Re: Why is there JOB scope for DSN ENQ's anyway?

[Shmuel Metz (Seymour J.)]

In <[EMAIL PROTECTED]>, on 05/27/2007
   at 03:39 PM, Bruce Black <[EMAIL PROTECTED]> said:

>The initiator knows which step is the last step, but I don't know how
>an executing program can tell

All of the control blocks are in SWA. Further, it's the Initiator that
issues the ENQ and DEQ requests for SYSDSN.
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see  
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

--
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

Re: Why is there JOB scope for DSN ENQ's anyway?

[Paul Gilmartin]

On Sun, 27 May 2007 15:39:49 -0400, Bruce Black wrote:

>> That "There is no easy way that I know to determine if the current
>> step is the last step that uses the dataset" claim conflicts with your
>> "then releases the dataset at the end of the last step that uses it"
>> statement.
>The initiator knows which step is the last step, but I don't know how an
>executing program can tell
>
Ah, you're getting there.  Even as the initiator with that knowledge
performs the SYSDSN DEQ after the last step that uses a data set name,
I'd expect that if the downgrade facility were provided it would likewise
be the initiator, not the executing program, that would downgrade the
ENQ after the last step that required exclusive when subsequent steps
require only shared.

-- gil

--
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

Re: Why is there JOB scope for DSN ENQ's anyway?

[Bruce Black]

That "There is no easy way that I know to determine if the current 
step is the last step that uses the dataset" claim conflicts with your 
"then releases the dataset at the end of the last step that uses it" 
statement.
The initiator knows which step is the last step, but I don't know how an 
executing program can tell


--
Bruce Black
Senior Software Developer
Innovation Data Processing

--
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

Re: Why is there JOB scope for DSN ENQ's anyway?

[Shmuel Metz (Seymour J.)]

In <[EMAIL PROTECTED]>, on 05/25/2007
   at 05:39 PM, "Robert A. Rosenberg" <[EMAIL PROTECTED]> said:

>I may be missing something but I do not see how GRS comes into play.

The scenario you describe involves GRS.

>Lets say that I have two systems in my GRSplex. System A has the 
>enhanced ENQ while System B does not. If I run a job on System B,
>the  EXC ENQ gets keep until the last DISP=SHR step terminates (like
>now).  When run on System A, the EXC ENQ gets downgraded and
>propagated to  System B 

How? There is no interface for doing that. IBM could add an interface,
but it would have to be present in System B, not just in System A.

>Remember that the fix is done in the Initiator

No; the new facility is in GRS and the Initiator only invokes it.

>so that fact the System B Initiator (and ENQ) does not have the fix 
>does not affect anything.

Without the fix, System B would not be able to correctly respond to
the downgrade message from System A.

-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see  
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

--
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

Re: Why is there JOB scope for DSN ENQ's anyway?

[Paul Gilmartin]

On Sat, 26 May 2007 15:09:36 EDT, IBM Mainframe Discussion List wrote:
>
>>Good idea.  I'll ask my admins to add to my (and other users') TSO  logon 
>>PROCs DD statements for data set names that we're likely to  allocate 
>>dymamically in our TSO sessions.
>
>So far, I thought this thread was all about jobs with multiple steps.   Are
>TSO logon PROCs on your system likely to have multiple steps?
>
I was trying to point out by example, not that multi-step TSO procs
need be supported (apparently that's prohibited anyway), but that
often the coder of a DYNALLOC call doesn't know a priori what DSNAME
will be allocated.  In fact, if as you suggested earlier:

Maybe users should read the documentation (if it mentions this  exposure),
realize that there is an exposure (this may be asking a lot),  and add a DD
statement to the step that does the dynamic allocation so the  Initiator 
will not
be fooled (if they know how that step works).

all DSNAMES dynamically allocated should also appear in DD statements in JCL,
there would be little use for DYNALLOC.  Programmers might as well use the
JCL allocation instead.

I understand the hazard that a "dusty deck" containing:

//STEP1   EXEC ...
//SYSUT2   DD  DISP=(NEW,CATLG),...
...
//STEP2   EXEC
//SYSUT1   DD  DISP=SHR,DSN=*.SYSUT2

would, if the downgrade ENQ facility were provided, find the system behavior
changed in that some other job might modify the data set between the steps
(but only if that other job updated with DISP=SHR, not very good practice).
Perhaps "downgradable" should be an option on the DD statement:

//SYSUT2   DD  DISP=((NEW,DOWNGRADABLE),CATLG),...

... or on the JOBPARM.

I understand that long ago the progenitor of z/OS maintained the ENQ
until the last step of the job; doing the DEQ after the last step
using the DSNAME in a DD statement was an innovation, undoubtedly in
response to customer requirements.  Didn't this likewise introduce
an exposure for jobs that allocated a DSNAME in JCL only in an earlier
step and DYNALLOCed it in a later step? Or was the change to early
DEQ introduced before the advent of dynamic allocation?

-- gil

--
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

Re: Why is there JOB scope for DSN ENQ's anyway?

[Ted MacNEIL]

>Are TSO logon PROCs on your system likely to have multiple steps?

I forget the code (S622?), but TSO will abend the user if there's more than one 
step in a TSO PROC.
-
Too busy driving to stop for gas!  

--
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

Re: Why is there JOB scope for DSN ENQ's anyway?

[(IBM Mainframe Discussion List)]

 
 
In a message dated 5/26/2007 1:53:01 P.M. Central Daylight Time,  
[EMAIL PROTECTED] writes:
>Good idea.  I'll ask my admins to add to my (and other users') TSO  logon
PROCs DD statements for data set names that we're likely to  allocate
dymamically in our TSO sessions.
 
So far, I thought this thread was all about jobs with multiple steps.   Are 
TSO logon PROCs on your system likely to have multiple steps?
 
Bill  Fairchild
Plainfield, IL

Euripides: "Man's most valuable trait is a  judicious sense of what not to 
believe." [412 B.C.;  Helen]





** See what's free at http://www.aol.com.

--
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

Re: Why is there JOB scope for DSN ENQ's anyway?

[Paul Gilmartin]

On Sat, 26 May 2007 14:33:35 EDT, IBM Mainframe Discussion List wrote:
>
>Maybe users should read the documentation (if it mentions this  exposure),
>realize that there is an exposure (this may be asking a lot),  and add a DD
>statement to the step that does the dynamic allocation so the  Initiator will 
>not
>be fooled (if they know how that step works).
>
Good idea.  I'll ask my admins to add to my (and other users') TSO logon
PROCs DD statements for data set names that we're likely to allocate
dymamically in our TSO sessions.

-- gil

--
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

Re: Why is there JOB scope for DSN ENQ's anyway?

[(IBM Mainframe Discussion List)]

 
 
In a message dated 5/25/2007 9:27:17 P.M. Central Daylight Time,  
[EMAIL PROTECTED] writes:
bblack (I think):
>>>That "There is no easy way that I know to determine if the  current 
>>>step is the last step that uses the dataset" claim  conflicts with
>>>your  "then releases the dataset at the end  of the last step that uses
>>>it"  statement.
 
