R.S. wrote:
Rick Fochtman wrote:
----------------------<snip>--------------------
One could enlarge those data set if a new unit type with larger
tracks would be defined.
I admit I'm too busy (lazy) right now to RTFM but would appreciate
any toughts on this (just curious). Why do we still keep the ~55k
track size and increase only the number of cylinders? With modern
DASD subsystems it shouldn't matter, right? What are the track size
limits in z/OS? I guess it's 64k, but still this would be 16% more.
---------------------<unsnip>-----------------------
You're right, but the downside is this: there are literally millions
of lines of JCL still in regular use that allocate space in terms of
tracks and cylinders. To change the length of a track would invoke
nightmares of geometry changes, which we all suffered through in
pre-3390 days whenever a newer DASD design hit the street. IT managers
that remember those days still cringe at the thought! Until all
allocations are done in terms of bytes, or multiples thereof, a
geometry change will put people into cold sweats. Old habits are hard
to break; old nightmares are hard to forget.
I disagree. Completely. Mainframe users had to do with different track
sizes, some dataceneters still have 3380 emulation.
There is also possiblity to use bytes/kbytes/Mbytes. It have been here
for years. Since beginning of DFSMS. JCL change shouldn't be a problem,
it had to be done during previous model conversion, it can be done in
the future. Last but not least: it *need not* to be done! You can set
"default track size" in SMS. This mechanism can be further enhanced. So,
in fact no change is required. Even for jobs with hardcoded volsers.
--
Radoslaw Skorupka
Lodz, Poland
As some have already noted, the reason why current DASD supports both
3380 and 3390 architecture, and some sites are still running DASD in
3380 emulation mode, is most likely because of some perceived difficulty
of migrating to 3390 architecture.
I have lived through 3330 -> 3350 -> 3380 -> 3390 DASD migrations (as an
MVS SysProg) and every one consumed a significant amount of man hours
and was in general a pain. Also running in a shop with multiple
architectures always introduced extra complications. Before putting a
new architecture on line, it has always been necessary to bring
Operating System maintenance current, check on vendor software support,
research known problems with new hardware support, track down HIPER
fixes (there invariably were some unresolved APARs), research
operational changes and installation issues for the new DASD, etc. etc.
Even if all JCL used space allocation in bytes and SDB (and there are
always some cases where this is not so), you still have to worry about
VSAM allocation and index-space and index CISIZE dependencies on tracks
per cylinder; and how to mass migrate datasets, many of which may be
active on-line datasets that are not normally re-created by JCL, and
doing this in a way that effectively uses space on a volume with a new
architecture and capacity.
Even today I don't know of any tools that will allow you to dynamically
move a single in-use dataset to another DASD volume; and those tools
that allow you to dynamically move an entire volume to another volume
(e.g., FDRPAS) require identical volume architecture (and at least as
many cylinders), and cannot merge data from multiple volumes to a single
larger target volume dynamically.
Bottom line, if you change DASD architecture there is no way to avoid
extra system downtime to finish part of the migration. But if you stay
within the same DASD architecture, there are ways to make the
transition almost transparent to your user community. From the
standpoint of system availability, I would hate to be forced to make an
arbitrary change from 3390 DASD architecture after seeing the
availability benefits and time savings from staying within the 3390
architecture over at least five major DASD system migrations over the
last decade.
--
Joel C. Ewing, Fort Smith, AR [EMAIL PROTECTED]
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
