|
View previous topic :: View next topic
|
| Author |
Message |
drowelf
Warnings : 1
New User
Joined: 03 Mar 2006
Posts: 47
Location: Simpsonville, SC
|
|
|
|
Interesting question brought to me by a colleague . We have a JCL Stream that invokes a PROC with several Steps. A subsequent Steps are encased in an IF STEPxx.RC = 0. She needs to restart the job at one of the steps within the IF Block. But when she tries it using the RESTART= option, the step never executes because the IF condition is not satisfied.
Now I'm stumped and not sure how to get this job restarted at the required step. |
|
| Back to top |
|
 |
Akatsukami
Global Moderator
Joined: 03 Oct 2009
Posts: 1788
Location: Bloomington, IL
|
|
|
|
| Sacrificing any number of chickens will be useless; you will have to edit the JCL beyond merely adding a RESTART parameter to the job card. |
|
| Back to top |
|
|
Gary McDowell
Active User
Joined: 15 Oct 2012
Posts: 139
Location: USA
|
|
|
|
I like to know the answer to this one as well.
As a work-around for restarts I've just taken the IF/ENDIF temporally out and then did the RESTART. Not ideal but it worked. |
|
| Back to top |
|
|
Robert Sample
Global Moderator
Joined: 06 Jun 2008
Posts: 8696
Location: Dubuque, Iowa, USA
|
|
|
|
The manual (JCL Reference in this case) tells much:
| Quote: |
20.23.4 Cautions when Coding the RESTART Parameter
Before resubmitting a job:
Check all backward references to steps before the restart step. Eliminate all backward references in EXEC statement PGM parameters and DD statement VOLUME=REF parameters.
Review all EXEC statement COND parameters. If any of the COND parameters reference a step before the restart step, be aware that the system ignores the return code tests for those steps. See "Considerations when Using the COND Parameter" in topic 16.5.6 for more information.
Note that the stepname and procstepname specified to identify the restart step must be unique within the job. Otherwise, the system will not be able to determine the correct restart step. Results will be unpredictable.
Review all IF/THEN/ELSE/ENDIF structures. If a relational expression references a step that is bypassed by the RESTART keyword, the system evaluates that part of the expression as false.
|
And after playing Zelda quite a few hours, I NEVER sacrifice chickens! They are too dangerous! |
|
| Back to top |
|
|
Gary McDowell
Active User
Joined: 15 Oct 2012
Posts: 139
Location: USA
|
|
|
|
Also as Robert mentioned in his post " See "Considerations when Using the COND Parameter" in topic 16.5.6 for more information."
In part…
| Quote: |
When the JOB Statement Contains a RESTART Parameter
When restarting a job, the restart step becomes, in effect, the first step in the job. Therefore, the system evaluates a COND parameter on the restart step as false and executes the step. Subsequent steps might be executed. When a COND parameter on a step following the restarted step refers to a step that precedes the restarted step, the system evaluates the COND parameter as false. If all other COND parameters on that step are also false, the system executes the step. |
|
|
| Back to top |
|
|
drowelf
Warnings : 1
New User
Joined: 03 Mar 2006
Posts: 47
Location: Simpsonville, SC
|
|
|
|
| Akatsukami wrote: |
| Sacrificing any number of chickens will be useless; you will have to edit the JCL beyond merely adding a RESTART parameter to the job card. |
I did not realize that any practitioners of mainframe poultry sacrifice still existed out there. I used it quite a lot during my early days as a developer. 
Thanks to everyone who answered. I had pretty much come to the same conclusion, but wanted to make sure. |
|
| Back to top |
|
|
enrico-sorichetti
Superior Member
Joined: 14 Mar 2007
Posts: 10873
Location: italy
|
|
|
|
| Quote: |
| Sacrificing any number of chickens will be useless |
what about using managers instead 
might not be as effective as chickens, but it would be a nice way to get rid of dead wood |
|
| Back to top |
|
|
Akatsukami
Global Moderator
Joined: 03 Oct 2009
Posts: 1788
Location: Bloomington, IL
|
|
|
|
| enrico-sorichetti wrote: |
| Quote: |
| Sacrificing any number of chickens will be useless |
what about using managers instead |
I don't want to offend the loa!   |
|
| Back to top |
|
|
David Robinson
Active User
Joined: 21 Dec 2011
Posts: 199
Location: UK
|
|
|
|
Whilst it is true that you cannot restart from with an IF/THEN block by coding some sort of different restart statement, it can however be done if prior consideration has been given to this and the JCL coded accordingly.
//TEST01S IF STEP01.RC EQ 0 OR ¬STEP01.RUN THEN DO
//STEP02 EXEC PGM=IEFBR14
In this case a restart from STEP02 will work, as the IF condition also has a test to see whether STEP01 actually ran.
Alternatively, if you use TWS and the environment has been set up appropriately, you can use the step restart feature within TWS. This will allow a restart from within an IF/THEN block as on rerun TWS will manipulate the JES control blocks to simulate the return codes that occurred on the original failed run. |
|
| Back to top |
|
|
Bill Woodger
Moderator Emeritus
Joined: 09 Mar 2011
Posts: 7309
Location: Inside the Matrix
|
|
|
|
| Quote: |
| ... TWS will manipulate the JES control blocks to simulate the return codes that occurred on the original failed run. |
Is that really how it works? |
|
| Back to top |
|
|
David Robinson
Active User
Joined: 21 Dec 2011
Posts: 199
Location: UK
|
|
|
|
| Bill Woodger wrote: |
| Quote: |
| ... TWS will manipulate the JES control blocks to simulate the return codes that occurred on the original failed run. |
Is that really how it works? |
I believe so, although I'm an Ops Analyst, not a Sysprog, and hence not an expert on such things! This is the extract from the manual -
Return code simulation logic
The Step Restart of a job is performed by return code simulation. The Scheduler obtains a history of the previous runs, the step execution, and the return codes from the Operinfo record. Then it adds a pre-step named EQQCLEAN to the JCL. The list of simulated steps and return codes serves as input for EQQCLEAN.
At run time, EQQCLEAN checks the JES control blocks and alters them to force the simulated return codes so that IF THEN ELSE and COND can follow the correct logic.
Abended steps are simulated as flushed for the following reasons:
IF THEN ELSE or COND related to abended steps are supposed to be run immediately at abend time. The flushed simulation avoids the duplicate execution of these steps.
If the abended steps were not simulated as flushed, JES would flush all the steps following the abended steps again. |
|
| Back to top |
|
|
Bill Woodger
Moderator Emeritus
Joined: 09 Mar 2011
Posts: 7309
Location: Inside the Matrix
|
|
|
|
| Well, it seemed an ugly thing to do. Thinking further, it is not as bad as I was thinking, as the only thing which could be "affected" by such changes would be COND and IF processing and such things. |
|
| Back to top |
|
|
|
|