[EMAIL PROTECTED] (mailto:[EMAIL PROTECTED]) :
>>It confused me at first, too.  I believe what he means is  that the  
Initiator
>>can know where the last step is that has JCL  referring to the data  set, 
but
>>cannot know that a later step  will dynamically allocate the data set  
without
>>JCL referring to  it.
 
[EMAIL PROTECTED] (mailto:[EMAIL PROTECTED]) :
>At the current time that is an exposure RIGHT NOW since the Initiator  
>has released the ENQ and you have to hope you can get it again. How  
>will doing a EXC->SHR downgrade alter this situation?
 
Maybe users should read the documentation (if it mentions this  exposure), 
realize that there is an exposure (this may be asking a lot),  and add a DD 
statement to the step that does the dynamic allocation so the  Initiator will 
not 
be fooled (if they know how that step works).
 
Bill  Fairchild
Plainfield, IL

"Men will never be free until the last king  is strangled with the entrails 
of the last priest." [Denis Diderot;  1713-1784]





** See what's free at http://www.aol.com.

--
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

Re: Why is there JOB scope for DSN ENQ's anyway?

[Robert A. Rosenberg]

At 18:34 -0400 on 05/25/2007, (IBM Mainframe Discussion List) wrote 
about Re: Why is there JOB scope for DSN ENQ's anyway?:





In a message dated 5/25/2007 5:09:08 P.M. Central Daylight Time, 
[EMAIL PROTECTED] writes:

That "There is no easy way that I know to determine if the current 

step is the last step that uses the dataset" claim conflicts with
your  "then releases the dataset at the end of the last step that uses
it"  statement.

It confused me at first, too.  I believe what he means is that the  Initiator
can know where the last step is that has JCL referring to the data  set, but
cannot know that a later step will dynamically allocate the data set  without
JCL referring to it.



At the current time that is an exposure RIGHT NOW since the Initiator 
has released the ENQ and you have to hope you can get it again. How 
will doing a EXC->SHR downgrade alter this situation?



Bill  Fairchild
Plainfield, IL



--
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

Re: Why is there JOB scope for DSN ENQ's anyway?

[(IBM Mainframe Discussion List)]

 
 
In a message dated 5/25/2007 5:09:08 P.M. Central Daylight Time,  
[EMAIL PROTECTED] writes:
>That "There is no easy way that I know to determine if the current  
step is the last step that uses the dataset" claim conflicts with 
your  "then releases the dataset at the end of the last step that uses 
it"  statement.
 
It confused me at first, too.  I believe what he means is that the  Initiator 
can know where the last step is that has JCL referring to the data  set, but 
cannot know that a later step will dynamically allocate the data set  without 
JCL referring to it.
 
Bill  Fairchild
Plainfield, IL





** See what's free at http://www.aol.com.

--
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

Re: Why is there JOB scope for DSN ENQ's anyway?

[Robert A. Rosenberg]

At 14:14 -0400 on 05/25/2007, Bruce Black wrote about Re: Why is 
there JOB scope for DSN ENQ's anyway?:



As far as a EXC-SHR function, this also seems obvious to me.  The
initiator ENQs the dataset, and then releases the dataset at the end of
the last step that uses it.  If you issue a EXC-SHR request, a fullowing
step may need the dataset exclusive and you have now compromised the
dataset.  There is no easy way that I know to determine if the current
step is the last step that uses the dataset.


That "There is no easy way that I know to determine if the current 
step is the last step that uses the dataset" claim conflicts with 
your "then releases the dataset at the end of the last step that uses 
it" statement.


Since it parses the job stream and sets a flag to say "You can 
release the ENQ at Step Term" (as it apparently does), it can know 
where the last DISP=OLD step is and do the downgrade then IF there 
are one or more subsequent DISP=SHR steps (otherwise do the DEQ at 
that point since this is the last step that uses the dataset).


--
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

Re: Why is there JOB scope for DSN ENQ's anyway?

[Robert A. Rosenberg]

At 10:48 -0300 on 05/24/2007, Shmuel Metz (Seymour J.) wrote about 
Re: Why is there JOB scope for DSN ENQ's anyway?:



 >Just make it a private/undocumented interface (as has been done with

other internal functions such as SuperLocate and others) and
restrict its use to ONLY the Initiator (and possibly other IBM
routines that could be more efficient by its availability).


That is an unnecessary and insufficient condition. I see no risk in
making it a GUPI, while making it private does not resolve the problem
of a GRSplex with some members not having the functionality. By all
means submit a requirement, with a sound business case, but don't ask
for an early implementation; if you got one you'd be sorry. It will
undoubtedly take IBM some serious work to get the GRS aspect right.


I may be missing something but I do not see how GRS comes into play. 
Lets say that I have two systems in my GRSplex. System A has the 
enhanced ENQ while System B does not. If I run a job on System B, the 
EXC ENQ gets keep until the last DISP=SHR step terminates (like now). 
When run on System A, the EXC ENQ gets downgraded and propagated to 
System B (with all the waiting SHR ENQs on both systems getting 
released). Remember that the fix is done in the Initiator so that 
fact the System B Initiator (and ENQ) does not have the fix does not 
affect anything.


My 2 step implementation method (first private interface and then 
later GUPI when the downlevel system issues get addressed) is to 
allow it to be available to the Initiator (and other IBM routines) 
NOW with code that is Guaranteed to be at the minimal support level 
needed to make use of it without running into the GOTCHA situation of 
a user program that is using the GUPI (or assuming that the support 
exists due to being assembled with a ISGENQ [ENQ due to being 
depreciated does not need to be updated just like GETMAIN was not to 
support STORAGE-Only functionality] macro that supports it) and then 
run on a downlevel system without the support (assuming that the 
current ENQ/ISGENQ routine can not spot the "bad" parmlist and either 
ABEND or return a Non-Zero RC as appropriate).


--
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

Re: Why is there JOB scope for DSN ENQ's anyway?

[Paul Gilmartin]

on Fri, 25 May 2007 15:19:35 -0400, J R <[EMAIL PROTECTED]> wrote:
>
>Right, but maybe the intervening de-allocate was done without a DEQ.
>
That's what I believe.

>Besides, the message "IKJ56247I FILE SYSUT1 NOT FREED, IS NOT ALLOCATED" may
>not come to pass the way you think.  It says that the *ddname* is no longer
>allocated.  A better test might be via the command "free da('FOO.BAR')".
>
Good point.  I'll try it ...

>In any event, I believe the alloc and free commands are probably driven off
>the DSABQ; the first free removes the DSAB, the second one does not find it.
>  Whether the dataset remains allocated or, more to the point, enqueued, is
>another matter.
>
OK.  And I added Greg S's SLEEP.  During the sleep, when I attempt
to allocate from my TSO session, I get:

 MIM1088 CONTENTION WITH FREEDSN OWNS EXCL  ON LSTC3MVS
 MIM1089 YOU NEED SHR  SYSDSN   FOO.BAR
 IKJ56225I DATA SET FOO.BAR ALREADY IN USE, TRY LATER+
 IKJ56225I DATA SET IS ALLOCATED TO ANOTHER JOB OR USER

