ca.portal.admin

Re:[IDMSVENDOR-L] DASD Upgrades

Discussion created by ca.portal.admin on Feb 4, 2009
Our service provider announced plans to upgrade DASD hardware from mod-3

(3,339 cyl) to mod-L (32,760 cyl). =20



Currently we have many multi-file areas with some exceeding 50 files.

The general approach is to keep allocation down to roughly 12,500 tracks

(quarter volume) for each file. I was told this allowed for flexibility

when having to perform these migrations (and there's probably other

reasons) but I'm not convinced this is a good way to manage our database

files.



Would it be practical to allocate DB files to the volume's maximum size

when necessary? Any general rules to follow when allocating large

areas?



TIA,

Brian Hirman

R16.0 SP4 z/OS 1.9



=20
"
IDMS Public Discussion Forum
IDMS-L@LISTSERV.IUASSN.COM
SMTP
IDMS-L@LISTSERV.IUASSN.COM
IDMS-L@LISTSERV.IUASSN.COM
SMTP








Normal

Normal
Re: DASD Upgrades
"I have created myself a rule, no dataset is bigger than 200 cylinders=
.=20
If I need more, I split the area into many 200 cylinder files. Like=
=20
this, I have all the flexibility to move my database files, they are =
all=20
200 cylinders. well most of them. So if I have access to a new pack,=
=20
then I can start moving those 200 cylinder files as I wish. They are=
=20
interchangeable.

Voil=E0,
Daniel Bureau
Ajilon Consulting
Montr=E9al

Hall, Dan (GE Comm Fin) a =E9crit :
Brian,
One drawback to allocating a DB file to the maximum number of track=
s is,
what happens if an area unexpectedly fills up? You have painted you=
rself
into a corner. You cannot perform a quick EXPAND PAGE to correct th=
e
problem. The larger page size would automatically mean you are goin=
g to
use more tracks than are available on a single volume. These would =
force
you to perform an Unload/Reload to correct the problem, this means =
a
much larger outage time.

We try to allocate the DB files 1/2 the maximum number of tracks, j=
ust
for this reason.

Another issue is, how often do you have completely empty production
volumes sitting around when you need to allocate files? It is usual=
ly a
lot easier (at least for me) to find a fraction of a volume than it=
is
to find a completely empty volume.


Dan Hall=20
Database Administrator=20
GE Capital Solutions=20

T 513 217 5060=20
E dan.hall@ge.com=20
www.ge.com/capitalsolutions/=20

Middletown, OH 45042=20
General Electric Capital Corporation=20

GE imagination at work=20


-----Original Message-----
From: IDMS 3rd-party providers forum
[mailTo:IDMSVENDOR-L@LISTSERV.IUASSN.COM] On Behalf Of HIRMAN, BRIA=
N CIV
DFAS
Sent: Wednesday, February 04, 2009 2:37 PM
To: IDMSVENDOR-L@LISTSERV.IUASSN.COM
Subject: [IDMSVENDOR-L] DASD Upgrades

Our service provider announced plans to upgrade DASD hardware from =
mod-3
(3,339 cyl) to mod-L (32,760 cyl). =3D20

Currently we have many multi-file areas with some exceeding 50 file=
s.
The general approach is to keep allocation down to roughly 12,500 t=
racks
(quarter volume) for each file. I was told this allowed for flexib=
ility
when having to perform these migrations (and there's probably other
reasons) but I'm not convinced this is a good way to manage our dat=
abase
files.

Would it be practical to allocate DB files to the volume's maximum =
size
when necessary? Any general rules to follow when allocating large
areas?

TIA,
Brian Hirman
R16.0 SP4 z/OS 1.9

=3D20


=20
"
IDMS 3rd-party providers forum
IDMSVENDOR-L@LISTSERV.IUASSN.COM
SMTP
IDMSVENDOR-L@LISTSERV.IUASSN.COM
IDMSVENDOR-L@LISTSERV.IUASSN.COM
SMTP








Normal

Normal
Re: DASD Upgrades
"One more area of concern is disaster recovery. If your recovery site
does not have the same dasd, you could be in a bind. By keeping to the
smaller sizes you can prevent a problem.=20


Will Hathcock
Database Administrator
(719) 495-6177

We are what we repeatedly do. Excellence then, is not an act but a
habit. - Aristotle

Outcomes