Job Descriptions: Underused and Underappreciated
Published: March 10, 2010
by 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))
Here's a job description for the same task.
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