... DEQ is not happening.  It works as it should.  And SYSTSPRT
output for both steps says:

free dataset('FOO.BAR')
READY
free dataset('FOO.BAR')
IKJ56247I DATA SET FOO.BAR NOT FREED, IS NOT ALLOCATED

-- gil

--
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

Re: Why is there JOB scope for DSN ENQ's anyway?

[J R]

Paul Gilmartin said:
the initiator

was able to allocate it again in STEP2.  I hope this was
not done without an ENQ.


Right, but maybe the intervening de-allocate was done without a DEQ.

Besides, the message "IKJ56247I FILE SYSUT1 NOT FREED, IS NOT ALLOCATED" may 
not come to pass the way you think.  It says that the *ddname* is no longer 
allocated.  A better test might be via the command "free da('FOO.BAR')".


In any event, I believe the alloc and free commands are probably driven off 
the DSABQ; the first free removes the DSAB, the second one does not find it. 
 Whether the dataset remains allocated or, more to the point, enqueued, is 
another matter.







From: Paul Gilmartin <[EMAIL PROTECTED]>
Reply-To: IBM Mainframe Discussion List 
To: IBM-MAIN@BAMA.UA.EDU
Subject: Re: Why is there JOB scope for DSN ENQ's anyway?
Date: Fri, 25 May 2007 13:48:43 -0500

On Fri, 25 May 2007 14:14:44 -0400, Bruce Black wrote:
>
>As far as a EXC-SHR function, this also seems obvious to me.  The
>initiator ENQs the dataset, and then releases the dataset at the end 
ofVVe

>the last step that uses it.  If you issue a EXC-SHR request, a fullowing
>step may need the dataset exclusive and you have now compromised the
>dataset.  There is no easy way that I know to determine if the current
>step is the last step that uses the dataset.
>
Apparently the initiator is up to the task, easy or difficult.
The JCL fragment:

//*
//STEP1EXEC  PGM=IKJEFT01
//SYSUT1DD   DISP=OLD,DSN=FOO.BAR,
//  UNIT=SYSALLDA,VOL=SER=TSO001
//SYSTSPRT  DD   SYSOUT=(,)
//SYSTSIN   DD   *
free dd(sysut1)
free dd(sysut1)
//*
//STEP2EXEC  PGM=IKJEFT01
//SYSUT1DD   DISP=OLD,DSN=FOO.BAR,
//  UNIT=SYSALLDA,VOL=SER=TSO001
//SYSTSPRT  DD   SYSOUT=(,)
//SYSTSIN   DD   *
free dd(sysut1)
free dd(sysut1)
//*

produces SYSTSPRT from STEP1

READY
free dd(sysut1)
READY
free dd(sysut1)
IKJ56247I FILE SYSUT1 NOT FREED, IS NOT ALLOCATED
READY
END

... and  SYSTSPRT from STEP2

READY
free dd(sysut1)
READY
free dd(sysut1)
IKJ56247I FILE SYSUT1 NOT FREED, IS NOT ALLOCATED
READY
END

... so even though FOO.BAR was FREEd in STEP1, the initiator
was able to allocate it again in STEP2.  I hope this was
not done without an ENQ.  Whatever technique the initiator
used here, it could use the same technique to differentiate
an EXC from A SHR ENQ.

-- gil


_
PC Magazine’s 2007 editors’ choice for best Web mail—award-winning Windows 
Live Hotmail. 
http://imagine-windowslive.com/hotmail/?locale=en-us&ocid=TXT_TAGHM_migration_HM_mini_pcmag_0507


--
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

Re: Why is there JOB scope for DSN ENQ's anyway?

[Greg Shirey]

Hmm, I took your example job and added a step inbetween your two and put
the job to sleep for 30 seconds.  

The SYSTSPRT output looked like this:

READY 
FREE DD(SYSUT1)   
READY 
FREE DD(SYSUT1)   
IKJ56247I FILE SYSUT1 NOT FREED, IS NOT ALLOCATED 
READY 
END   
Going to sleep for 30 seconds 
14:05:52.270727   
14:06:22.280007   
READY 
END   
READY 
FREE DD(SYSUT1)   
READY 
FREE DD(SYSUT1)   
IKJ56247I FILE SYSUT1 NOT FREED, IS NOT ALLOCATED 
READY 
END   

But for that 30 seconds, I was unable to edit the SYSUT1 data set -
"Data set in use".   The ISPF Data Set Contention panel showed my batch
job "owns data set exclusively."

Greg Shirey
Ben E. Keith Company


-Original Message-
From: IBM Mainframe Discussion List On Behalf Of Paul Gilmartin
Sent: Friday, May 25, 2007 1:49 PM
To: IBM-MAIN@BAMA.UA.EDU
Subject: Re: Why is there JOB scope for DSN ENQ's anyway?


Apparently the initiator is up to the task, easy or difficult.
The JCL fragment:

//*
//STEP1EXEC  PGM=IKJEFT01
//SYSUT1DD   DISP=OLD,DSN=FOO.BAR,
//  UNIT=SYSALLDA,VOL=SER=TSO001
//SYSTSPRT  DD   SYSOUT=(,)
//SYSTSIN   DD   *
free dd(sysut1)
free dd(sysut1)
//*
//STEP2EXEC  PGM=IKJEFT01
//SYSUT1DD   DISP=OLD,DSN=FOO.BAR,
//  UNIT=SYSALLDA,VOL=SER=TSO001
//SYSTSPRT  DD   SYSOUT=(,)
//SYSTSIN   DD   *
free dd(sysut1)
free dd(sysut1)
//*

produces SYSTSPRT from STEP1

READY
free dd(sysut1)
READY
free dd(sysut1)
IKJ56247I FILE SYSUT1 NOT FREED, IS NOT ALLOCATED
READY
END

... and  SYSTSPRT from STEP2

READY
free dd(sysut1)
READY
free dd(sysut1)
IKJ56247I FILE SYSUT1 NOT FREED, IS NOT ALLOCATED
READY
END

... so even though FOO.BAR was FREEd in STEP1, the initiator
was able to allocate it again in STEP2.  I hope this was
not done without an ENQ.  Whatever technique the initiator
used here, it could use the same technique to differentiate
an EXC from A SHR ENQ.

--
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

Re: Why is there JOB scope for DSN ENQ's anyway?

[Paul Gilmartin]

On Fri, 25 May 2007 14:14:44 -0400, Bruce Black wrote:
>
>As far as a EXC-SHR function, this also seems obvious to me.  The
>initiator ENQs the dataset, and then releases the dataset at the end ofVVe
>the last step that uses it.  If you issue a EXC-SHR request, a fullowing
>step may need the dataset exclusive and you have now compromised the
>dataset.  There is no easy way that I know to determine if the current
>step is the last step that uses the dataset.
>
Apparently the initiator is up to the task, easy or difficult.
The JCL fragment:

