View previous topic :: View next topic |
Author |
Message |
TexasRanger Beginner
Joined: 05 Feb 2004 Posts: 10 Topics: 4
|
Posted: Wed May 26, 2004 9:07 am Post subject: STEP RC, JOB RC, OPC SCHEDULER |
|
|
Hello,
I have read some other posts to get an answer about the following topic, but I have found nothing that I can reuse.
I am going to run a Job in OPC that exceeds a limited number of lines, the porblem is that I have so many conditions concatened that depend on the return codes of previous steps. So when dividing the JCL in to smaller JOBS it is not possible to "save" the return code a step in a previous job.
Is there any mechanism thereby you can save those rc steps values without breaking the logic flow of the JCL? Of course the worst solution is to divide each step of the JCL into a new JCL, so maintining the return code of the step in the return code of the JOB.
Thanks. |
|
Back to top |
|
|
kolusu Site Admin
Joined: 26 Nov 2002 Posts: 12372 Topics: 75 Location: San Jose
|
Posted: Wed May 26, 2004 9:34 am Post subject: |
|
|
Texas Ranger,
Do you have more than 255 steps in the job? I never heard that there is a limitation on the no: of lines per job. The only limitation you have is no: of exec statements and the dd names.
Does your shop has limitation on the no: of lines in a JCL?
Kolusu _________________ Kolusu
www.linkedin.com/in/kolusu |
|
Back to top |
|
|
TexasRanger Beginner
Joined: 05 Feb 2004 Posts: 10 Topics: 4
|
Posted: Wed May 26, 2004 10:23 am Post subject: |
|
|
Nop, is a client requirement, and I guess it also has to deal with OPC performance. |
|
Back to top |
|
|
Maton_Man Beginner
Joined: 30 Jan 2004 Posts: 123 Topics: 0
|
Posted: Wed May 26, 2004 9:40 pm Post subject: |
|
|
Are you concerned with the number of lines in the job you submit or the total number of lines after all INCLUDEs and PROCs are expanded during submission?
If the former is true then (without seeing your actual job) some strategies for cutting down on the 'apparent' size of the job are:
- 'procedure'-izing
- using INCLUDE statements
- using SET statements to store long strings that are repetitive
You could (again, without seeing your actual job) cut down on the actual number of lines by:
- using LIKE= for all new, catalogued datasets and pre-defining model datasets
- putting all instream data in datasets instead of instream _________________ My opinions are exactly that. |
|
Back to top |
|
|
TexasRanger Beginner
Joined: 05 Feb 2004 Posts: 10 Topics: 4
|
Posted: Thu May 27, 2004 3:31 am Post subject: |
|
|
I am concerned with the total number of lines the JOB has. Below there is an example, take the long lines as the threholds of number of lines for each new JOB, the JOB will result in 4 JOBS. Bear in mind that is not possible to reorganize the flow of execution because of shared datasets needed for each step, some data sets are the output for one step and the input for other different.
So, how would you keep those steps return codes when diving the JOB???
Thanks.
Example of JOB (mine has 230 steps and much more lines.....)
__________________________________________________
JOB pepito
STEP1
.....
RUN PROGRAM (A)
END
____________________________________________________
IF STEP1.RC = 0
STEP2
......
RUN PROGRAM(B)
END
ENDIF
IF STEP1.RC=0
STEP3
...
SORT
ENDIF
________________________________________________-
STEP4
RUN PROGRAM(C)
END
IF STEP3.RC =3
STEP5
RUN PROGRAM(D)
END
ENDIF
______________________________________________-
IF STEP4.RC=1
STEP6
RUN PROGRAM(E)
END
ENDIF
_______________________________________________- |
|
Back to top |
|
|
Maton_Man Beginner
Joined: 30 Jan 2004 Posts: 123 Topics: 0
|
Posted: Thu May 27, 2004 5:43 pm Post subject: |
|
|
Quote: |
Bear in mind that is not possible to reorganize the flow of execution because of shared datasets needed for each step, some data sets are the output for one step and the input for other different.
|
If you catalog them then this shouldn't hinder you from exploring a change in execution flow, but since you haven't posted your actual job I can only guess.
Also, I would only be taking stabs in the dark in suggesting a solution to your problem because conceivably everything I suggest might have a valid but not necessarily technical reason for not working.
One option would be to catalog a dataset eg. JOBNAME.STEPNAME.STEPRC if you get a certain return code check for existence (in a number of ways which you will find by searching the forums) in your subsequent jobs.
- _________________ My opinions are exactly that. |
|
Back to top |
|
|
|
|