Check the return code of an Internal reader step



JES, JES2, JCL utilities, IDCAMS, Compile & Run JCLs, PROCs etc...

Check the return code of an Internal reader step

Postby kiranmayipv » Mon Nov 29, 2010 5:11 pm

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.
.
kiranmayipv
 
Posts: 7
Joined: Wed Aug 18, 2010 8:31 pm
Has thanked: 0 time
Been thanked: 0 time

Re: Check the return code of an Internal reader step

 

Re: Check the return code of an Internal reader step

Postby enrico-sorichetti » Mon Nov 29, 2010 7:14 pm

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
cheers
enrico
When I tell somebody to RTFM or STFW I usually have the page open in another tab/window of my browser,
so that I am sure that the information requested can be reached with a very small effort
enrico-sorichetti
Global moderator
 
Posts: 2643
Joined: Fri Apr 18, 2008 11:25 pm
Has thanked: 0 time
Been thanked: 130 times

Re: Check the return code of an Internal reader step

Postby steve-myers » Mon Nov 29, 2010 9:18 pm

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.
steve-myers
Global moderator
 
Posts: 1885
Joined: Thu Jun 03, 2010 6:21 pm
Has thanked: 4 times
Been thanked: 197 times

Re: Check the return code of an Internal reader step

Postby dick scherrer » Tue Nov 30, 2010 2:07 am

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.
Hope this helps,
d.sch.
User avatar
dick scherrer
Global moderator
 
Posts: 6304
Joined: Sat Jun 09, 2007 8:58 am
Has thanked: 3 times
Been thanked: 91 times

Re: Check the return code of an Internal reader step

Postby kiranmayipv » Tue Nov 30, 2010 12:12 pm

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.
kiranmayipv
 
Posts: 7
Joined: Wed Aug 18, 2010 8:31 pm
Has thanked: 0 time
Been thanked: 0 time

Re: Check the return code of an Internal reader step

Postby steve-myers » Tue Nov 30, 2010 12:16 pm

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.
steve-myers
Global moderator
 
Posts: 1885
Joined: Thu Jun 03, 2010 6:21 pm
Has thanked: 4 times
Been thanked: 197 times

Re: Check the return code of an Internal reader step

Postby enrico-sorichetti » Tue Nov 30, 2010 12:30 pm

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
cheers
enrico
When I tell somebody to RTFM or STFW I usually have the page open in another tab/window of my browser,
so that I am sure that the information requested can be reached with a very small effort
enrico-sorichetti
Global moderator
 
Posts: 2643
Joined: Fri Apr 18, 2008 11:25 pm
Has thanked: 0 time
Been thanked: 130 times

Re: Check the return code of an Internal reader step

Postby Robert Sample » Tue Nov 30, 2010 5:25 pm

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.
Robert Sample
Global moderator
 
Posts: 3367
Joined: Sat Dec 19, 2009 8:32 pm
Location: East Dubuque, Illinois
Has thanked: 1 time
Been thanked: 222 times


Return to JCL

 


  • Related topics
    Replies
    Views
    Last post