//*
//STEP1EXEC  PGM=IKJEFT01
//SYSUT1DD   DISP=OLD,DSN=FOO.BAR,
//  UNIT=SYSALLDA,VOL=SER=TSO001
//SYSTSPRT  DD   SYSOUT=(,)
//SYSTSIN   DD   *
free dd(sysut1)
free dd(sysut1)
//*
//STEP2EXEC  PGM=IKJEFT01
//SYSUT1DD   DISP=OLD,DSN=FOO.BAR,
//  UNIT=SYSALLDA,VOL=SER=TSO001
//SYSTSPRT  DD   SYSOUT=(,)
//SYSTSIN   DD   *
free dd(sysut1)
free dd(sysut1)
//*

produces SYSTSPRT from STEP1

READY
free dd(sysut1)
READY
free dd(sysut1)
IKJ56247I FILE SYSUT1 NOT FREED, IS NOT ALLOCATED
READY
END

... and  SYSTSPRT from STEP2

READY
free dd(sysut1)
READY
free dd(sysut1)
IKJ56247I FILE SYSUT1 NOT FREED, IS NOT ALLOCATED
READY
END

... so even though FOO.BAR was FREEd in STEP1, the initiator
was able to allocate it again in STEP2.  I hope this was
not done without an ENQ.  Whatever technique the initiator
used here, it could use the same technique to differentiate
an EXC from A SHR ENQ.

-- gil

--
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

Re: Why is there JOB scope for DSN ENQ's anyway?

[Bruce Black]

Can you PLEASE explain why there was/is support for a SHR->EXC
>Upgrade...
Pretty simple.  The dataset is ENQed SHR because the highest DISP in the 
job for that dataset is SHR.  But some function in a step may want to 
get EXC control so that it can update the dataset, thus the RET=CHNG 
function.  For example if you issue a DYNALLOC for the dataset in a 
program with DISP=OLD I believe DYNALLOC will chnage the ENQ.


As far as a EXC-SHR function, this also seems obvious to me.  The 
initiator ENQs the dataset, and then releases the dataset at the end of 
the last step that uses it.  If you issue a EXC-SHR request, a fullowing 
step may need the dataset exclusive and you have now compromised the 
dataset.  There is no easy way that I know to determine if the current 
step is the last step that uses the dataset.


--
Bruce A. Black
Senior Software Developer for FDR
Innovation Data Processing 973-890-7300
personal: [EMAIL PROTECTED]
sales info: [EMAIL PROTECTED]
tech support: [EMAIL PROTECTED]
web: www.innovationdp.fdr.com

--
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

Re: Why is there JOB scope for DSN ENQ's anyway?

[Paul Gilmartin]

On Fri, 25 May 2007 10:10:26 -0500, Scott Fagen wrote:
>
>On Wed, 23 May 2007 22:38:13 -0500, Paul Gilmartin wrote:
>
>>Would repairing a defect be considered (part of) a business case?
>
>Of course.
>>
>> 
>
>And what was the outcome of the incident?
>
It was so long ago that I was probably not submitting PMRs electronically;
I find I have no electronic record.  I'm confident there was no effective
repair at the time.  I don't recall an APAR with a PRS or SUG closure.
I could test again and see whether the problem persists.  It probably does.
Ideally, IBM should have provided the downgrade ENQ facility so DYNALLOC
could be made to operate as specified.  Failing that, it would be better
to change the specification to agree with reality and allow removing the
pitfall rather than to pretend the pitfall doesn't exist.  Merely documenting
the hazard might be more dirty linen than IBM cares to hang out.

-- gil

--
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

Re: Why is there JOB scope for DSN ENQ's anyway?

[Scott Fagen]

On Wed, 23 May 2007 00:46:28 -0400, Robert A. Rosenberg <[EMAIL PROTECTED]>
wrote:
>I do not regard my query about why this glaring design flaw in ENQ is
>not being addressed (even if the usage of the enhanced support is
>restricted to the Initiator initially) as insulting (or do you regard
>my characterization of the original/current design of ENQ lacking a
>EXC->SHR Downgrade capability as "poor"/"flawed" as insulting?).

Perhaps we differ, but the characterization of poor and/or flawed appears to
me as pejorative.

Please read the following as facts, not insults:

Since you are not in a custodial position for the design or implementation
of ENQ, GRS, or Allocation, you cannot know if such a design has ever been
proposed, written, or embodied.  You can only know that it is not available
as the operating system is currently implemented through consideration of
the written documentation and empirical experimentation.

ENQ/DEQ, in its current form (barring the two currently open APARs against
it, neither of which do not violate the integrity of the function), is not
flawed, the function is merely incomplete.  

>I am doing exactly what a SHARE Requirement is supposed to do - Point
>out a lack of functionality and provide an suggestion as to one way
>to rectify the lack. I do not have access to the SHARE Request List
>but I'd be surprised if there has not been one already submitted (or
>at least proposed) about this exact issue (the lack of a EXC->SHR
>downgrade at the job step boundary between DISP=OLD and DISP=SHR
>steps).

Although obvious, I'll state that IBM-MAIN is not considered a forum for
gathering requirements for IBM products.

>IMO, the lack of a fix in progress amounts to a deliberate crippling
>of the Initiator since the fix is so easy to make

You are entitled to your opinion.

On Wed, 23 May 2007 22:38:13 -0500, Paul Gilmartin <[EMAIL PROTECTED]>
wrote:

>Would repairing a defect be considered (part of) a business case?

Of course.
>
>I was sensitized to this matter many years ago when I learned that
>under certain conditions of contention attempting to DYNALLOC a data
>set with options NEW and CATALOG can fail and leave the data set on
>a volume not catalogued and not deleted.  I discovered this with
>considerable discomfort only when I had run the job enough times
>and it had failed enough times (usually it succeeded) that I had
>a copy of the problem data set on every storage volume on the floor.
>
>A dedicated IBM developer researched the problem and sought a solution.
>Finally, he reported to me that under the design requirements of
>DYNALLOC, and lacking the facility to downgrade an ENQ, no solution
>was possible.  (I would have changed the specifications of DYNALLOC,
>since the problem I reported demonstrated in itself that the specification
>was not being met.)  With an ENQ downgrade facility, the problem
>could easily have been solved within the constraints of the DYNALLOC
>specification.

And what was the outcome of the incident?

>
>And, finally, to throw an additional wrinkle Robert's way, suppose:
>
>ALLOCATE DD(E) DSN(FOO.BAR) OLD
>ALLOCATE DD(S) DSN(FOO.BAR) SHR
>FREE DD(E)
>
>A programmer might reasonably expect this would leave a SHR ENQ
>on SYSDSN FOO.BAR.  What component should do the accounting, and
>what's the algorithm?  But perhaps this hardly more complex than
>what is done nowadays when a data set name is statically allocated
>in JCL, then multiply allocated to different DDNAMEs and FREEd
>dynamically within the job step.

A programmer might come to that conclusion.  This programmer would agree if
the result of the set of directives concluded with _no_ ENQ on FOO.BAR.

However, if the result was that an EXCL ENQ remained on FOO.BAR, I'd come to
the same conclusion as I do now for the batch allocation case.  It ain't
perfect, but it gets the job done and maintains the integrity of the data.

