IBM Mainframe Forum

Hello,

My apologies, I know the thread could have been more aptly named, but I was unsure as to how I'd put my question.

Following a requirement, the sample JCL that I'd written is as below:



The '$MEMBER1' is the SORTOUT DD statement which is built in a COBOL program in an earlier step.
The challenge that I'm facing currently is-- the PDS containing the '$MEMBER1' is given in JCLLIB statement at the top of the JCL, now during the execution, the value of '$MEMBER1' updated by the COBOL is not getting picked by my JCL in the First run of this piece; when I run the JCL a second time, the value updated in previous run is picked.
This I understand can be because of JES loading my JCL symbolics during the initial JCL conversion phase.
Example: lets say the member is initially empty, the COBOL wrote some data to this member, and we expect our JCL to pick the updated SORTOUT from this member; when the JCL is executed, no SORTOUT is found.
Now, when we submit the JCL again, SORTOUT is found, because it was built in the previous run itself.


Is there a way to pass the SORTOUT member to my JCL such that the updated values get picked, everytime the JCL is submitted, instead of it picking the values which were present at the time of initial JCL loading.

Thanks.

I don't understand what you mean by "SORTOUT member". Can you show an example of what you are trying to do?

Hey Bill,

The sample JCL that I'd initially given (the first comment in this thread) should ideally have a SORTOUT coded as below; the values of Xs', ns', ms', zs' and bs' being present (valid numbers or characters signifying each value):



What we are currently doing is, the above skeleton (and only the above part) is built using a COBOL program during runtime itself, where all the X, m, n, z, b are populated depending on various conditions. Basically the entire SORTOUT statement is built in COBOL; which is then written to a PDS member (so basically the PDS member contains the SORTOUT statement with valid values which were populated by COBOL program), the PDS name being already provided in the JCLLIB statement coded at the start of JCL.
Post which this member is passed to my SORT step as shown in the previous comment using an INCLUDE statement.

Problem here is:

The '$MEMBER1' is the SORTOUT DD statement which is built in a COBOL program in an earlier step.
The challenge that I'm facing currently is-- the PDS containing the '$MEMBER1' is given in JCLLIB statement at the top of the JCL, now during the execution, the value of '$MEMBER1' updated by the COBOL is not getting picked by my JCL in the First run of this piece; when I run the JCL a second time, the value updated in previous run is picked.
This I understand can be because of JES loading my JCL symbolics during the initial JCL conversion phase.
Example: lets say the member is initially empty, the COBOL wrote some data to this member, and we expect our JCL to pick the updated SORTOUT from this member; when the JCL is executed, no SORTOUT is found.
Now, when we submit the JCL again, SORTOUT is found, because it was built in the previous run itself.


Is there a way to pass the SORTOUT member to my JCL such that the updated values get picked, everytime the JCL is submitted, instead of it picking the values which were present at the time of initial JCL loading.

I hope I was able to put across my query in a better fashion this time; please let me know in case it is still unclear.

Thanks.

Run your sort in a separate job after the member has been created.

Hey Nicc,

That is the worst case scenario solution that I could think of, and we'd have to push it; the problem with this solution being, we'll have to request business for scheduling another job in prod, which is urmmm, not very feasible under the current conditions here, hope you'd understand.

I can submit the SORT step in a new job using IEBGENER step after the said COBOL program has executed, that would solve my problem, but in that case I won't be able to add scheduler job dependency on this submitted job (submitted through IEBGENER || if this is possible in TWS, I am currently not aware of it ).

Which brings us back to the square one, if there is a way to achieve the requisite in the same job.

Thanks.

No - and in a production environment even a job submitted by another job should be scheduled via the scheduler so that dependencies can be resolved. either way, you are adding another job. The alternative is to re-think the entire strategy. Why do you need a program to generate the SORTOUT statement in the first place? All you need is a datasetname (can be a temporary dataset name generated by the system), a space parameter (can be made large and have RLSE coded to cut down unused space), a DISP and a place to put the dataset. Sort can handle the rest.

Hey Nicc,

Logically speaking whatever you've said holds true, and this is how we usually go about it.
This is a first timer for me as well, looking at this kind of requirement. Sadly the setup I was given to work with was this, with the COBOL, and the rest of the stuff in place; else I'd have done it a bit differently.

Nevertheless, going back to why we are building SORTOUT through COBOL, there are a horde of precursor conditons which decide what all datasets are to be written, which is why the need to have a dynamic DSN, as the DSN can change depending on conditons, so will the space/RECL/UNIT, it can be an o/p TAPE as well; agreed that we can have a temp dataset in place; but, again, how do we find the correct DSN later for this temp dataset.

Which is why the query, and the current design.

<Just a wishlist item, I hope there would be something like STEPLIB, which instead of having us overriding loads allows us to override libraries the way JCLLIB does>

Thanks.

As you already seem to know, everything in the JCL is already resolved before the job is even selected for execution.

If you need this, the only way is a separate job. Someone should have caught that at the design stage.

Note, as NicC alluded, SORT will supply all the DCB info for SORTOUT or on OUTFIL dataset. Much better not to provide those in the JCL. Two places to maintain things.

how do we find the correct DSN later for this temp dataset

LRECL (and other DCB parameters) do not need to be coded - your sort program takes care of that.

Aki88 wrote:I can submit the SORT step in a new job using IEBGENER step after the said COBOL program has executed, that would solve my problem, but in that case I won't be able to add scheduler job dependency on this submitted job (submitted through IEBGENER || if this is possible in TWS, I am currently not aware of it ).

This is possible. TWS can be used to track a job that is submitted outside of TWS, and hence run succesor jobs when it has completed. Simply add the job to your TWS schedule as usual, but set the "Submit" flag in Automatic Options to No.