IBM Mainframe Forum

Hi,

This is a piece of Internal reader code that i have. After all the 5 jobs that I am calling from this Internal reader step are completed sucessfully, I want my next step in the parent job to execute. Would checking for the condition code of the Internal reader step INTRDR2 achiece this. If not please suggest an alternative.
//INTRDR2 EXEC PGM=IEBGENER,COND=(0,NE,STEP02)
//SYSOUT DD SYSOUT=*
//SYSPRINT DD SYSOUT=*
//SYSUT1 DD DISP=SHR,DSN=WEBADT.CSS.TD453912.RUN(AA453912)
// DD DISP=SHR,DSN=WEBADT.CSS.TD453912.RUN(AB453912)
// DD DISP=SHR,DSN=WEBADT.CSS.TD453912.RUN(AC453912)
// DD DISP=SHR,DSN=WEBADT.CSS.TD453912.RUN(AD453912)
// DD DISP=SHR,DSN=WEBADT.CSS.TD453912.RUN(AE453912)
//SYSUT2 DD SYSOUT=(,INTRDR)
//SYSIN DD DUMMY
//STEP3 EXEC PGM=CHECKF,COND=(0,NE,INTRDR2) .

Thanks.
.

there are no <inline> alternatives...
the cond code checking mechanism work only to check the preceding steps rc inside a JOB

for cross JOB checking You will have to setup the proper scheduler(*) constructs

(*) TWS aka OPC, or the corresponding ones from some other provider

If your goal is to determine if the job was submitted correctly, JES2 does not provide any feedback to the submitting program, so there is no way the submitting program can provide a useful return code. Even if there was a feedback method, I doubt IEBGENER would be checking.

There is a limited mechanism to get the job ID of the most recently submitted job. Unfortunately, I don't think there is formal documentation for this method, though this link provides a hint about the mechanism. Its user must be writing Assembler, but the program does not have to be authorized to use it. The TSO SUBMIT command uses this mechanism. I've used this mechanism in past endeavors, though my last try, back in the 1990s, when I was trying to write a batch job submission program failed, though I think the problem I had was more to do with other aspects of the program. In order to do this correctly the program has to locate new jobs in its input, and get the job ID before it starts a new job.

If your goal is to determine if the submitted job ran correctly, you need to use other methods, as enrico-sorichetti states in his previous post.

Hello,

Suggest you re-design the process.

Submitting 5 jobs to run concurrently is usually not acceptable. . .

There is no good reason to tie up resources waiting for the 5 submitted jobs to complete.

You need to talk with your scheduling people for the way to accomplish what you want using the system scheduling.

Problem: A particular step in our job is taking long almost 6-7 hours to complete. So I was thinking to split it into 4-5 jobs seperately(each processing a set of records) to reduce the time. Once these jobs complete, the next steps in the parent job have to continue.
This is the plan.

Is there any way we could achieve this. Could you please suggest.

Without some sort of scheduling package, the usual solution is for the first job to submit the second job as soon as it completes, and for the second job to submit the third job, and so on.

if the <process> is built of <steps> that have to be run in sequence
it will make substantially no difference using one big job or many small jobs
( apart dataset access conflicts )

for the process as You describe it ... mangle a step in order to parallelize its processing
You will need definitely a scheduler

Problem: A particular step in our job is taking long almost 6-7 hours to complete. So I was thinking to split it into 4-5 jobs seperately(each processing a set of records) to reduce the time. Once these jobs complete, the next steps in the parent job have to continue.

Why do you think splitting the job up will help your problem? What analysis have you done to determine this? A program may be I/O-bound or CPU-bound. If your job is CPU-bound, splitting it into multiple jobs may actually make your problem WORSE since you will be adding the CPU overhead of address space switching without reducing the CPU requirement at all. If the program is I/O-bound, splitting the job into multiple jobs may -- or may not -- help, depending upon the specifics (such as accessing a data base or VSAM files, strings and buffers available to the program, the JCL being used and so forth).

Bottom line: unless you've done a lot of analysis up front, merely splitting a job into 4 or 5 (or whatever) jobs may not make a single second of difference in the total time it takes to get the data processed.