Scott Fagen
z/OS Core Technology Design
IBM Poughkeepsie

--
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

Re: Why is there JOB scope for DSN ENQ's anyway?

[Shmuel Metz (Seymour J.)]

In <[EMAIL PROTECTED]>, on 05/22/2007
   at 08:37 AM, Paul Gilmartin <[EMAIL PROTECTED]> said:

>You will reacquire them when that other job DEQs them.  This is
>scarcely different from waiting for resources before the first step,
>save that the potential damage from cancelling a job between steps is
>greater than from cancelling before the first step.

It is significantly different, because another job might have altered
the data between the steps.
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see  
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

--
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

Re: Why is there JOB scope for DSN ENQ's anyway?

[Shmuel Metz (Seymour J.)]

In <[EMAIL PROTECTED]>, on 05/23/2007
   at 04:10 PM, "Robert A. Rosenberg" <[EMAIL PROTECTED]> said:

>Just make it a private/undocumented interface (as has been done with 
>other internal functions such as SuperLocate and others) and 
>restrict its use to ONLY the Initiator (and possibly other IBM 
>routines that could be more efficient by its availability). 

That is an unnecessary and insufficient condition. I see no risk in
making it a GUPI, while making it private does not resolve the problem
of a GRSplex with some members not having the functionality. By all
means submit a requirement, with a sound business case, but don't ask
for an early implementation; if you got one you'd be sorry. It will
undoubtedly take IBM some serious work to get the GRS aspect right.
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see  
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

--
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

Re: Why is there JOB scope for DSN ENQ's anyway?

[Paul Gilmartin]

On Wed, 23 May 2007 11:13:46 -0500, Scott Fagen wrote:

>On Wed, 23 May 2007 00:00:52 -0400, Robert A. Rosenberg wrote:
>
>>Since as I noted, the Support is easy to add (as I documented)
>
... but I'd say, certainly more than one man-day.  The mere administrative
burden for any change exceeds that.

>Unfortunately, "because it's easy" is not considered a compelling business
>case at IBM.
>
Would repairing a defect be considered (part of) a business case?

I was sensitized to this matter many years ago when I learned that
under certain conditions of contention attempting to DYNALLOC a data
set with options NEW and CATALOG can fail and leave the data set on
a volume not catalogued and not deleted.  I discovered this with
considerable discomfort only when I had run the job enough times
and it had failed enough times (usually it succeeded) that I had
a copy of the problem data set on every storage volume on the floor.

A dedicated IBM developer researched the problem and sought a solution.
Finally, he reported to me that under the design requirements of
DYNALLOC, and lacking the facility to downgrade an ENQ, no solution
was possible.  (I would have changed the specifications of DYNALLOC,
since the problem I reported demonstrated in itself that the specification
was not being met.)  With an ENQ downgrade facility, the problem
could easily have been solved within the constraints of the DYNALLOC
specification.

And, finally, to throw an additional wrinkle Robert's way, suppose:

ALLOCATE DD(E) DSN(FOO.BAR) OLD
ALLOCATE DD(S) DSN(FOO.BAR) SHR
FREE DD(E)

A programmer might reasonably expect this would leave a SHR ENQ
on SYSDSN FOO.BAR.  What component should do the accounting, and
what's the algorithm?  But perhaps this hardly more complex than
what is done nowadays when a data set name is statically allocated
in JCL, then multiply allocated to different DDNAMEs and FREEd
dynamically within the job step.

-- gil

--
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

Re: Why is there JOB scope for DSN ENQ's anyway?

[Robert A. Rosenberg]

At 08:37 -0500 on 05/22/2007, Paul Gilmartin wrote about Re: Why is 
there JOB scope for DSN ENQ's anyway?:



 >Note: I acknowledge that there also needs to be updates to the ENQ

and ISGENQ macros to request this option and a new flag bit in their
Parm fields. That and what happens if you make the request on a
system that is missing the support is the bigger problem than making
the few lines of code change to support the capability.


The format of the new parameter list needs to be such that it is invalid
on a system that is missing the support.


As I was typing one of my replies yesterday, I rethought the issue 
and realized we got off-track. What we are addressing (at least 
initially) is a solution to the issue of the Initiator holding the 
EXC ENQ longer than it needs to (ie: During Job Steps where a SHR ENQ 
is adequate since no Job Steps from this point until Job Term need 
the EXC ENQ). The updating of the ENQ code to support the EXC->SHR 
downgrade request and the updating of the Initiator code to make this 
request at Step Term of the last step that needs the EXC ENQ when one 
or more steps only need a SHR ENQ will fulfill this need.


Our desire to want the request for this function to be bullet-proof 
so that it will trigger a failure if issued on a system without the 
support is a non-issue since there is no need to make this a general 
usage interface AT THIS POINT IN TIME. Just make it a 
private/undocumented interface (as has been done with other internal 
functions such as SuperLocate and others) and restrict its use to 
ONLY the Initiator (and possibly other IBM routines that could be 
more efficient by its availability). The Initiator can make the 
request without any need to update the SYS1.MACLIB versions of the 
ENQ and ISGENQ macros (or their generated parameter list). Since the 
only routine that is issuing the request is the Initiator, it will 
automatically be running on a system that has the needed enhanced ENQ 
support. Since this facility only gets used by the Initiator, you do 
not have the exposure that would exist if it were made a standard 
User Interface or one that could also (under NDA) be used by 3-Party 
Products.


Note: I have not looked at the format of the ISGENQ parmlist but if 
it has some version level field that might solve the incompatible 
format issue IF/WHEN the EXC->SHR capability were made a general-use 
function. That issue is for the future since all that is needed RIGHT 
NOW is to allow the Initiator to use it.


--
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

Re: Why is there JOB scope for DSN ENQ's anyway?

[Scott Fagen]

On Wed, 23 May 2007 00:00:52 -0400, Robert A. Rosenberg <[EMAIL PROTECTED]>
wrote:

>Can you PLEASE explain why there was/is support for a SHR->EXC
>Upgrade...

No, I cannot.  The original support predates the library system that we used
before the one we are using now (the archaeological digs go down to the MVS
V1 strata), implying that the code was written before I finished high
school.  Best guess is, "because someone needed it."  There are plenty of
uses of ENQ beyond the serialization of datasets (SYSDSN).  I am aware of a
number of RET=CHNG uses within the BCP.

>Since as I noted, the Support is easy to add (as I documented) 

Unfortunately, "because it's easy" is not considered a compelling business
case at IBM.

>there is no downlevel exposure if it is initially restricted to use
>by the Initiator 

No, you would also have to ensure that the downgrade support is understood
by _all_ systems in a GRS ring, GRS Star and MII complex.  Otherwise an
uplevel system may create havoc by implying a grant of another system's
request when that system doesn't understand that a downgrade is possible. 
This exposure implies that 'compatibility PTFs' would be required for all
in-service releases of GRS and MII.

Scott Fagen
z/OS Core Technology Design
IBM Poughkeepsie

--
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

