How many MAXIMUM Jobs can be submitted in a single JCL

[Priya]

Hi,

How many MAXIMUM Jobs can be submitted in a single JCL?

[Robert Sample]

Assuming you mean a single data set that is submitted to the system via a TSO SUBMIT command or via the internal reader in a batch job, there is no real limit. Your system has a limit on the total number of jobs that can be in the system at one time, set in the JES initialization parameters, but the system will submit whatever is in your data set to the internal reader. And there are other limits (system spool space available, for example) that will impact the answer.

Note that this is NOT something you want to test. JES limits activity once spool space utilization hits a certain percent, and completely stops activity once spool space utilization hits another percent -- which means nobody gets to sign onto the system, even.

[BobThomas]

I did an experiment and had 10 Job-cards in a single member of a PDS - 20 Jobs got submitted, as you said. Should not it be one-Job, per member? I'm confused why it's not that way..?

[Robert Sample]

The system determines the start of a job when it finds a JOB card. The end of the job is much harder to determine, but a new job card definitely ends the previous job. The member count of a PDS has nothing to do with the number of submitted jobs.

[DB2 Guy]

The end of the job is much harder to determine...

Why is it so, Robert? Are there some limitations from OS side?

Thank you.

[Robert Sample]

Consider the internal reader. You copy a series of JCL statements to it, and the internal reader buffers them in your address space. These JCL statements may include one job, or two jobs, or many jobs. Finding a JOB statement in the stream of statements indicates that the previous job (if any) is complete -- but for the last (or only) job being submitted, what indicates the end of that job? A // statement does not since there may be additional (unused) JCL statements after the //. Closing the internal reader will indicate the end of job, but that may be hours (or days) after the last statement is read in (one example of this would be an internal reader for a CICS region where the region stays up 24 x 7 -- unless the DD statement is closed or another job is submitted, the last JCL stream remains unfinished). The same consideration applies to remote job entry readers -- they may remain open for weeks at a time, so the last JCL stream submitted won't be completed until the reader is closed or another job is submitted.

IBM provides some statements to indicate the end of the job. The /*EOF statement is most common although the JCL Reference manual lists several others (/*DEL, /*PURGE and /*SCAN -- the latter two only for JES2). The TSO SUBMIT command usually closes the internal reader as part of the SUBMIT processing, but that may be a site option -- I haven't reviewed them lately. Any time the internal reader is used (particularly for remote job entry and CICS internal readers), using /*EOF as the last statement will indicate the end of the job and allow it to be processed.

[Priya]

Thanks for such a comprehensive explanation, Robert.

Much appreciate that,

[DB2 Guy]

Thank you Robert.

[BobThomas]

The system determines the start of a job when it finds a JOB card. The end of the job is much harder to determine, but a new job card definitely ends the previous job. The member count of a PDS has nothing to do with the number of submitted jobs.

Thanks Robert. As I said in other post, sorry for the late reply. But this did help.