Submitting Job

Q. How do you submit a Job on Mainframes for execution?

On Mainframes, when you want to perform any task, you write a Job, and give it to the Mainframe Computer for processing. This is called submitting a job. However, contrary to what you might fancy, your job doesn’t run immediately. Picture this - there are hundreds and thousands of Jobs, that are submitted on a Mainframe, minute-by-minute, every second, by different folks. How would the Mainframe computer decide which job goes first, and then which goes next and so on.. The MVS Operating System prepares a pretty time-table, a schedule, that goes something like this - JOB 1 runs at 12 o’ clock, JOB 2 runs at 1 o’ clock, JOB 3 runs at 2 o’ clock and so on.. Thus every job is allotted a time-slot(period) in the Mainframe's Calendar/time-table. To submit a JOB on Mainframes, you must type SUBMIT command or just SUB, on the command line of the editor. I have shown below, how you submit a job on Mainframes. When you press <Enter>, the Job AGY015A gets submitted to the Mainframe computer for processing. This is indicated by a *** message displayed at the bottom of the screen. The *** indicates, that TSO is waiting for me to read the message. As soon as you press <Enter> key again, the message goes away.   A common practise adopted by most Mainframe Programmers, is to code the NOTIFY parameter on the JOB Statement. Coding this parameter is quite useful, as it gives you an alert, a notification message, saying "The job AGY0157A has completed".

Q. How do you see the Job Print Output in TSO/ISPF?

I submitted the simple 3-Step JCL, by typing the SUBMIT command. Shortly after, MVS also alerted me, by sending a message, that my job AGY0157A completed. But, I don’t know for sure, whether my job completed successfully, or it failed(and the reason why it failed). MVS Operating System prints messages to a log, as the job is processed. These run-time messages which get recorded to the log, helps track, if the Job completed successfully or it failed. Further, they also contain error-messages that point out why the job fails. To see the print output/log of any Batch Job, you use a software called SDSF. SDSF stands for Spooler Display and Search Facility – its a software for seeing the output in the Spool. What is Spool? Well, generally, the log of a Job, when it runs on Mainframes, are to be sent to a printer. But prior to sending the log to the printer, the logs have to wait(buffered) in a staging area(in a queue), because hundreds of jobs complete every minute, and the logs gotta be printed. Not all logs can be printed at once. The logs have to wait in a Queue/staging area. This staging area is called Spool(Queue). The Mainframe printer will pick up the log from the spool one-by-one and print it. Before TSO and SDSF was invented, you couldn’t see the output till the time, it got printed. Waiting for it to get printed, could take hours on end. Now-a-days, TSO makes this easy, it’s possible to view the logs in the Spool(Queue).   To view the log of a Job in the Spool(Queue), type START SDSF and press <Enter>. This shows the shows the SDSF Screen. To see the log of Job, you must type ST on the SDSF menu and press <Enter>.   A list of the logs for all jobs in Spool(Output Queue) is displayed. By default, this list will displayed only those jobs submitted via your TSO User-id. For example, if my TSO User-id is AGY0157, it will display all jobs starting with(prefix) AGY0157*.   The screen displays a list of logs of all jobs, you have submitted. For each job that you submit, there is an entry, and it shows various details like the job-name, owner, class and priority. If your job is complete, and its log is ready to be dispatched to the printer, the log is on the PRINT Queue. On the other hand, if the job is still running, then it is still in the EXECUTION Queue. Mostly, all jobs that you submit, their logs would be dumped here in the Spool. To view the contents any particular job log, you can type ? against the job=name and press <Enter>. This takes you inside the log. The log(print output) of a job, contains several sections. You can type S(Show) against each section, and view the contents of it.  The Input Queue and Output Queue are analogous to the run-ways on an Airport. The Input Queue is runway from where the Jobs take-off. After their flight is complete, the jobs land on the runway called the Output Queue.But who's the Air Traffic Controller(ATC) on this Airport? The JES(Job Entry Sub-System) is a software that manages the Input Queue and Output Queue. The JES acts like Traffic Controllers(Traffic cops). Without them, two airplanes or jobs could collide. The JES is a part of the MVS Operating System that decides, what time a job can takeoff safely from the Input Queue(Takeoff runway). Thus, it monitors the traffic in the Input Queue(Runway) and prepares the time-table, a chart or a schedule for Jobs entering the system. On the Input Queue side, the JES(Job Entry Subsystem) welcomes all Jobs that enter into the Input Queue, reads the Jobs' JCL, converts it into an internal format known to MVS, and schedules the job for takeoff at 2 o’clock or 3 o’clock, till the Job takes off, and begins its flight(execution). Sometimes, on the Output Queue(Staging area) side contains logs(outputs) of old jobs. Such old logs(print outputs) of a job, are deleted from time-to-time periodically by JES. So, JES ensures that the Output Queue clean and tidy. The JES Message Log contains the following messages -   The Job Entry Subsystem(JES) reads the Job’s JCL Statements. My Job had 24 lines of JCL Code, so JES reports this as 24 cards read. Once the job takes off from the Input Queue, it executes, and lands at Output Queue. The log(print output) of Job, is referred as SYSOUT. This contains 125 lines of text. JES reports this as 125 SYSOUT Print records. This implies, the log(print output) of the job, contains 125 lines of text, in the Output Queue(Staging area), waiting to get printed. MVS numbers the JCL Statements that you submitted as part of the job.   ALLOC tells you which devices and how much memory was allocated for the job-step. As you know, one step runs one program. It also informs you about the CPU time required to process a Job-step. Every Job-step leaves behind a trail, a COND CODE in the range of 0000 to 4095. But apart from this , when you want to write your own extra notes to the logs(diary), you code a SYSOUT=* parameter on the DD Statement. For the 3-step job-stream that I have written, I have set the //SYSUT2 DD statement to point to the logs. This means that, the outputs of //STEP01 and //STEP03 shall be jotted down in the logs. The first step prints/copies the contents of the Unsorted Input file to the log. The second step These are the contents of the Unsorted Input File, written to the log - These are the contents of the Sorted Output, written to the log -