Re: Why is there JOB scope for DSN ENQ's anyway?

[Robert A. Rosenberg]

At 21:48 -0500 on 05/22/2007, Scott Fagen wrote about Re: Why is 
there JOB scope for DSN ENQ's anyway?:



Why doesn't initiator/terminator downgrade the ENQ from EXC to SHR when the
job has only DISP=SHR interest in the dataset for any of the remaining job
steps.  The answer clearly distinguishes where the deficiency lies in the
system (GRS, not Allocation).

If the question is "why isn't there a RET=CHANGE variant for altering EXC to
SHR ownership in ENQ (and/or ISGENQ)?" the answer is, most surely, "because
IBM has never seen sufficient business justification to implement 
the function."


Since as I noted, the Support is easy to add (as I documented) and 
there is no downlevel exposure if it is initially restricted to use 
by the Initiator (just update the Initiator Code to do the EXC->SHR 
downlevel ENQ at the point where all subsequent steps are DISP=SHR). 
Both the Initiator and ENQ support will be at the same level so you 
do not run into the attempt to run the new code against an old ENQ or 
the macro parm support that would occur if it were a USER-CODE 
supported feature. That Initiator update might actually take a few 
man-days (in addition to the man-hour or so to the ENQ code). You can 
postpone the availability to USER-CODE via new ENQ/ISGENQ macros 
until the problem of handling the accidental attempt to issue the 
request on a downlevel system is addressed. I think that a automatic 
business case can be made just based on the improved efficiency of 
the Initiator.



 >

See Robert Rosenberg's recent well-reasoned contribution on this
topic:

   Linkname: Re: Why is there JOB scope for DSN ENQ's anyway?
URL: http://bama.ua.edu/cgi-bin/wa?A2=ind0705&L=ibm-main&P=195906


So, I'd have to guess, based on the insulting tones, that you and Mr.
Rosenberg have some resentment about this function not being implemented.


I do not regard my query about why this glaring design flaw in ENQ is 
not being addressed (even if the usage of the enhanced support is 
restricted to the Initiator initially) as insulting (or do you regard 
my characterization of the original/current design of ENQ lacking a 
EXC->SHR Downgrade capability as "poor"/"flawed" as insulting?).


I am doing exactly what a SHARE Requirement is supposed to do - Point 
out a lack of functionality and provide an suggestion as to one way 
to rectify the lack. I do not have access to the SHARE Request List 
but I'd be surprised if there has not been one already submitted (or 
at least proposed) about this exact issue (the lack of a EXC->SHR 
downgrade at the job step boundary between DISP=OLD and DISP=SHR 
steps).


IMO, the lack of a fix in progress amounts to a deliberate crippling 
of the Initiator since the fix is so easy to make (so long as you 
make ENQ part initially an Authorized User facility and restrict its 
user-base to the Initiator). If you feel that my estimates of the 
ease of writing the needed code understates the effort needed, I 
welcome your estimate of the effort and/or pointing out where I am 
mistaken about what needs to be done.


--
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

Re: Why is there JOB scope for DSN ENQ's anyway?

[Robert A. Rosenberg]

At 13:17 -0500 on 05/22/2007, Scott Fagen wrote about Re: Why is 
there JOB scope for DSN ENQ's anyway?:



On Sat, 19 May 2007 20:59:40 -0500, Paul Gilmartin <[EMAIL PROTECTED]>
wrote:


On Sat, 19 May 2007 20:52:05 -0300, Clark Morris wrote:


 ...  If the ENQ is exclusive for the first step and
shared for the second, it will be changed by the initiator/terminator
between steps.


Nope.

Wishful thinking.

But why not?


ENQ RET=CHNG only supports 'upgrade' from SHR to EXC, not 'downgrade' from
EXC to SHR.  DEQing and re-ENQing may put you behind some waiting request,
which would expose you to deadly embraces.


