I know that sometimes it can be a little confusing to understand how the operating system handles jobs on the AS/400, iSeries or IBM i system is setup to function. But really it is actually straight forward once you realize that there are two types of jobs that can run. All jobs fall into one of two categories of either interactive or batch.

Interactive jobs are the traditional “green-screen” or terminal type jobs where the user is actively using an emulator or an old fashioned terminal to interface with the system to input information such as entering in customer information to a file. The other type of job are batch jobs which can range from mass update programs to long running reports.

Because the interactive job system is so straight forward a majority of the system administrator’s time will be spent managing the batch jobs. When you work with and administer an AS/400 try to think of the batch processing job system in two to three parts that function together to accomplish the work.

First up you have the job queue. This is where all the information revolving around a batch job starts out before coming to life. Think of the job queue sort of like a reservation system, with all things being equal the first job into the queue is the first job out of the queue. Now it is possible to have a job with a different job priority which is sort of treating it like a VIP, that job or jobs can go to the front of the line of the queue ahead of all the other jobs with a lower priority.

Once a job has waited for it’s turn in the job queue then it gets placed into a subsystem. The subsystem is where the job is allocated system resources such as memory and a slice of the CPU time for processing. So for example if the job is a query or an RPG program to generate a report it now starts running to create the report. While a job is running in a subsystem you can see it using the WRKACTJOB command.

If you have never utilized WRKACTJOB before you should become extremely familiar with it since it is an excellent tool for administering running jobs on your system.

Now depending on what type of job there may or may not be an output. And this is where I referred earlier to it being a two or three parts. In the case of a job that generates a report, while it is being generated the output file, known as a spool file, is placed in an output queue determined by how the job was defined or where a users jobs are configured to print. You can also see the spool file or files a job is creating by taking option give and then option four from the WRKACTJOB screen. Once a job is finished running, which is determined by the code or programming of the job it then ceases to exist.

Sometimes when you have a job that doesn’t create any output like a report it can be hard to tell if it actually ran or not. One method to see if a job ran or not is to look through the system history log by using the command DSPLOG. Virtuall every little thing (and all job starts and ends) is logged in the system log so be forewarned that you may have to wade through several pages to find your specific jobs start and end timestamp. Another technique is to use the work with submitted jobs command WRKSBMJOB.

Author Bio: Get John Andersen’s proven step by step training program that shows you how to quickly master essential AS/400, iSeries and IBM i power system operations at AS/400 Training Course.

Category: Computers and Technology
Keywords: as400, iseries, ibm i