How do you use JCL to submit and monitor other jobs and commands?

You can also submit jobs through Zowe Explorer in VS Code by right clicking on a member with JCL in it. In Zowe Explorer's jobs section you can see job output, but only if it's in the spool, if it's stored in something like $avers you won't be able to retrieve it.

A job works as a script or a collection of actions executed in batch mode by designated programs. To execute these jobs you will frequently use a Job Card in the beginning of each JOB. following is an example. //JOBNAME JOB ()'JOB',CLASS=X,MSGCLASS=X,NOTIFY=&SYSUID. To designate a program to execute an activity, you’ll use a Job Control Language(JCL) that will be translated to machine language by the JES and will be processed by the OS. Following is an example of an activity to delete several regular files using a program called IDCAMS. //JOBNAME JOB ()'JOB',CLASS=X,MSGCLASS=X,NOTIFY=&SYSUID //STEP1 EXEC PGM=IDCAMS //SYSPRINT DD SYSOUT=* //SYSIN DD * Delete xxxxxxxx Delete xxxxx /*

Being able to read and write JCL is really important for any position that touches the mainframe. Most of the time, there is job in some library that will meet your needs, you’ll only need to adjust it accordingly, also is important to know the steps after running the job, if any errors appear, it’s important to know how to interpret the joblog to understand what just happened and if you need to fix something.

One way to monitor these jobs is using Zowe. Zowe is an integrated and extensible open source framework for z/OS. Zowe comes with a core set of applications out of the box in combination with the APIs and OS capabilities. The Open Mainframe Project estimates that 70% of mainframe shops will be using Zowe by the end of 2024. Find out more at: zowe.org

Another quick way to monitor the status of a job is to make use of the NOTIFY parameter in the JOB statement. When you provide NOTIFY=&SYSUID in the JOB statement, you will be notified when the job completes. A TSO message pops up upon the completion of the job and it will contain essential information such as the job's name, the job's ID, the job's completion time and the job's Maximum completion code (MAXCC). A job is deemed to be successful if the MAXCC is greater than equal to 0 and lesser than equal to 4. Jobs with MAXCC above 4 are usually regarded as failure.

Rexx execs can be used to submit, monitor, view/delete output, and cancel jobs using the TSO Foreground-Initiated-Background (FIBs) commands of SUBMIT, STATUS, OUTPUT, and CANCEL. TSO SUBMIT is similar to ISPF SUBMIT except you can use OUTTRAP to capture the job name and id for use with the other commands. From the exec, you can submit the job(s) and use the STATUS command to monitor completion. Once completed, you can use the OUTPUT command with the SAVE subcommand to copy the output to a data set for processing and then delete the held output, if desired. I've used these techniques with installation execs to ensure the environment is as expected. Rexx execs can also interact with SDSF although those tend to be more involved.

From a CICS TS perspective, it's possible to issue CICS system commands via JCL. This requires the definition of a console entry as a resource in the CICS TS definition file (DFHCSD), and also requires the appropriate RACF permissions. The IEFBR!4 program is executed, with a modify command defined in the JCL coded with the appropriate CICS TS region. This command is routed to the region, e.g. CICSTEST. This can include basic system inquiry operations, or even the ability to start and stop the specified CICS TS region. This facility should obviously be used with caution. Output from the command is displayed on the z/OS console and in the output of the job.

JCL provides the ability to automate system tasks without user interaction by leveraging IKJEFT01, the background TSO command processor. It allows embedding TSO or console commands directly within JCL using DD statements. The powerful SYSTSIN DD statement specifies the command stream to be executed. IKJEFT01 processes the command input and routes output back via SYSTSPRT for capture. This is demonstrated in the sample JCL, which runs the LISTCAT command to list catalog entries for a dataset. By specifying IKJEFT01 as the executing program and passing commands through SYSTSIN, JCL gains the functionality to perform various system operations in batch through a single job submission. Output is archived for reporting purposes.

JCL to submit another job Wait!!! Most mainframe schedulers provide audit tracking capability and will log who has run any unplanned job. Running a job through JCL may will mean that the audit log is not updated and this is frowned upon for audit compliance. Before executing another job through JCL I would check with Scheduling & Computer Security teams I can't believe many companies would allow this.

We can use IEBEDIT utility to execute one JCL from another JCL. This is used in a scenario where we have many steps in a JCL but we want to execute only a few,then we can create another JCL and from it we can execute selective steps (or all steps if needed) from the other JCL. An example is below- //JOB CARD //STEP01 EXEC PGM=IEBEDIT //SYSUT1 DD DSN=TEST.JCLLIB(JOB1), //. DISP=SHR //SYSUT2 DD SYSOUT=(*,INTRDR) //SYSIN DD * EDIT TYPE=INCLUDE,STEPNAME=(S1) /* If the above JCL is submitted, from TEST.JCLLIB(JOB1) only S1 step will be executed even though this JCL has many other steps. INTRDR is internal reader which is a functionality which will a privilege to a JCL to read another JCL and execute the steps.

It is important to note that every job that runs keeps the mainframe processor occupied. The inherent nature of the platform means that there are thousands of users who are trying to get their job executed. Hence, jobs are automatically set to be killed after a certain number of CPU seconds (not actual elapsed time). Setting the right CLASS and TIME parameter is crucial to ensure your job completes on time and isn’t kicked out. Other parameters such as REGION help in allocating the right amount of memory (address space). When having a job with large number of steps, code CONDition parameters to manage execution when steps might fail.

symbolic parameters and variables are your secret weapons! These allow you to define values that can be reused throughout the JCL code, reducing redundancy JCL code can become intricate. Leaving comments throughout your script explaining its logic and purpose is a game-change For commonly used JCL code sections, consider utilizing cataloged procedures.

Job control language (JCL) is a set of statements that you code to tell the z/OS operating system about the work you want it to perform. Although this set of statements is quite large, most jobs can be run using a very small subset. Learn about essential and most frequently used JCL statements and parameters, as well as coding techniques. JCL statements tell z/OS where to find the appropriate input, how to process that input (that is, what program or programs to run), and what to do with the resulting output.

How to use JCL to submit another job? Just because you can doesn't mean you should. I would advise anyone who thinks they have come up with a great new mainframe short-cut to check with others in your company as it is likely the short-cut is not already being used for a very good reason. Many tasks can be performed by macro & scripting but this is not always audit compliant.