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?

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.

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.

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

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?

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

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

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

]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.

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.

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.