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
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
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
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
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
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
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
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
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
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
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.
snip
And what was the outcome of the incident?
It was so long ago that I was probably not submitting
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
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
remains allocated or, more to the point, enqueued, is
another matter.
From: Paul Gilmartin [EMAIL PROTECTED]
Reply-To: IBM Mainframe Discussion List IBM-MAIN@BAMA.UA.EDU
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
-
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
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*
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
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
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
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
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
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
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
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
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.
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
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.
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
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
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.
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
is there JOB scope for DSN ENQ's anyway?
URL: http://bama.ua.edu/cgi-bin/wa?A2=ind0705L=ibm-mainamp;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
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
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
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
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
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
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
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
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
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
41 matches
Mail list logo
