Yes your reading and interpretation is essentially correct.
VSAM was implemented at the OS level with DOS/VS (and IIRC,
DOS/VS was first to have VSAM with MVS|VS1 to follow), where with
OS (OS/VS1 or MVS) it was implemented at the address space level.
Whoever did your migration, if they did not have a background
involving DOS/VS_ and just did a flat migration to MVS (z/OS),
you can get royally shafted.
The SHARE OPTIONS between the two systems are very different and
one has to know and understand this to do a proper migration and
Catalog structures are very different between the two systems.
Where you would do backups by CATALOG, a CATALOG does not OWN the
volumes in an MVS shop. But they did in a DOS/VS shop.
And I hate to break this to you at this late date, but if the
migrators didn't know it, the z/VSE system was an XA I/O system
and so the performance increase for I/O that one expected in days
of yore in going to z/OS will not be there (until DOS/VSE/ESA,
DOS systems were BASE S/370 using the OLD SIO/SIOF, etc. and not
SSCH and related instructions).
You may actually lose performance in the z/OS environment as a
result.
Regards,
Steve Thompson
On 09/04/2018 07:42 PM, Tony Thigpen wrote:
My main background is z/VSE but now I have to manage a bunch of
z/OS sites, including one that recently converted from z/VSE to
z/OS.
On z/VSE, share-option 4 means that VSAM will prevent any read or
write integrity exposures when multiple tasks are accessing the
same VSAM file.
z/VSE VSAM will internally lock any CI that is being updated so
that nobody else can update the CI. This ENQ/DEQ is handled by
the IBM provided VSAM IO routines at the task level.
Additionally, VSAM will flush all update buffers after a write or
update. And, it will not buffer reads when reading a share-option
4 file. (I am being somewhat general in the descriptions, so the
details are a little more complicated.) All this to make sure
that the records on disk and the records in buffers match.
Now, with z/OS, my reading of the VSAM Demystified RedBook leads
me to the following:
1) Share-option 4 allows multiple open for update, but expects
the program, not the VSAM subsystem, to perform the ENQ/DEQs.
2) If a program does not perform ENQ/DEQs, then data integrity is
lost as multiple tasks can update the same record concurrently.
3) VSAM/RLS is one way to protect the data, but that is another
can of worms.
Am I understanding the z/OS side correctly?
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
