Job Descriptions: Underused and Underappreciated

March 10, 2010 Ted Holt

If every machine attached to the Internet were running a robust operating system like the IBM i, I doubt the malware problem would be nearly as severe as it is. Having said that, I wonder once again, as I do from time to time, why those who use IBM i neglect so many of its wonderful features. Today my thoughts turn to job descriptions.

Before talking about job descriptions, let’s consider for a moment what a job is. Early in my career I acquired the bad habit of referring to a program or group of related programs as a job. I have since learned to use proper terms, like “program” and “application”. When we tell a computer to run a program in order to perform work, only then do we have a job.

My late friend Ernie Malaga explained to me that a job, like a human, has a lifecycle. It’s born, it works, it dies. I would add that it’s planned (we hope) and leaves behind evidence (e.g., in reports and properly updated database files) of a beneficial existence.

Another part of the analogy is that a job exists within an environment. The purpose of a job description is to define the environment in which a job will live out its life. For example:

the job queue from which the job will enter the subsystem;
the priority at which the job will run;
the CL command that will run;
the list of libraries that the system will search for unqualified objects.

For a complete list of job attributes, see the help text of the Create Job Description (CRTJOBD) command.

By way of example, here’s a typical Submit Job (SBMJOB) command.

SBMJOB CMD(CALL PGM(COST2741R))
       JOB(COSTING)
       JOBQ(PRODUCTION)
       OUTQ(COSTACCT)
       PRTTXT('Company confidential')

Here’s a job description for the same task.

CRTJOBD JOBD(COSTING)
        JOBQ(PRODUCTION)
        OUTQ(COSTACCT)
        PRTTXT('Company confidential')
        RQSDTA('CALL PGM(COST2741R)')

And here’s how to submit the job using the job description.

SBMJOB JOB(COSTING) JOBD(COSTING) OUTQ(*JOBD) RQSDTA(*JOBD)

One thing I like about using a job description is that the job can be made to run the same way no matter where it is submitted from.

I also like that changing the way the job behaves requires a simple Change Job Description (CHGJOBD) command, rather than a modification to a CL program or menu.

And if you want to create an autostart job, you must have a job description. See Admin Alert: Using OS/400 Autostart Jobs for Repetitious Server Processing, by Joe Hertvik, for more information.

But what I most like about job descriptions is that almost every bit of information a job needs is stored in one tidy place where I can keep up with it.

If you give it some thought, you’ll probably come up with some good places to use job descriptions in your shop.

Admin Alert: Using OS/400 Autostart Jobs for Repetitious Server Processing

                     Post this story to del.icio.us
               Post this story to Digg
    Post this story to Slashdot