You may want to look at CA Shareoption5. I know that was used in a VSE->z/OS migration in a past life, and seem to recall it was something to do with addressing online & batch concurrency/integrity.
On Wed, 5 Sep 2018 at 23:24, Mark Waterbury < [email protected]> wrote: > Who said SVS did not have VSAM? > SVS certainly did have VSAM ... > > It was an ICR -- Independent Component Release -- so somewhat tricky to > get it installed into SVS, but once installed, it did work... and CICS/VS > used it ... > This was on SVS 1.7 circa 1976-77... > And, just like on MVS, on SVS, we were taught that: > Share options means 3 Close your eyes > 4 Close your eyes and step on the gas! > Does that jog anyone's memory? > Mark S. Waterbury > > On Wednesday, September 5, 2018, 12:35:26 AM EDT, Seymour J Metz < > [email protected]> wrote: > > > > 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) > > What was SVS, chopped liver? > > > -- > Shmuel (Seymour J.) Metz > http://mason.gmu.edu/~smetz3 > > ________________________________________ > From: IBM Mainframe Discussion List <[email protected]> on behalf > of Steve Thompson <[email protected]> > Sent: Tuesday, September 4, 2018 8:35 PM > To: [email protected] > Subject: Re: VSAM share-option 4 > > 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 > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to [email protected] with the message: INFO IBM-MAIN > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to [email protected] with the message: INFO IBM-MAIN > ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
