As I said, there are some good things and bad things for each OS.
As to your question, if someone is using the file when the 5 hour job
gets to that point, then it just waits.
Deadly embrace is normally a function of poor design or bad scheduling.
When that happens we just beat our programmers so they don't do it
again. :-)
But, if it is something that might happen, we just convert the VSAM file
to shareoption-4, which *WORKS* in z/VSE by letting multiple programs
update the VSAM file at the same time without any special programming by
the programmer. Unlike z/OS which never implemented shareoption-4 as
documented in the original design document.
(I had a conversation with a IBM guy that worked on the original VSAM
code for MVS(?) when he was at IBM. He said that they just ran out of
time getting it to work, so they changed the document so that it was the
programmers responsibility to lock/unlock, not the OS. The OS handled it
the lock/unlock/wait in DOS/VS). He tried to get them to do it right
later, but powers that be said it was out and could no longer be changed.)
Tony Thigpen
Charles Mills wrote on 3/30/20 6:00 PM:
Not beating up on VSE. ("My OS is better than your OS.") DOS/360 was my first
IBM OS.
But the negative -- what OS/360 was trying to avoid -- is deadly embrace. What
if that 5-hour job gets up to the end and then CANNOT allocate the VSAM file?
And worst case, what if the program that owns it is waiting on something the
5-hour job already owns?
Charles
-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf
Of Tony Thigpen
Sent: Monday, March 30, 2020 8:38 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: PARM= vs PARMDD= and symbol substitution
Yes, before the EXEC card.
Actually, there is no 'allocation' of a file by z/VSE during the JCL
processing. The file is only 'allocated' once it is opened and
'unalocated' once the program closes the file.
For instance, if you have a 5 hour program, that just needs to update a
'totals' VSAM file at the end of the 5 hours, as long as the program
does not open the file until it needs the file, any other program can
use, including updating, the file until that time.
So, basically, you 'own' the file only while you have it opened.
One ramification is that you can't create a file simply by having in the
jcl, like in z/OS. You have to open it to create it.
Tony Thigpen
Paul Gilmartin wrote on 3/30/20 11:05 AM:
On Mon, 30 Mar 2020 10:11:53 -0400, Tony Thigpen wrote:
Coming from the z/VSE world, some of the JCL stuff in z/OS just is 'weird'.
I understand that in z/VSE tne DD statementw precede the EXEC for
the step. Intuitive because allocation is done first.
1) In z/VSE, the conditional jcl statements are more logical, not
something akin to RPN.
2) Our SETPARMs are sequential. You can have multiple SETPARMs of the
same variable in the same step and intervening statements are processed
using the 'then value' of the SETPARM.
3) We can modify and even define SETPARM values via programs as a way to
pass information between steps.
Don't get me wrong, there are good things in both, but sometimes issues
with the underlying basics of each lead to strange 'higher level' items.
Working daily on z/VSE, z/VM and z/OS really get's confusing sometimes.
Even simple things like responding to a console message. z/VSE needs the
outstanding message number, followed by a space, then the response. Yet,
z/OS usually needs a comma where z/VSE had the space, but not always.
-- gil
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
