Quote exactly where I said that SVS did not have VSAM. I believe
you will find that it was a reader's inference because I didn't
say one way or the other.
I gave the order of which system got VSAM first from my memories.
And I mangled a sentence -- I looked at it a few times after the
posting and it wasn't clear.
So with SVS being chopped liver, I decided it wasn't worth the
efforts (or Shmuel, was that a bad inference by me reading what
you said?).
AFTER ALL, this is 2018, not the 1970s. Those things make no
difference anymore. But the difference in the way it was
implemented between OS and DOS made a big difference in how
SHAREOPTIONS were implemented/done/used. And that is the problem
the OP is having to deal with after the migration.
And to another posting about SHAREOPTION 5 -- I'd be more
inclined to suggest the use of IAM. Cheaper than IBM's VSAM,
while doing the same types of files as VSAM and providing the
cross "DOMAIN" support that the OP might need.
I am probably prejudiced against a certain vendor because of
experience with them putting their cash cow in their basement.
It might be worth a trial to see the differences and costs.
Regards,
Steve Thompson
On 09/06/2018 03:04 PM, Seymour J Metz wrote:
Who said SVS did not have VSAM?
Steve Thompson
SVS certainly did have VSAM
Indeed.
--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3
________________________________________
From: IBM Mainframe Discussion List <[email protected]> on behalf of Mark
Waterbury <[email protected]>
Sent: Wednesday, September 5, 2018 6:19 PM
To: [email protected]
Subject: Re: VSAM share-option 4
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
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
