Paul Gilmartin wrote:
On Fri, 15 May 2009 09:27:42 -0400, Thompson, Steve wrote:
Welcome to the MVS world. In the MVS world, we are not device dependant,
nor are we data definition locked/blocked. We generally don't have to
recompile our programs, change the DTF contents (DCB in MVS), etc. just
because the file attributes change (xSAM to VSAM is the exception).
Huh???
If "we are not device dependant", why is there such intense trepidation
and resistance to the mere suggestion of a device with a novel geometry
such as more bytes per track or more tracks per cylinder? It doesn't
appear that you and I have been living in the same MVS world.
-- gil
It would be a rarity for application programs themselves to be device
dependent in the z/OS world, but once you start dealing with instances
of data used by those programs on DASD the dependency creeps back in in
both obvious and subtle ways, in both the physical representation of the
data and in the JCL which references or allocates that data set. I
think it would be fair to say that a systems programmer who has to
design and implement a migration strategy and deal with effects that are
more often than not performance and resource usage issues would see many
more issues with DASD architecture migration than an applications
programmer.
Just changing the number of cylinders per device, complicates DASD
migration strategies and may require JCL adjustments to optimize
allocations when the typical free space per volume or size of typical
free space extents changes. If you change the capacity of a track or
cylinder, then all JCL, IDCAMS, or TSO dataset space allocations in
those units are obviously suspect.
A change in track size raises issues in both block size and number of
blocks per track that in general defy a completely automated solution
and require some analysis to resolve. Even with an ordinary sequential
dataset, there is no guarantee that all access is via standard (QSAM)
access methods with no use of pointers dependent in some way on track
geometry. And even if all access is QSAM, do you leave the block size
alone and risk performance issues, or re-optimize block size and risk
having to adjust JCL REGION sizes to allow for larger buffers? Data set
types that are known to be direct access, and which may contain internal
relative track pointers cannot be copied without some internal modification.
Changes in track size or tracks per cylinder have especially subtle side
effects when dealing with VSAM KSDS files. VSAM Control Area (CA) size
is tied to the physical cylinder architecture, optimum index CI-size is
tied to the number of Data CIs per CA, which in turn is tied to both
track size and cylinder size. Failure to adjust a sub-optimum Index CI
size when copying a KSDS to a new architecture could seriously degrade
CA space utilization and increase total dataset space requirements, but
automatically adjusting Index CI size for online files could have
adverse side effects on manually defined LSR buffer pools in the online
regions that access these KSDS files. So again, any attempt to
automatically migrate such files to a new architecture carries risks.
Having been through several architecture conversions in the past -- 3330
> 3350 > 3380(various models) > 3390(various models) -- there is no
doubt that (1)it can be done (but any old code with datasets that are
tied to one architecture with no source or no support is a definite
problem!), (2) a migration that changes the track/cylinder architecture
takes more person hours to do correctly, (3) and having two different
architectures in house during a transition is more complicated to
manage. All things being equal, I would much rather not use my scarce
time dealing with DASD architecture migration.
Joel C Ewing
----------------------------------------------------------------------
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
