Flip This Job Number: Adjusting The Job Queue Control Utility For Job Number Resets
November 12, 2014 Hey, Joe
|
I just read your article on creating a skeleton program for controlling IBM i job queues creating a skeleton program for controlling IBM i job queues. In your job queue physical file (WRKJOBQPF) that contains the list of jobs inside a specific job queue, you keyed that file by the six-digit job number of each job in queue. I think that’s a bad idea. Here’s why. . . –Charles Charles continues: “On busy systems where the job number can flip (over to 000001) daily, it introduces a period of time where the results will not be desirable. Needless to say, this occurs any time the job number resets (to 000001). Since the output of the job queue spooled file lists the jobs in their proper order, you are searching a specific field where you have no need to specify a key.” Charles has a point here. For a modern system, the IBM i operating system has a relatively limited number of job numbers it can assign to submitted jobs. IBM programmed the system so that it can only number submitted jobs up to six digits long. This means the possible range of job numbers for an IBM i partition is 000001 through 999999, or roughly about 1 million unique job numbers. And when your system passes 999999 jobs, it flips over and starts counting again at job number 000001. It’s also important to note that reusing job numbers on an IBM i doesn’t cause an issue with duplicate jobs, because the operating system refers to an individual job by the unique “job number/user name/job name” combination instead of by just the job number. The Problem And job number resets happen more often than you might think. On smaller partitions, it may take longer to submit a million jobs and flip the job number, perhaps a year or two. But on bigger partitions where you may be running tens of thousands of jobs a day, the job number can flip on a regular basis, perhaps several times a week or month. In my WRKJOBQPF file, I keyed the file by job number (the JOBNUM field) in descending sequence. The DDS for WRKJOBQPF looks like this. A R JOBQJOB
A FILLER1 1A TEXT('FILLER FLD 1')
A JOBNAME 10A TEXT('JOB NAME')
A FILLER2 3A TEXT('FILLER FLD 2')
A USERNAME 10A TEXT('USER NAME')
A FILLER3 3A TEXT('FILLER FLD 3')
A JOBNUM 6A TEXT('JOB NUMBER')
A FILLER4 99A TEXT('Filler FLD 4')
A K JOBNUM DESCEND
Which keeps the jobs in order from newest (largest job number) to oldest (newest file number) AS LONG AS the file numbers haven’t flipped over from 999999 to 000001. If the job numbers flip to 000001, then the job order imposed by the JOBNUM descending key will be turned around. The newer jobs with low job numbers will be at the bottom of the file while the older higher job number records will be at the top of the file. And you won’t be able to process the jobs in a job queue by arrival sequence order. As Charles pointed out, this is easily corrected by removing the JOBNUM key altogether and just processing the records in arrival number sequence, like this: A R JOBQJOB
A FILLER1 1A TEXT('FILLER FLD 1')
A JOBNAME 10A TEXT('JOB NAME')
A FILLER2 3A TEXT('FILLER FLD 2')
A USERNAME 10A TEXT('USER NAME')
A FILLER3 3A TEXT('FILLER FLD 3')
A JOBNUM 6A TEXT('JOB NUMBER')
A FILLER4 99A TEXT('Filler FLD 4')
By doing this, my skeleton job program will always process the job queue records in the order they were received, without regard to job number. Doing it this way will keep jobs with flipped job numbers starting at ‘000001’ on top of older jobs with job numbers in higher job number ranges. Order will be restored and kept in the job queue file, no matter what. So if you’re using my job queue control utility for processing jobs in arrival order, be sure to make this one small change in the WRKJOBQPF file. It could make a big difference in the way you process job queue entries. –Joe Joe Hertvik is an IBM i subject matter expert (SME) and the owner of Hertvik Business Services, a content strategy organization servicing the computer industry. Email Joe for a free quote for any upcoming projects. He also runs a data center for two companies outside Chicago, featuring multiple IBM i ERP systems. Joe is a contributing editor for IT Jungle and has written the Admin Alert column since 2002. Check out his blog where he features practical information for tech users at joehertvik.com. RELATED STORY Admin Alert: A Skeleton Utility Program For Controlling IBM i Job Queues
|
