Basics of batch job monitoring, production support of AS400

I am assuming that the reader of this article is new to IBM i world.

Congratulations on landing up in IT and working with IBM i (As/400 system). There are multiple websites which can help you in understanding batch job monitoring in IBM i, in this article I am trying to share whatever I have learnt over the past few years of my experience in IBM i (also known as AS/400).

--> You can start with WRKACTJOB command, this command will show all the subsystems, job queue, jobs running in those job queue.

Once you have located where your job is, you can use option 5 to pull a list of options.

On this list you can find 3 important options, option 1, option 11, option 14 

If you select option 1 - you will be able to see what is the job name, number and the user who submitted this job. Another good thing that you can see, if you hit page down is what command the job is executing.

 

If you select option 11 - you can see the call stack of program ( what is a call stack ? --> Its basically the order in which one program is calling another program), along with call stack you can see exactly which statement the program is executing.

If you select option 14  - you can see which all files are being used and the RRN (relative record number) that the file is being accessed.

Now with all the above information in one place you can start your investigation / analysis of a job that has appeared in MSGW.

--> Next useful command is DSPMSG MSGQ(*SYSOPR) MSGTYPE(*INQ), this command is useful to locate the messages that are waiting for reply, in simpler words as a newbie if you see any alert email saying "your xyz job is in MSGW status", you can quickly type this command and see the message exactly.

Now, MSGW status of a job can appear due to many reasons and I will cover them in my upcoming article. For now just hit F1 wherever you see a message. The F1 key will expand the message and will show you something more than the message itself. For example it can tell what job threw that error, which program it came from and at which statement it came from.

--> Next useful command is DSPLOG and DSPJOBLOG, using these two commands you can understand the steps that the job took, before it went into MSGW status.

This article will be helpful to new IBM i programmers. In my upcoming article I will try to add more techniques to do batch job monitoring.