How do I use the ISGENQ macro in such a way that the ENQ lasts for the life
of the entire job (or several job steps) and not just for the life of a
single job-step? Would specifying the TCB address of the initiator TCB on
the TCB parameter work? Any better ideas?
Thanks,
Steff Gladstone
---
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf
Of Steff Gladstone
Sent: Monday, April 20, 2015 10:13 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: ENQ for the life of the job
How do I use the ISGENQ macro in such a way that the ENQ lasts for
On Mon, Apr 20, 2015 at 9:13 AM, Steff Gladstone
wrote:
> How do I use the ISGENQ macro in such a way that the ENQ lasts for the life
> of the entire job (or several job steps) and not just for the life of a
> single job-step? Would specifying the TCB address of the initiator TCB on
> the TCB pa
Greetings,
How do I use the ISGENQ macro in such a way that the ENQ lasts for the life
of the entire job (or several job steps) and not just for the life of a
single job-step? Would specifying the TCB address of the initiator TCB on
the TCB parameter work? Any better ideas?
Thanks,
Steff Gladst
| M: 512-627-3803
> E: cblaic...@syncsort.com
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Steff Gladstone
> Sent: Monday, April 20, 2015 10:13 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: ENQ for the life
On Mon, Apr 20, 2015 at 9:41 AM, Steff Gladstone
wrote:
> The ENQ has to be transparent to the JCL. Could I dynamically allocate a
> dataset with DISP=(OLD,PASS)? As I recall the dynamic allocation does not
> permit the use of PASS.
>
Hum, I'm going to go way out on a limb and start sawing.
I suppose a final job-step to do the DEQ with COND=EVEN would not always do
the trick. As I recall there are some types of abends that flush the job
including steps with COND=EVEN, right?
On Mon, Apr 20, 2015 at 6:09 PM, John McKown
wrote:
> On Mon, Apr 20, 2015 at 9:41 AM, Steff Gladstone <
> s
616.653.8429
f 616.653.2717
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf
Of Steff Gladstone
Sent: Monday, April 20, 2015 11:18 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: ENQ for the life of the job
I suppose a final job-step to do
>
>
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Steff Gladstone
> Sent: Monday, April 20, 2015 11:18 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: ENQ for the life of the job
>
> I suppose a fi
Rapids, MI 49546 MD RSCB2H p 616.653.8429 f
> 616.653.2717
>
>
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> On Behalf Of Steff Gladstone
> Sent: Monday, April 20, 2015 11:18 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
MAIN@LISTSERV.UA.EDU
Subject: Re: ENQ for the life of the job
As previously suggested, initial IEFBR14 step (e.g.)
//step1 exec pgm=iefbr14
//dd1dd dsn=hlq.program,disp=(mod,pass),space=(trk,1,1),unit=sysda
And simply never reference hlq.program in the jobstream.
This will prevent multiple
On Mon, Apr 20, 2015 at 10:18 AM, Steff Gladstone wrote:
> I suppose a final job-step to do the DEQ with COND=EVEN would not always do
> the trick. As I recall there are some types of abends that flush the job
> including steps with COND=EVEN, right?
>
>
Very true. My favorite: S40D with a nice
Steff Gladstone wrote:
>The job is performing a change management system operation (moving a new
>program version to production, saving previous generations, providing for
>possible fallback, etc.). The operation for various reasons must be performed
>in several job steps. We want to ENQ on th
On Mon, Apr 20, 2015 at 10:36 AM, Steff Gladstone wrote:
> The job is performing a change management system operation (moving a new
> program version to production, saving previous generations, providing for
> possible fallback, etc.). The operation for various reasons must be
> performed in sev
> > I suppose a final job-step to do the DEQ with COND=EVEN would not
always do
> > the trick. As I recall there are some types of abends that flush the
job
> > including steps with COND=EVEN, right?
> >
> >
> Very true. My favorite: S40D with a nice message about the initiator
being
> terminat
mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf
Of Elardus Engelbrecht
Sent: Monday, April 20, 2015 1:24 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: ENQ for the life of the job
Steff Gladstone wrote:
>The job is performing a change management system operation (moving a new
>program version t
Jousma, David wrote:
... I'd use standard JCL DISP=OLD processing on a dummy dataset name that includes the program name as part of it.
Maybe someone mentioned this already, but I was thinking even simpler -
use the same job name each time if the user has no control over the
JCL, with JES2
Thank you all for for help. The obvious question that remains is: how
does the operating systen itself maintain a continuous ENQ over several job
steps for a dataset allocated in the first step with disp=(mod,pass)? Is
there a special privileged ENQ operation that only the operating system has
a
From your other posts I understand that you don't want to change JCL,
but you are able to change the code of the relevant programs and you know
all the programs that are part of this operation and could do "other
operations
or changes" affecting your change management system operation.
So: have
On Tue, Apr 21, 2015 at 3:00 AM, Steff Gladstone
wrote:
> Thank you all for for help. The obvious question that remains is: how
> does the operating systen itself maintain a continuous ENQ over several job
> steps for a dataset allocated in the first step with disp=(mod,pass)? Is
> there a spe
Even without modifying the SWA with information for the DD, as you
suggested earlier?
On Tue, Apr 21, 2015 at 2:50 PM, John McKown
wrote:
> On Tue, Apr 21, 2015 at 3:00 AM, Steff Gladstone <
> steff.gladst...@gmail.com>
> wrote:
>
> > Thank you all for for help. The obvious question that remai
On Tue, 21 Apr 2015 11:00:20 +0300, Steff Gladstone wrote:
>how
>does the operating systen itself maintain a continuous ENQ over several job
>steps for a dataset allocated in the first step with disp=(mod,pass)?
It isn't so much a question of "How" as "Who".
The Initiator performs the ENQ and AT
In
,
on 04/20/2015
at 05:13 PM, Steff Gladstone said:
>How do I use the ISGENQ macro in such a way that the ENQ lasts for
>the life of the entire job (or several job steps) and not just for
>the life of a single job-step?
Cautiously and with trepidation.
>Would specifying the TCB address of
In
,
on 04/20/2015
at 10:09 AM, John McKown said:
>I wonder if it would be possible to do a directed ENQ of a SYSDSN
>to the initiator TCB and then modify the SWA to "generate" the i
>nternal information for a DD and place that as if it had been in
>a DD in the JCL.
Possible, yes. Easy or
On Mon, Apr 20, 2015 at 8:37 PM, Shmuel Metz (Seymour J.) <
shmuel+ibm-m...@patriot.net> wrote:
> In
> ,
> on 04/20/2015
>at 10:09 AM, John McKown said:
>
> >I wonder if it would be possible to do a directed ENQ of a SYSDSN
> >to the initiator TCB and then modify the SWA to "generate" the i
On Tue, Apr 21, 2015 at 7:00 AM, Steff Gladstone
wrote:
> Even without modifying the SWA with information for the DD, as you
> suggested earlier?
>
Yes, you can do the directed ENQ yourself without modifying the SWA.
Which, by the by, I _mentioned_, not _suggested_. At least, I didn't mean
for
Sorry, John. My question was unclear. It was referring to your earlier
remarks above:
Thinking about it a bit more, given what Mr. Relson
said about RTM, doing this _should_ work even if the initiator
terminates
abnormally since RTM should clean up the ENQs during EOM processing.
A
At 06:50 -0500 on 04/21/2015, John McKown wrote about Re: ENQ for the
life of the job:
ÐThe initiator (in general terms) is what reads the Ðparsed JCL and creates
the SWA control blocks which represent the job. This code then knows the
DSNs in the job and issues a single ENQ for _all_ of them
On Tue, 21 Apr 2015 11:20:24 -0400, Robert A. Rosenberg wrote:
>
>... a IMO major design flaw in the ENQ process
>the Initiator can be forced to hold an ENQ for subsequent steps where
>it is no longer needed. The case I am talking about is there is no
>way to convert an EXC ENQ into a SHR one.
>
W
On Tue, 21 Apr 2015 11:20:24 -0400, Robert A. Rosenberg wrote:
>... due to a IMO major design flaw in the ENQ process
>the Initiator can be forced to hold an ENQ for subsequent steps where
>it is no longer needed. The case I am talking about is there is no
>way to convert an EXC ENQ into a SHR on
On Tue, Apr 21, 2015 at 10:20 AM, Robert A. Rosenberg
wrote:
> At 06:50 -0500 on 04/21/2015, John McKown wrote about Re: ENQ for the life
> of the job:
>
> ŠThe initiator (in general terms) is what reads the Šparsed JCL and
>> creates
>> the SWA control blocks which repr
On Tue, Apr 21, 2015 at 10:11 AM, Steff Gladstone wrote:
> Sorry, John. My question was unclear. It was referring to your earlier
> remarks above:
>
> Thinking about it a bit more, given what Mr. Relson
> said about RTM, doing this _should_ work even if the initiator
> terminates
>
on List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf
Of Steff Gladstone
Sent: 21 April 2015 16:12
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: ENQ for the life of the job
Sorry, John. My question was unclear. It was referring to your earlier remarks
above:
Thinking about it a bit more, given wh
riginal Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf
Of J O Skip Robinson
Sent: Monday, April 20, 2015 11:25 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: EXTERNAL: Re: ENQ for the life of the job
OP is clear about not wanting to change JCL. I've never tried
In
,
on 04/21/2015
at 11:00 AM, Steff Gladstone said:
>The obvious question that remains is: how does the operating
>systen itself maintain a continuous ENQ over several job steps for
>a dataset allocated in the first step with disp=(mod,pass)?
The Initiator does the ENQ.
--
Shmuel
On Tue, 21 Apr 2015 11:05:51 -0500, John McKown wrote:
>
>The ability to atomically downgrade an ENQ from EXC to SHR is now/soon to
>be available in z/OS. I don't remember if it is a PTF or release 2.1.1 .
>
In:
z/OS 2.1.0>z/OS MVS>z/OS MVS JCL Reference>JOB statement>DSENQSHR
parameter>Overri
On Tue, 21 Apr 2015 16:39:00 +, Rob Scott wrote:
>No matter what you fiddle about with in SWA, these GRS resource manager
>routines will enable GRS to cleanup any underlying
>resources obtained by the task or address space.
Yes, but only for abnormal termination of the Initiator TCB, or fo
On Tue, 21 Apr 2015 18:01:10 -0500, Walt Farrell wrote:
>
>Yes, but only for abnormal termination of the Initiator TCB, or for failure of
>the entire address space. In normal or abnormal termination of the jobstep
>task those resource managers won't help the OP, and the ENQ would remain
>outstan
for the life of the job
Thank you all for for help. The obvious question that remains is: how
does the operating systen itself maintain a continuous ENQ over several job
steps for a dataset allocated in the first step with disp=(mod,pass)? Is
there a special privileged ENQ operation that
At 10:49 -0500 on 04/21/2015, Paul Gilmartin wrote about Re: ENQ for
the life of the job:
On Tue, 21 Apr 2015 11:20:24 -0400, Robert A. Rosenberg wrote:
>
... a IMO major design flaw in the ENQ process
the Initiator can be forced to hold an ENQ for subsequent steps where
it is no lon
-1468 . USA
Tel: +1.781.684.2305
Email: rsc...@rs.com
Web: www.rocketsoftware.com
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf
Of Walt Farrell
Sent: 22 April 2015 00:01
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: ENQ for the life of the job
I have found the discussion interesting, particularly in what has not been
said (or perhaps I missed it).
The OP asked about an ENQ. The post did not indicate what resource it
wanted to ENQ on (and as Tom Marchant point out, it is of course critical
that all players in a serialization game use
On Wed, 22 Apr 2015 07:44:29 -0400, Peter Relson wrote:
>
>Getting back to the OP, my first question would have been what they are
>trying to accomplish/serialize? If it's to keep one job from running while
>another is, then as has been suggested use of a specific data set
>*allocation* (even a rel
Paul Gilmartin wrote:
>The OP's peculiar constraint is that the serialization must be achieved with
>no change to existing JCL.
There must be a peculiar reason or two, or the OP is just prohibited to change
the JCL.
Why, oh why, did I suggested using automation to set a flag somewhere? Just
l
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Paul Gilmartin
> Sent: Wednesday, April 22, 2015 5:10 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: ENQ for the life of the job
>
> The OP's pe
Yup!
Charles
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf
Of retired mainframer
Sent: Wednesday, April 22, 2015 10:38 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: ENQ for the life of the job
> -Original Message-
> Fro
2015 5:10 AM
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: Re: ENQ for the life of the job
> >
> > The OP's peculiar constraint is that the serialization must be achieved
> > with no change to existing JCL.
>
> Does anyone else find it a little absurd that a trivial
On Wed, 22 Apr 2015 14:10:30 -0500, John McKown wrote:
>
>Total agreement. But I understand why. We have an occasional S0C7 due to
>the end user uploading bad data. My solution was to change a SORT control
>card in a stand alone SORT step. After over a month, this change is still
>pending research
On Wed, Apr 22, 2015 at 2:33 PM, Paul Gilmartin <
000433f07816-dmarc-requ...@listserv.ua.edu> wrote:
> On Wed, 22 Apr 2015 14:10:30 -0500, John McKown wrote:
> >
> >Total agreement. But I understand why. We have an occasional S0C7 due to
> >the end user uploading bad data. My solution was to
On Apr 22, 2015, at 2:10 PM, John McKown wrote:
---SNIP___
Total agreement. But I understand why. We have an occasional S0C7
due to
the end user uploading bad data. My solution was to change a SORT
control
card in a stand alone SORT
On 04/22/2015 12:38 PM, retired mainframer wrote:
>> -Original Message-
>> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
>> Behalf Of Paul Gilmartin
>> Sent: Wednesday, April 22, 2015 5:10 AM
>> To: IBM-MAIN@LISTSERV.UA.EDU
>>
On Thu, 23 Apr 2015 10:13:52 -0500, Joel Ewing wrote:
>One possible explanation for the no-JCL-change requirement
It seems to me that we have done a lot of guessing based upon
minimal information provided by the OP. The resource names that
would be specified by the ENQ are not clear. Nor is
One method for this sort of problems could be to in the current/existing job
begin with submitting a NEW job that does the DEQ. And serialize the new job
so it executes AFTER any of these problem jobs.
The new job could - if needed - do its own "result polling" for the old jobs.
Best Regar
e doing (and
have a TEST system to play with).
Dan
-Original Message-
From: Steff Gladstone
Sent: Monday, April 20, 2015 10:32 AM Newsgroups: bit.listserv.ibm-main
Subject: Fwd: ENQ for the life of the job
Greetings,
How do I use the ISGENQ macro in such a way that the ENQ lasts for th
54 matches
Mail list logo
