IBM Mainframe Forum

Dear dick scherrer
In our operational environment PROGA must run once every night via a JCL. But now in our test invironment I want to run it multiple of times to simulate for example 10 night passed. Its may be not true to use thw word "test the functionality " of PROGA. I want just run PROGA multiple of times via MYPROG and MYPROG must change the PARM1 for PROGA also.

Hello,

Suggest you simply change MYPROG to create 10 sets of jcl for PROGA and either submit this thru the internal reader or write it to a dataset or member and submit this.

You will have the 10 executions of PROGA that you want. COnvenitntly, they will all be in one set of sysouts.

These users thanked the author dick scherrer for the post:

Mehdi shri (Sun Nov 11, 2012 4:59 pm)

Thank you dick scherrer.
What is the statement for using internal reader in COBOL.

Mehdi shri wrote:... What is the statement for using internal reader in COBOL.

You define an internal reader to your program using JCL, as discussed in MVS JCL Reference and MVS JCL User's Guide for your z/OS release. This has not changed in almost 40 years. All your program does is use standard Cobol methods to open the data set, write to the data set, and close the data set as though it is a sequential data set. There are no special Cobol statements to use an internal reader.

These users thanked the author steve-myers for the post:

Mehdi shri (Sun Nov 11, 2012 4:59 pm)

In addition to actually using the INTRDR (Internal Reader) you can, for your initial testing, just create a "normal" sequential file, even SYSOUT=* (or whatever), so that you know you've got things right before tossing the job through the INTRDR.

If writing to an actual dataset, you can edit the dataset and use SUBmit if it looks OK. It doesn't have to go through the INTRDR, that doesn't make the job work or not, it is just a way of then automating the process.

These users thanked the author BillyBoyo for the post:

Mehdi shri (Sun Nov 11, 2012 4:59 pm)

BillyBoyo's idea of specifying SYSOUT=* or specifying a real data set to review to job before actually submitting it is excellent; I've done this many times over my career.

Hello,

I've also been known to generate the early testing with a JCL Error in the submitted job so that while i'm making sure i built the job correctly it can be submitted with no fear of running and having the system validate the jcl as much as possible . . .

Another excellent idea; one I've done many times over the course of my career.