|
View previous topic :: View next topic
|
| Author |
Message |
Alex Garcia
New User
Joined: 06 Jan 2011
Posts: 9
Location: Kansas City
|
|
|
|
I have a job that executes the same proc three times. The first step in the proc is a program that checks to see if a dataset is empty. If so, the program sets the rc=1. This step does not have a cond= on it. The first execution of the proc sets the return code to 1 and the rest of the steps are bypassed. The next execution of the proc executes the same program and sets the rc=0 since the input dataset is not empty, but the remaining steps in the proc do not run. The same result for the third execution of the proc. If the second and third execution of the program resets the rc to 0, why don't the rest of the steps execute?
Thanks! |
|
| Back to top |
|
 |
Akatsukami
Global Moderator
Joined: 03 Oct 2009
Posts: 1788
Location: Bloomington, IL
|
|
|
|
| Please post the JCL, including the expansion of the proc, and that portion of the JES execution log showing that the steps do not run. Cut and paste from your emulator, using the Code tag for readability; do not attach screenshots or other documents. |
|
| Back to top |
|
|
dick scherrer
Moderator Emeritus
Joined: 23 Nov 2006
Posts: 19244
Location: Inside the Matrix
|
|
|
|
Hello,
| Quote: |
| If the second and third execution of the program resets the rc to 0, why don't the rest of the steps execute? |
Ahh, Umm, nothing resets an already set return code. . . New return codes occur as additonal steps execute, but once set the return code from previous steps are never reset.
If your process only executed the proc once (rather than three times), you could submit process 2 from process 1 and then process 3 from process 2 via the internal reader. Then the "original" return code would not be seen by the subsequent runs. |
|
| Back to top |
|
|
Akatsukami
Global Moderator
Joined: 03 Oct 2009
Posts: 1788
Location: Bloomington, IL
|
|
|
|
| dick scherrer wrote: |
| Quote: |
| If the second and third execution of the program resets the rc to 0, why don't the rest of the steps execute? |
Ahh, Umm, nothing resets an already set return code. . . New return codes occur as additonal steps execute, but once set the return code from previous steps are never reset. |
If I understand him correctly (and it's quite possible I don't, which is why I asked to see the JCL and execution log) his JCL looks like this:
| Code: |
//A JOB
//STEP1 EXEC FOO
//STEP2 EXEC FOO
//STEP3 EXEC FOO
//
|
and FOO looks like
| Code: |
//FOO PROC
//PRCSTEP1 EXEC PGM=BAR
// IF (RC=0) THEN
//PRCSTEP2 EXEC PGM=SUMMAT
// ENDIF
|
STEP1.PRCSTEP1 runs to CC=1, and as expected STEP1.PRCSTEP2 does not execute. STEP2.PRCSTEP2 runs to CC=0, but STEP2.PRCSTEP2 does not execute as desired; likewise STEP3.PRCSTEP1 and STEP3.PRCSTEP2.
(The error in this case is obvious, but it may not be so in realitty.) |
|
| Back to top |
|
|
Alex Garcia
New User
Joined: 06 Jan 2011
Posts: 9
Location: Kansas City
|
|
|
|
| Sorry, I misspoke. The first execution of the proc sets the rc=1 and the subsequent executions of the proc SETS the rc=0. Does the JCL keep three different return codes and only reference the first? This doesn't make sense since after rearranging the jobsteps so that a valid data card is first, the proc executed all the steps for the first execution and then the second got rc=1 and neither execution 2 or 3 executed |
|
| Back to top |
|
|
Robert Sample
Global Moderator
Joined: 06 Jun 2008
Posts: 8696
Location: Dubuque, Iowa, USA
|
|
|
|
| Each step executed has a return code associated with it. A COND test that does not reference an individual step refers to all previous step condition codes. |
|
| Back to top |
|
|
Alex Garcia
New User
Joined: 06 Jan 2011
Posts: 9
Location: Kansas City
|
|
|
|
the job:
| Code: |
//FOO job
//FOOA EXEC PROC OOF
//FOOB EXEC PROC OOF
//FOOC EXEC PROC OOF
|
The proc:
| Code: |
//OOF PROC
//STEP1 EXEC PGM=UTL090
//IF UTL090.RC = 0 THEN
// EXEC ALL PROCSTEPS
//END-IF
|
The result:
FOOA executes, utl090 gets an rc=1 all steps in proc bypassed
FOOB executes, utl090 gets rc=0, all steps in proc bypassed
FOOC executes, utl090 gets rc=0, all steps in proc bypassed
UTL090 is the only step in the proc that does not have a COND=
thanks |
|
| Back to top |
|
|
Robert Sample
Global Moderator
Joined: 06 Jun 2008
Posts: 8696
Location: Dubuque, Iowa, USA
|
|
|
|
| Would it be so hard to post the actual job expansion? Without seeing exactly what the system thinks you've done, I don't think we're going to be able to help you. |
|
| Back to top |
|
|
Alex Garcia
New User
Joined: 06 Jan 2011
Posts: 9
Location: Kansas City
|
|
|
|
| I am not allowed to post stuff outside of work. They get kinda hinky about that stuff. The salient points are there. I think you answered my question with your earlier post about each step seeing the rc from each previous step. I assume that includes earlier executions of a proc in a job as well? |
|
| Back to top |
|
|
Akatsukami
Global Moderator
Joined: 03 Oct 2009
Posts: 1788
Location: Bloomington, IL
|
|
|
|
Note that qualifying the return code with the program name is wrong; it has to be qualified with the step name.
There are other possible errors due to its being embedded in a proc, but I may or may not be able to turn my full attention to this for a few hours. |
|
| Back to top |
|
|
Akatsukami
Global Moderator
Joined: 03 Oct 2009
Posts: 1788
Location: Bloomington, IL
|
|
|
|
I did have some time to look at this.
As I'd thought, the qualification of the condition is wrong (as is the hyphen in "END-IF").
My JCL:
| Code: |
//FOOA EXEC OOF
//STEP1.TOOLIN DD *
1
//STEP2.SYSUT1 DD *
GOODBYE, WORLD!
//FOOB EXEC OOF
//STEP1.TOOLIN DD *
0
//STEP2.SYSUT1 DD *
GOODBYE, WORLD!
//FOOC EXEC OOF
//STEP1.TOOLIN DD *
0
//STEP2.SYSUT1 DD *
GOODBYE, WORLD! |
The proc OOF:
| Code: |
//OOF PROC
//STEP1 EXEC PGM=P14
// IF (STEP1.RC=0) THEN
//STEP2 EXEC PGM=IEBGENER
//SYSPRINT DD SYSOUT=*
//SYSUT2 DD SYSOUT=*
//SYSIN DD DUMMY
// ENDIF |
(P14 is a little utility that does nothing but set the completion code to whatever is read from TOOLIN, or to 1234 if that is not a valid return code.)
Results in (E)JES:
| Code: |
JESMSGLG HLD 1 6 1 LOCAL 17
JESJCL HLD 1 6 1 LOCAL 52
JESYSMSG HLD 1 6 1 LOCAL 201
SYSPRINT FOOB STEP2 HLD 1 6 1 LOCAL 17
SYSUT2 FOOB STEP2 HLD 1 6 1 LOCAL 1
SYSPRINT FOOC STEP2 HLD 1 6 1 LOCAL 17
SYSUT2 FOOC STEP2 HLD 1 6 1 LOCAL 1 |
As expected and desired, FOOA.STEP2 did not execute, whereas FOOB.STEP2 and FOOC.STEP2 did. |
|
| Back to top |
|
|
Alex Garcia
New User
Joined: 06 Jan 2011
Posts: 9
Location: Kansas City
|
|
|
|
| Akatsukami wrote: |
Note that qualifying the return code with the program name is wrong; it has to be qualified with the step name.
|
Sorry, in my jcl the stepname and program name are the same. I typed it in wrong. My bad. UTL090.rc=0 is the stepname. Not step1. Also, the hyphen only exists in what I typed. there is none in my exec jcl |
|
| Back to top |
|
|
Alex Garcia
New User
Joined: 06 Jan 2011
Posts: 9
Location: Kansas City
|
|
|
|
| The difference between your execution and mine is that your subsequent steps don't have a cond=. I still need to code for abend situations and not execute subsequent steps on critical abends. They are all coded
(with the exception of the utl090 step) |
|
| Back to top |
|
|
Robert Sample
Global Moderator
Joined: 06 Jun 2008
Posts: 8696
Location: Dubuque, Iowa, USA
|
|
|
|
| Quote: |
| A COND test that does not reference an individual step refers to all previous step condition codes. |
Your COND=(0,NE) does not reference a step name, hence it applies to ALL PREVIOUS STEPS. If any step prior gets a non-zero return code, the execution of the step with COND=(0,NE) will be bypassed.
The system is doing exactly what you told it to do. |
|
| Back to top |
|
|
Akatsukami
Global Moderator
Joined: 03 Oct 2009
Posts: 1788
Location: Bloomington, IL
|
|
|
|
| Alex Garcia wrote: |
| The difference between your execution and mine is that your subsequent steps don't have a cond=. I still need to code for abend situations and not execute subsequent steps on critical abends. They are all coded
(with the exception of the utl090 step) |
Nu? Change the relational expression to ((STEP1.RC = 0) & (¬ABEND)). |
|
| Back to top |
|
|
Alex Garcia
New User
Joined: 06 Jan 2011
Posts: 9
Location: Kansas City
|
|
|
|
| Robert Sample wrote: |
]Your COND=(0,NE) does not reference a step name, hence it applies to ALL PREVIOUS STEPS. If any step prior gets a non-zero return code, the execution of the step with COND=(0,NE) will be bypassed.
The system is doing exactly what you told it to do. |
Hence my problem. I want the COND= to apply to all previous steps in the currently executing proc, not the previous executions of the proc earlier in the job. I apologize if I am not being clear about this. |
|
| Back to top |
|
|
Robert Sample
Global Moderator
Joined: 06 Jun 2008
Posts: 8696
Location: Dubuque, Iowa, USA
|
|
|
|
| Unless you explicitly name each step of the proc by using the appropriate two-level identifier, what you want to to cannot be done. You might want to investigate using your site's job scheduler to schedule three separate jobs, in which case the only condition codes to matter will be the ones in the current job. |
|
| Back to top |
|
|
dick scherrer
Moderator Emeritus
Joined: 23 Nov 2006
Posts: 19244
Location: Inside the Matrix
|
|
|
|
Hello,
| Quote: |
| I want the COND= to apply to all previous steps in the currently executing proc, not the previous executions of the proc earlier in the job. I apologize if I am not being clear about this. |
What you want is clear. . . That you cannot have it the way you are trying to do it does not yet appear to be clear to you . . .
If you change the process to have 1 submit 2 then 2 submit 3, the problem goes away.
Or completely qualify which COND to check. |
|
| Back to top |
|
|
Akatsukami
Global Moderator
Joined: 03 Oct 2009
Posts: 1788
Location: Bloomington, IL
|
|
|
|
| Alex Garcia wrote: |
| Hence my problem. I want the COND= to apply to all previous steps in the currently executing proc, not the previous executions of the proc earlier in the job. I apologize if I am not being clear about this. |
| Akatsukami wrote: |
| Change the relational expression to ((STEP1.RC = 0) & (¬ABEND)). |
|
|
| Back to top |
|
|
Alex Garcia
New User
Joined: 06 Jan 2011
Posts: 9
Location: Kansas City
|
|
|
|
thanks to all for your input. We were trying to avoid creating 18 new jobs and the associated schedule changes to try and resolve this problem.
The fact that I cannot do this the way that I should be able to do it is very clear to me now. This is not the answer that I sought, but is still an answer to my question.
I appreciate your efforts |
|
| Back to top |
|
|
Bill O'Boyle
CICS Moderator
Joined: 14 Jan 2008
Posts: 2501
Location: Atlanta, Georgia, USA
|
|
|
|
FWIW, here's an undocumented method to execute or not execute steps in a JOB. I use this in many disaster recovery JOB's, which have many steps which I may want to execute or not execute.
Using 1's and 0's is akin to boolean logic (1=ON, 0=OFF).
| Code: |
// SET RUNSTP1=1
// SET RUNSTP2=0
//*
// IF &RUNSTP1=1 THEN
//* THE STEP WILL RUN, VARIABLE RUNSTP1 RESOLVES TO A 1
// ENDIF
//*
// IF &RUNSTP2=1 THEN
//* THE STEP WILL NOT RUN, VARIABLE RUNSTP2 RESOLVES TO A 0
// ENDIF
//*
//
|
Bill |
|
| Back to top |
|
|
dick scherrer
Moderator Emeritus
Joined: 23 Nov 2006
Posts: 19244
Location: Inside the Matrix
|
|
|
|
Hello,
| Quote: |
| The fact that I cannot do this the way that I should be able to do it is very clear to me now. |
Why do you believe you "should be able" 
If you should be able, IBM would have implemented same.
It is quite important to test an approach before commiting to it and then needing to back-up and re-group. |
|
| Back to top |
|
|
Alex Garcia
New User
Joined: 06 Jan 2011
Posts: 9
Location: Kansas City
|
|
|
|
| dick scherrer wrote: |
Hello,
If you should be able, IBM would have implemented same.
|
So if IBM hasn't implemented it, then it shouldn't be done? |
|
| Back to top |
|
|
dick scherrer
Moderator Emeritus
Joined: 23 Nov 2006
Posts: 19244
Location: Inside the Matrix
|
|
|
|
Hello,
Not until you (or a large group) convince IBM to change "the way it works" 
Actually, "should" has little to do with it - as of the current implementation, you cannot do what you want the way you want to do it. . .
Many (most?) of us have been frustrated by the way some things are. Usually, they are not going to change (especially not quickly enough to be used for anything currently being worked on). |
|
| Back to top |
|
|
parsesource
New User
Joined: 06 Feb 2006
Posts: 97
|
|
|
|
| Robert Sample wrote: |
| Unless you explicitly name each step of the proc by using the appropriate two-level identifier, what you want to to cannot be done. You might want to investigate using your site's job scheduler to schedule three separate jobs, in which case the only condition codes to matter will be the ones in the current job. |
it can be done the following way. you have to add the stepname as parameter to the proc.
| Code: |
//A JOB
//STEP1 EXEC FOO,STEPNAME=STEP1
//STEP2 EXEC FOO,STEPNAME=STEP2
//STEP3 EXEC FOO,STEPNAME=STEP3
//
|
and FOO looks like
| Code: |
//FOO PROC
//PRCSTEP1 EXEC PGM=BAR
// IF (&STEPNAME.PRCSTEP1.RC=0) THEN
//PRCSTEP2 EXEC PGM=SUMMAT
// ENDIF
|
|
|
| Back to top |
|
|
|
|
