Joined: 26 Apr 2004 Posts: 4652 Location: Raleigh, NC, USA
Just keep your thought process simple. Keep in mind a few basic rules:
- The RESTART syntax is always going to be:
,RESTART=* - restart at the first jobstep and, if used, first procstep.
,RESTART=STEPNAME - restart at the specified job step. If stepname refers to an EXEC statement that invokes a procedure, the step name of the step within the procedure must also be specified (see below).
,RESTART=STEPNAME.PROCSTEPNAME - restart at the specified step of a procedure. Stepname identifies the EXEC statement of the job step that calls the procedure; procstepname identifies the EXEC statement of the procedure step. The step identified by procstepname must contain the PGM keyword rather than invoke a procedure.
- The RESTART parameter can only be used in the JOB statement or in a
/*JOBPARM statement (on a JES2 system).
Usually my peers discussed& they told in some interviews that
Restart a proc is
Restart=procname.procstepname
Dats y i confused vch i need to use
Jobstepname.procstepname or procname.procstepname
Thats why i confused is this applicable for instream& catalog procs both or only for catlog procs
In my organisation i never saw instream proc, mostly at which scenario organisations use instream procs?
which will restart the job at job step JS10 and proc PROC01 step STEP1, which is exactly the same as just re-submitting the same job.
or you can code ONLY one of these three:
Code:
//JOBA JOB ...,RESTART=JS10.STEP1
which will restart the job at job step JS10 and proc PROC01 step STEP1, just like above:
Code:
//JOBA JOB ...,RESTART=JS10.STEP2
which will restart the job at job step JS10 and proc PROC01 step STEP2:
Code:
//JOBA JOB ...,RESTART=JS10.STEP3
which will restart the job at job step JS10 and proc PROC01 step STEP3.
There are no other options. The ONLY way to get what is being asked is to either re-write the job to call PROC02 directly with the proper RESTART statement:
or re-write PROC01 so that it ONLY invokes PROC02, and re-write PROC02 so that STEP4 is the first step, or avoid the whole mess altogether and not nest your proc's. It's a bad practice.
Joined: 26 Apr 2004 Posts: 4652 Location: Raleigh, NC, USA
For the second question, an instream proc follows the exact same rules. I tested it out to make sure, and removed my original comment about not using RESTART for an instream proc, although personally I've never seen instream procs used for real, and it seems as if it would be just as easy to edit the job and just change the proc, submit the job, then cancel your edit.
I think your third question's been answered.
I'm going to make one final comment before I end my involvement with this topic. I'm going to run this by the other Moderators, but I think we need to start pushing you posters to provide only REAL-WORLD solutions, not these esoteric, theoretical ones, and to start pushing back to the interviewers if they expect you to answer them otherwise. The answers need to based on YOUR experiences with standards/procedures that YOU have followed. I may have to follow a different set of standards/procedures where I work, so my answer might be quite different than yours, but correct anyway. I think you'd be hard-pressed to find any production control environment where they'd do anything more than change the default RESTART command per YOUR specifications and then re-run the job. I seriously doubt any would allow someone to actually implement a job with nested procedures, with maybe a few allowable exceptions. I doubt there are any that are going to use IEBEDIT, change COND or IF/THEN/ELSE statements, or anything else. For anything more, you'll probably have to implement an emergency change request and provide them with an edited version of the job and/or procedures, which they would then submit as-is.
Joined: 03 Oct 2009 Posts: 1787 Location: Bloomington, IL
superk wrote:
There are no other options. The ONLY way to get what is being asked is to either re-write the job to call PROC02 directly with the proper RESTART statement:
or re-write PROC01 so that it ONLY invokes PROC02, and re-write PROC02 so that STEP4 is the first step, or avoid the whole mess altogether and not nest your proc's.
This seems not to be the case. Experimentation indicates that RESTART=STEP3.STEP4 is indeed efficacious (I'm running zOS 1.11.0, MVS SP7.1.1, and JES3, FWIW).
Joined: 03 Oct 2009 Posts: 1787 Location: Bloomington, IL
superk wrote:
I think you'd be hard-pressed to find any production control environment where they'd do anything more than change the default RESTART command per YOUR specifications and then re-run the job. I seriously doubt any would allow someone to actually implement a job with nested procedures, with maybe a few allowable exceptions. I doubt there are any that are going to use IEBEDIT, change COND or IF/THEN/ELSE statements, or anything else. For anything more, you'll probably have to implement an emergency change request and provide them with an edited version of the job and/or procedures, which they would then submit as-is.
Again, this does not seem to be the case.
For the past half-dozen years, I have done software tools development, which very seldom takes me within shouting distance of the production LPARs or the issuance process. From 1995-2002, however, I was involved in ADMing general ledger systems (varying in size from one Canadian to one North American and South American) for a certain large manufacturer of mainframe hardware and software. The rules for these production systems were basically two-fold:
If the system goes down, get it running ASAP.
In case of doubt, refer to rule #1.
The operators were under orders to make no modifications to a failed job...but to run any JCL that we handed them to resolve the situation. Any JCL; they were not to make reply, not to reason why, not to comment, "Gee, this looks awfully like a Rexx exec intended to transfer accounts receivable to your checking account" (and some of the operators were sharp enough to notice that), but run it. The responsibility was entirely ours, the service analysts; on problem calls, we'd be working from home, and, if any of us needed to perform jumonji giri, the kitchen and the knife block were only a few steps away (none of us did, although there were a couple of occasions when it looked like it might be the easy way out).
Standards and procedures may have changed, there and everywhere, and I do myself and my fellow analysts the honor of suggesting that the rawest of us yet had considerably more knowledge, experience, and ability than the typical querents in this forum, and could thus get away with tricks that no sane manager would let them try. Nonetheless, I think it may be short-sighted to assume that a plea of, "We tried industry-standard procedures, and they didn't work" will be accepted by a crisis manager who is imagining his bonuses for the next millennium spiraling down the drain.
Joined: 03 Oct 2009 Posts: 1787 Location: Bloomington, IL
superk wrote:
Anyone know how/why that works?
The manual indicates that that reference will work when overriding a DD statement in a nested procedure, so it's not unreasonable to suppose that the RESTART parameter would -- and does -- accept it.
Joined: 03 Oct 2009 Posts: 1787 Location: Bloomington, IL
kumar119119 wrote:
Akatsukami,tell me one thing,
i.e
If we give RESTART=STEP3.STEP4
is control directly goes to step3 even if we don't mention the JS10 in the RESTART, for this case is JS10 no need?
That is correct.
Quote:
Like one mention in the previous posts for single proc no need to mention jobstepname.procstepname, instead jus RESTART=procstepname is enough,
Now, don't get confused over this.
z/OS V1.R9.0 MVS JCL Reference states in the topic "Modifying Nested Procedures":
Quote:
Modifying or additional JCL statements apply to one level of nesting only. You can use statements to modify statements in a procedure only for the level of nesting at which the EXEC statement for that procedure appears.
//B PROC
//BS1 EXEC PROC=C
//CS1.CS1DD1 DD DSNAME=X.Y.Z This statement is a valid
//* override of procedure C, stepCS1
//* for DD CS1DD1
//*
//CS1.CS1DD3 DD SYSOUT=A This statement is a valid
//* addition to procedure C, step CS1
//BS2 EXEC PGM=BBB
//BS2DD1 DD DSNAME=E,DISP=SHR
// PEND
Procedure A:
Code:
//A PROC
//AS1 EXEC PROC=B
//BS2.BS2DD2 DD DSNAME=G,DISP=SHR This statement is a valid
//* addition to procedure B, step BS2
//AS2 EXEC PGM=AAA
//AS2DD1 DD DSNAME=E,DISP=SHR
// PEND
Job Stream:
Code:
//JOB1 JOB
//STEP1 EXEC PROC=A
//AS2.AS2DD2 DD DSNAME=G,DISP=SHR This statement is a valid
//* addition to procedure A, step AS2
//STEP2 EXEC PGM=IEFBR14
//A PROC
//AS1 EXEC PROC=B
//BS1.CS1.CS1DD1 DD DSN=X.Y.Z This statement is an invalid
//* override of procedure B, step BS1,
//* DD CS1.CS1DD1 (rules 4 and 5)
//*
//BS1.CS1.CS1DD3 DD SYSOUT=A This statement is an invalid
//* override of procedure B, step BS1,
//* DD CS1.CS1DD3 (rules 4 and 5)
//*
//BS1.BS1DD1 DD DSN=G,DISP=SHR This statement is an invalid
//* addition to procedure B, step BS1
//* (rule 3)
//AS2 EXEC PGM=AAA
//AS2DD1 DD DSN=E,DISP=SHR
// PEND
Job Stream:
Code:
//JOB1 JOB
//STEP1 EXEC PROC=A
//AS1.BS1.CS1.CS1DD1 DD DSN=X This statement is an invalid
//* override of procedure A, step AS1,
//* DD BS1.CS1.CS1DD1 (rules 3 and 5)
//STEP2 EXEC PGM=IEFBR14
Now, I don't have the source for the JES DSPs and, as I am neither an assembler nor a PL/X programmer, it would do me no good if I did. However, it is reasonable to assume that the same logic, and probably the same code, is used to resolve stepname references in every case, including for the RESTART parameter (this is essentially a longer-winded version of what I said to superk yesterday). So, we may never have a reference more than one level deep. Thus, if we wish to restart at STEPY in a proc at any level of nesting, we must find the step in the proc -- which may itself be nested several levels deep -- that invokes that proc, and (assuming that it be named STEPX) code RESTART=STEPX.STEPY on the job card.