Can you PLEASE explain why there was/is support for a SHR->EXC 
Upgrade (which has an almost 100% probability of not being doable due 
to some other task sharing your SHR ENQ status - IOW: Will only work 
when you are the sole ENQ'er in the first place) when the 100% 
Guaranteed to Succeed EXC->SHR Downgrade (since all it entails is 
updating the ENQ E/S field to SHR and acting as if you were the first 
SHR waiter with some OTHER task having just done the DEQ - IOW: You 
keep the ENQ but now as SHR and all the tasks who were waiting for 
you to DEQ [up until the first EXC waiter] get released)?


What was the original justification for the SHR->EXC support (even 
though it has timing restrictions that make it impossible to use 
consistently) while the design DELIBERATELY excluded EXC->SHR support 
that will ALWAYS work and would prevent the unnecessary holding of 
the EXE lock in Job Steps when only a SHR is needed (as well as other 
cases where a user written task needs to start with an EXC ENQ but 
only needs a SHR ENQ for the rest of the job step once the EXC 
protected work has been done)? As others have pointed out the 
rectification of this design flaw/decision is mired in the need to 
insure that the attempt to issue this request on a system that does 
not support it is detected and dealt with. If pushed, I think I can 
come up with a macro expansion that will be able to check for the 
support (by chasing and CVT anchored chain) and issue an ABEND when 
needed although it would be a major kluge of an expansion. The 
alternative, as noted, is to come up with an updated ENQ/ISGENQ parm 
list that will trigger an error if feed to a downlevel ENQ/ISGENQ 
routine.




Scott Fagen
z/OS Core Technology Design
IBM Poughkeepsie


--
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

Re: Why is there JOB scope for DSN ENQ's anyway?

[Scott Fagen]

On Tue, 22 May 2007 16:37:14 -0500, Paul Gilmartin <[EMAIL PROTECTED]>
wrote:

>On Tue, 22 May 2007 13:17:16 -0500, Scott Fagen wrote:
>>>>
>>>> ...  If the ENQ is exclusive for the first step and
>>>>shared for the second, it will be changed by the initiator/terminator
>>>>between steps.
>>>>
>>>Nope.
>>>
>>>Wishful thinking.
>>>
>>>But why not?
>>
>>ENQ RET=CHNG only supports 'upgrade' from SHR to EXC, not 'downgrade' from
>>EXC to SHR.  ...
>>
>That answers nothing; it's the impatient parent telling the curious
>child, "Because!"  The question remains, "But why not?"

No, it answers the question following the refutation stated in your post: 
Why doesn't initiator/terminator downgrade the ENQ from EXC to SHR when the
job has only DISP=SHR interest in the dataset for any of the remaining job
steps.  The answer clearly distinguishes where the deficiency lies in the
system (GRS, not Allocation).

If the question is "why isn't there a RET=CHANGE variant for altering EXC to
SHR ownership in ENQ (and/or ISGENQ)?" the answer is, most surely, "because
IBM has never seen sufficient business justification to implement the function."

>
>See Robert Rosenberg's recent well-reasoned contribution on this
>topic:
>
>   Linkname: Re: Why is there JOB scope for DSN ENQ's anyway?
>URL: http://bama.ua.edu/cgi-bin/wa?A2=ind0705&L=ibm-main&P=195906

So, I'd have to guess, based on the insulting tones, that you and Mr.
Rosenberg have some resentment about this function not being implemented. 
C'est la vie.

Scott Fagen
z/OS Core Technology Design
IBM Poughkeepsie

--
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

Re: Why is there JOB scope for DSN ENQ's anyway?

[Paul Gilmartin]

On Tue, 22 May 2007 13:17:16 -0500, Scott Fagen wrote:
>>>
>>> ...  If the ENQ is exclusive for the first step and
>>>shared for the second, it will be changed by the initiator/terminator
>>>between steps.
>>>
>>Nope.
>>
>>Wishful thinking.
>>
>>But why not?
>
>ENQ RET=CHNG only supports 'upgrade' from SHR to EXC, not 'downgrade' from
>EXC to SHR.  ...
>
That answers nothing; it's the impatient parent telling the curious
child, "Because!"  The question remains, "But why not?"

See Robert Rosenberg's recent well-reasoned contribution on this
topic:

   Linkname: Re: Why is there JOB scope for DSN ENQ's anyway?
URL: http://bama.ua.edu/cgi-bin/wa?A2=ind0705&L=ibm-main&P=195906

-- gil

--
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

Re: Why is there JOB scope for DSN ENQ's anyway?

[Scott Fagen]

On Sat, 19 May 2007 20:59:40 -0500, Paul Gilmartin <[EMAIL PROTECTED]>
wrote:

>On Sat, 19 May 2007 20:52:05 -0300, Clark Morris wrote:
>>
>> ...  If the ENQ is exclusive for the first step and
>>shared for the second, it will be changed by the initiator/terminator
>>between steps.
>>
>Nope.
>
>Wishful thinking.
>
>But why not?

ENQ RET=CHNG only supports 'upgrade' from SHR to EXC, not 'downgrade' from
EXC to SHR.  DEQing and re-ENQing may put you behind some waiting request,
which would expose you to deadly embraces.

Scott Fagen
z/OS Core Technology Design
IBM Poughkeepsie

--
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

Re: Why is there JOB scope for DSN ENQ's anyway?

[Paul Gilmartin]

On Tue, 22 May 2007 09:12:10 -0300, Shmuel Metz (Seymour J.) wrote:
>
>>If all ENQs now performed with job scope were performed with job step
>>scope, the "deadly embrace" would equally well be avoided.
>
>But the data sets would no longer be protected against concurrent
>updates.
>
Thank you.  I had overlooked that.  (I might say "intervening" rather
than "concurrent".)

-- gil

--
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

Re: Why is there JOB scope for DSN ENQ's anyway?

[Bruce Black]

ending up in a deadly embrace (where two jobs each want the same ENQs 
but can not get them).

Actually a deadly embrance (the old "fatatl fondle") is when
task 1 holds resource A but needs resource B
task 2 holds resource B but needs resource A

A job could end up in a fatal fondle if it didn't acquire all its 
resources at the beginning, all at once.


--
Bruce A. Black
Senior Software Developer for FDR
Innovation Data Processing 973-890-7300
personal: [EMAIL PROTECTED]
sales info: [EMAIL PROTECTED]
tech support: [EMAIL PROTECTED]
web: www.innovationdp.fdr.com

--
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

Re: Why is there JOB scope for DSN ENQ's anyway?

[Shmuel Metz (Seymour J.)]

In <[EMAIL PROTECTED]>, on 05/18/2007
   at 04:08 PM, Paul Gilmartin <[EMAIL PROTECTED]> said:

>If all ENQs now performed with job scope were performed with job step
>scope, the "deadly embrace" would equally well be avoided.

But the data sets would no longer be protected against concurrent
updates.
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see  
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

--
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

Re: Why is there JOB scope for DSN ENQ's anyway?

[Paul Gilmartin]

On Mon, 21 May 2007 22:41:55 -0400, Robert A. Rosenberg wrote:

>At 18:43 -0500 on 05/21/2007, Paul Gilmartin wrote about Re: Why is
>there JOB scope for DSN ENQ's anyway?:
>
>There is a simple reason. The ENQs are done before the job is started
>so that all of the datasets are available to the steps. If you
>release and reacquire the ENQs, there is a possibility that you will
>not be able to reacquire them (due to some other job grabbing them
>
You will reacquire them when that other job DEQs them.  This is
scarcely different from waiting for resources before the first
step, save that the potential damage from cancelling a job between
steps is greater than from cancelling before the first step.

>between your DEQ and ENQ) or even worse, ending up in a deadly
>embrace (where two jobs each want the same ENQs but can not get
>
No.  Deadly embrace is not possible because the job requesting
resources holds none.

>them). The way it works now, you wait until everything is available
>and then run, doing DEQs for those datasets that are no longer needed.
>
>The question of holding a Exclusive ENQ when you only need a Shared
>ENQ (ie: Exclusive in Step1 and continuing to hold Exclusive when
>only needing Shared in subsequent steps) is due to a poor ENQ design
>
(a man sharing my own convictions)

>Note: I acknowledge that there also needs to be updates to the ENQ
>and ISGENQ macros to request this option and a new flag bit in their
>Parm fields. That and what happens if you make the request on a
>system that is missing the support is the bigger problem than making
>the few lines of code change to support the capability.
>
The format of the new parameter list needs to be such that it is invalid
on a system that is missing the support.

-- gil

--
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

Re: Why is there JOB scope for DSN ENQ's anyway?

[Robert A. Rosenberg]

At 18:43 -0500 on 05/21/2007, Paul Gilmartin wrote about Re: Why is 
there JOB scope for DSN ENQ's anyway?:



On Mon, 21 May 2007 16:01:57 -0700, Edward Jaffe wrote:


I've never heard of an ENQ with job scope. A quick look at the ISGENQ
service shows the following scope values:


OK.  We were being careless, and I may be at fault for starting it.

The issue is why ENQs are issued at the beginning of the job and
held until the last step that uses the data set name, rather
than being dequeued after each step and re-enqueued at the next
step, and for only the data set names used in that step.


There is a simple reason. The ENQs are done before the job is started 
so that all of the datasets are available to the steps. If you 
release and reacquire the ENQs, there is a possibility that you will 
not be able to reacquire them (due to some other job grabbing them 
between your DEQ and ENQ) or even worse, ending up in a deadly 
embrace (where two jobs each want the same ENQs but can not get 
them). The way it works now, you wait until everything is available 
and then run, doing DEQs for those datasets that are no longer needed.


The question of holding a Exclusive ENQ when you only need a Shared 
ENQ (ie: Exclusive in Step1 and continuing to hold Exclusive when 
only needing Shared in subsequent steps) is due to a poor ENQ design 
that has no provision for altering an Exclusive to a Shared (while 
having the useless Shared to Exclusive capability that is almost 
impossible to be able to use due to the probability that some other 
task shares your Shared ENQ lock). The amount of coding work needed 
to fix this design flaw is under one man day (just flip the E/S flag 
in the ENQ queue record from E to S and then drive the routine that 
handles a DEQ of an Exclusive ENQ that is followed on its queue by a 
waiting Shared ENQ [IOW: Take entries 2+ out of hold and assign them 
as Shared owners of the ENQ until you run off the end of the list or 
encounter another Exclusive ENQ request]). IBM has repeated refused 
to devote the minimal resources needed to fix this problem.


Note: I acknowledge that there also needs to be updates to the ENQ 
and ISGENQ macros to request this option and a new flag bit in their 
Parm fields. That and what happens if you make the request on a 
system that is missing the support is the bigger problem than making 
the few lines of code change to support the capability.




"Duration" would have been a better word than "scope", which is
already used in the other sense.

-- gil


--
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

Re: Why is there JOB scope for DSN ENQ's anyway?

[Paul Gilmartin]

On Mon, 21 May 2007 16:01:57 -0700, Edward Jaffe wrote:
>
>I've never heard of an ENQ with job scope. A quick look at the ISGENQ
>service shows the following scope values:
>
OK.  We were being careless, and I may be at fault for starting it.

The issue is why ENQs are issued at the beginning of the job and
held until the last step that uses the data set name, rather
than being dequeued after each step and re-enqueued at the next
step, and for only the data set names used in that step.

"Duration" would have been a better word than "scope", which is
already used in the other sense.

-- gil

--
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

Re: Why is there JOB scope for DSN ENQ's anyway?

[Edward Jaffe]

Farley, Peter x23353 wrote:

Picking up on something Paul G. said in another thread, I realized I have
never known *why* the system issues JOB scope ENQ's on DSN's.

I do realize that it is most probably to avoid an ENQ "deadly embrace"
somewhere along the line, but for the life of me (well, and maybe because
it's Friday) I can't think why a DSN ENQ would be JOB scope instead of STEP
scope.  At least not by default, anyway.
  


I've never heard of an ENQ with job scope. A quick look at the ISGENQ 
service shows the following scope values:



SCOPE=STEP
   indicates that the resource is
   serialized only within an
   address space.  If STEP is
   specified, a request for the
   same Qname and Rname from a
   program in another address
   space denotes a different
   resource.

SCOPE=SYSTEM
   indicates that the resource is
   serialized across all address
   spaces in a system.

SCOPE=SYSTEMS
   indicates that the resource is
   serialized across all systems
   in a GRS Star or GRS Ring
   complex.

SCOPE=SYSPLEX
   indicates that the resource is
   serialized across all systems
   in a GRS Star sysplex or GRS
   ring. (Same as scope SYSTEMS.)


--
Edward E Jaffe
Phoenix Software International, Inc
5200 W Century Blvd, Suite 800
Los Angeles, CA 90045
310-338-0400 x318
[EMAIL PROTECTED]
http://www.phoenixsoftware.com/

--
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

Re: Why is there JOB scope for DSN ENQ's anyway?

[Paul Gilmartin]

On Sat, 19 May 2007 20:52:05 -0300, Clark Morris wrote:
>
> ...  If the ENQ is exclusive for the first step and
>shared for the second, it will be changed by the initiator/terminator
>between steps.
>
Nope.

Wishful thinking.

But why not?

-- gil

--
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

Re: Why is there JOB scope for DSN ENQ's anyway?

[Clark Morris]

On 18 May 2007 13:30:32 -0700, in bit.listserv.ibm-main you wrote:

>Picking up on something Paul G. said in another thread, I realized I have
>never known *why* the system issues JOB scope ENQ's on DSN's.
>
>I do realize that it is most probably to avoid an ENQ "deadly embrace"
>somewhere along the line, but for the life of me (well, and maybe because
>it's Friday) I can't think why a DSN ENQ would be JOB scope instead of STEP
>scope.  At least not by default, anyway.
>
>I suppose if you create a dataset in step A and then use it DISP=SHR in step
>B (or F or Z, way down the line), if it were not JOB scope ENQueued some
>other job could come in-between your create and use steps and delete it on
>you, or update it in some clever but unscrupulous way, but I really can't
>think of a scenario that means JOB scope ENQ's are required.
>
>TIA for curing my ignorance on this subject.

AS I understand it, The ENQ for a data set is from start of job until
the last using step.  If the ENQ is exclusive for the first step and
shared for the second, it will be changed by the initiator/terminator
between steps.  If no further step requires the data set the ENQ is
dropped.  JES3 may do some additional things.  Since the Job is the
unit of work that requires the data set it should have it for as long
as it needs it.  FREE=CLOSE also influences things.
>
>Peter

--
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

Re: Why is there JOB scope for DSN ENQ's anyway?

[Paul Gilmartin]

On Fri, 18 May 2007 16:30:43 -0400, Farley, Peter x23353 <[EMAIL PROTECTED]> 
wrote:
>
>I do realize that it is most probably to avoid an ENQ "deadly embrace"
>somewhere along the line, but for the life of me (well, and maybe because
>it's Friday) I can't think why a DSN ENQ would be JOB scope instead of STEP
>scope.  At least not by default, anyway.
> 
If all ENQs now performed with job scope were performed with job step
scope, the "deadly embrace" would equally well be avoided.

>I suppose if you create a dataset in step A and then use it DISP=SHR in step
>B (or F or Z, way down the line), if it were not JOB scope ENQueued some
>other job could come in-between your create and use steps and delete it on
>you, or update it in some clever but unscrupulous way, but I really can't
>think of a scenario that means JOB scope ENQ's are required.
>
Additionally, there's initiator hogging, where one job holds a
resource and other jobs are waiting for it, each monopolizing an
an initiator.  While job scope ENQs are no less susceptible to
initiator hogging than job step scope (perhaps even more), it may
become necessary for an operator to cancel, reset, and restart
jobs in order to resume the work flow.  This is more safely done
if the wait occurs before Step 1 than between steps 41 and 42.

-- gil

--
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

Why is there JOB scope for DSN ENQ's anyway?

[Farley, Peter x23353]

Picking up on something Paul G. said in another thread, I realized I have
never known *why* the system issues JOB scope ENQ's on DSN's.

I do realize that it is most probably to avoid an ENQ "deadly embrace"
somewhere along the line, but for the life of me (well, and maybe because
it's Friday) I can't think why a DSN ENQ would be JOB scope instead of STEP
scope.  At least not by default, anyway.

I suppose if you create a dataset in step A and then use it DISP=SHR in step
B (or F or Z, way down the line), if it were not JOB scope ENQueued some
other job could come in-between your create and use steps and delete it on
you, or update it in some clever but unscrupulous way, but I really can't
think of a scenario that means JOB scope ENQ's are required.

TIA for curing my ignorance on this subject.

Peter
--
As of 04/01/2007 I have a new email address, so please update your address
book: Peter (dot) Farley (at) broadridge (dot) com

This message and any attachments are intended only for the use of the addressee 
and
may contain information that is privileged and confidential. If the reader of 
the 
message is not the intended recipient or an authorized representative of the
intended recipient, you are hereby notified that any dissemination of this
communication is strictly prohibited. If you have received this communication in
error, please notify us immediately by e-mail and delete the message and any
attachments from your system.

--
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