• The Four Hundred
  • Subscribe
  • Media Kit
  • Contributors
  • About Us
  • Contact
Menu
  • The Four Hundred
  • Subscribe
  • Media Kit
  • Contributors
  • About Us
  • Contact
  • Admin Alert: A Skeleton Utility Program For Controlling IBM i Job Queues

    October 8, 2014 Joe Hertvik

    From an IBM i operations viewpoint, there are several scenarios where you need to automate job queue management. Situations where you may have to automatically change one or more parameters for a job waiting in job queue include:

    • Looking for a specific job and automatically moving it to another job queue.
    • Moving all jobs in queue to a different job queue when they are held up behind a slow-moving job or a job waiting for a reply in batch.
    • Rearranging or changing job priorities so certain jobs run before or after other jobs.
    • Detecting an excessive number of jobs in queue and sending out an alert to monitoring personnel.

    To set up an automated job that collects information about and adjusts jobs waiting in queue, I created the WRKJOBQDB CL program. WRKJOBQDB is a skeleton program that collects data about all the running jobs in a specific job queue and then performs specific action on those jobs. In the sample program below, WRKJOBQDB collects job queue data and then changes all jobs with a specific job name to run at a lower priority than newer jobs (allowing newer jobs to run ahead of the changed jobs). WRKJOBQDB can easily be modified to perform other functions, serving as skeleton code for job queue management.

    WRKJOBQDB has a very simple database and format. It gathers information about a specific job queue, creates a database containing information on jobs in that job queue, and performs actions against specific waiting jobs, if those jobs are found in queue.

    Here’s the detailed code for the WRKJOBQPF database file and the WRKJOBQDB program.

    The WRKJOBQPF Database

    Job queue information is transferred from the printout that’s created when you run a Work with Job Queue (WRKJOBQ) command over your target job queue. Here’s the DDS and physical file layout for the WRKJOBQPF file used in this utility.

    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
    

    For the sample program, I created WRKJOBQPF in a library called RUNLIB.

    This file is 132 characters long, the same report width as the QPRTSPLQ printer file output it originated from, as shown in the code. This file is the core engine your program uses to examine and modify jobs waiting in your target job queue.

    WRKJOBQPF is keyed by each job’s job number in descending order (DESC). This is because we must process the oldest jobs in queue first, allowing us to change jobs in the order in which they were submitted. This prevents jobs from executing out of sequence as they are being changed.

    Also notice that all of the WRKJOBQPF fields are alpha-numeric. This is because we will be dumping the entire contents of a QPRTSPLQ spooled file into the file, including the report headers, column headings, etc., making a database copy of a spooled file. The skeleton program sorts through the file records and only processes those job queue entries it’s interested in. It ignores irrelevant data in WRKJOBQPF, such as data from report headers.

    Changing Your Waiting Jobs

    The WRKJOBQDB CL program code shown below copies my target job queue contents (as passed into the program) into the WRKJOBQPF file, reads the file, and changes specific job queue entries to run at job priority six.

    0001.00              PGM        PARM(&JOBQNAME &JOBQLIB)
    0002.00              DCLF       FILE(RUNLIB/WRKJOBQPF)
    0003.00
    0004.00              DCL        VAR(&JOBQLIB) TYPE(*CHAR) 
    LEN(10)
    0005.00              DCL        VAR(&JOBQNAME) TYPE(*CHAR) 
    LEN(10)
    0006.00
    0007.00              DLTF       FILE(QTEMP/WRKJOBQPF)
    0008.00              MONMSG     MSGID(CPF0000)
    0009.00
    0010.00
    0011.00
    0012.00              CRTDUPOBJ  OBJ(WRKJOBQPF) FROMLIB(RUNLIB) +
    0013.00                           OBJTYPE(*FILE) TOLIB(QTEMP)
    0014.00              CHGPF      FILE(QTEMP/WRKJOBQPF) 
    MAXMBRS(*NOMAX)
    0015.00
    0016.00              OVRDBF     FILE(WRKJOBQPF) 
    TOFILE(QTEMP/WRKJOBQPF) +
    0017.00                           SECURE(*YES)
    0018.00
    0019.00              WRKJOBQ    JOBQ(&JOBQLIB/&JOBQNAME) 
    OUTPUT(*PRINT) /* +
    0020.00                           Retrieve job queue library 
    information */
    0021.00
    0022.00              CPYSPLF    FILE(QPRTSPLQ) TOFILE(QTEMP/WRKJOBQPF)
    0023.00
    0024.00 LOOP:
    0025.00              RCVF
    0026.00              MONMSG     MSGID(CPF0864) EXEC(GOTO 
    CMDLBL(ENDLOOP))
    0027.00
    0028.00              IF         COND((&JOBNAME *EQ 'JOB1') *OR 
    (&JOBNAME +
    0029.00                           *EQ 'JOB2')) THEN(DO)
    0030.00              CHGJOB     JOB(&JOBNUM/&USERNAME/
    &JOBNAME) 
    JOBPTY(6)
    0031.00              MONMSG     MSGID(CPA0701 CPF1321)
    0032.00              ENDDO
    0033.00
    0034.00              GOTO       CMDLBL(LOOP)
    0035.00
    0036.00
    0037.00   ENDLOOP:   DSPJOBLOG  OUTPUT(*PRINT) 
    0038.00
    0039.00              ENDPGM
    

    Here’s what the code does.

    Line 0001.00 declares that the program will be called with parameters equal to the jobq name (&JOBQNAME) and the jobq library (&JOBQLIB) that you want to examine. &JOBQNAME and &JOBQLIB are defined in lines 0004.00 and 0005.00.

    Line 0002.00 defines the WRKJOBQPF file to the program.

    Lines 0007.00 and 0008.00 look for instances of the WRKJOBQPF file in the QTEMP library and deletes that work file, if it’s present.

    The Create Duplicate Object (CRTDUPOBJ) command in lines 0012.00 and 0013.00 creates a copy of the WRKJOBQPF file in the running job’s QTEMP library. This allows you to run multiple versions of the WRKJOBQDB program at the same time, since each copy will have its own copy of the database.

    Line 0014.00 increases the number of records the WRKJOBQPF file can contain, in case there are more jobs in queue than available records in WRKJOBQPF.

    Lines 0016.00 and 0017.00 override the WRKJOBQPF file to the new copy created in line 0014.00. Any references to WRKJOBQPF in this program will point to the copy in QTEMP.

    The Work with Job Queue (WRKJOBQ) command in lines 0019.00 and 0020.00 creates the QPRTSPLQ spooled file containing information about the contents of the job queue.

    Line 0022.00 copies the contents of the QPRTSPLQ spooled file created in lines 0019.00-0020.00 into the newly created WRKJOBQPF file in QTEMP.

    Lines 0024.00 through 0034.00 create a loop that processes all the records in the QTEMP/WRKJOBQPF file. When the program gets to the end of the file (line 0026.00), it ends the program by branching to the ENDLOOP label in line 0037.00.

    Lines 0028.00 through 32.00 examine each incoming record. If the job name is equal to ‘JOB1’ or ‘JOB2’, the Change Job (CHGJOB) command changes the job priority of the job to ‘6’. By default, most jobs enter the system at priority ‘5’. Changing a job to priority ‘6’ guarantees that any jobs entering the system before the JOB1 or JOB2 jobs are ready to start executing immediately. The new jobs will have priority and start running before the JOB1 and JOB2 jobs in queue are submitted for execution.

    Also notice the Monitor Message (MONMSG) command on line 0031.00. MONMSG looks for the following messages when executing the CHGJOB command and tells WRKJOBQDB to ignore them.

    • CPA0701 (&3 received by &1 at &4. (C D I R)–A message was received by WRKJOBQDB
    • CPF1321 (Job &1 user &2 job number &3 not found)–The job is no longer in the system

    This code is necessary in case the program is trying to change the priority on a job that has completed running and is no longer in the system.

    Lines 0037.00 through 0039.00 print out the job log and end the program.

    WRKJOBQDB is a simple program that allows you to look at job queue entries and make changes as needed. It’s a specialized tool that useful for known work flow situations, where one or more jobs is causing IBM i processing problems. Modify as needed.

    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.



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

    Share this:

    • Reddit
    • Facebook
    • LinkedIn
    • Twitter
    • Email

    Tags:

    Sponsored by
    Midrange Dynamics North America

    Git up to speed with MDChange!

    Git can be lightning-fast when dealing with just a few hundred items in a repository. But when dealing with tens of thousands of items, transaction wait times can take minutes.

    MDChange offers an elegant solution that enables you to work efficiently any size Git repository while making your Git experience seamless and highly responsive.

    Learn more.

    Share this:

    • Reddit
    • Facebook
    • LinkedIn
    • Twitter
    • Email

    Sponsored Links

    BCD:  Webinar: Deliver First-Rate IBM i Mobile Applications Quickly. October 16
    System i Developer:  Upgrade your skills at the RPG & DB2 Summit in Minneapolis, Sept 30 - Oct 2.
    MiNET:  Automate PDF, email, Fax, Archiving & more with ArtForm400. Try us for a FREE Redbox code!

    More IT Jungle Resources:

    System i PTF Guide: Weekly PTF Updates
    IBM i Events Calendar: National Conferences, Local Events, and Webinars
    Breaking News: News Hot Off The Press
    TPM @ EnterpriseTech: High Performance Computing Industry News From ITJ EIC Timothy Prickett Morgan

    IBM i Shops Turn to Vault400 for Protection App Dev, Database Top IBM i TR9 and TR1 Enhancements

    Leave a Reply Cancel reply

Volume 14, Number 23 -- October 8, 2014
THIS ISSUE SPONSORED BY:

Bug Busters Software Engineering
WorksRight Software
Shield Advanced Solutions

Table of Contents

  • Find A View Of A View Of A View. . .
  • A Bevy Of BIFs: Updates
  • Admin Alert: A Skeleton Utility Program For Controlling IBM i Job Queues

Content archive

  • The Four Hundred
  • Four Hundred Stuff
  • Four Hundred Guru

Recent Posts

  • Public Preview For Watson Code Assistant for i Available Soon
  • COMMON Youth Movement Continues at POWERUp 2025
  • IBM Preserves Memory Investments Across Power10 And Power11
  • Eradani Uses AI For New EDI And API Service
  • Picking Apart IBM’s $150 Billion In US Manufacturing And R&D
  • FAX/400 And CICS For i Are Dead. What Will IBM Kill Next?
  • Fresche Overhauls X-Analysis With Web UI, AI Smarts
  • Is It Time To Add The Rust Programming Language To IBM i?
  • Is IBM Going To Raise Prices On Power10 Expert Care?
  • IBM i PTF Guide, Volume 27, Number 20

Subscribe

To get news from IT Jungle sent to your inbox every week, subscribe to our newsletter.

Pages

  • About Us
  • Contact
  • Contributors
  • Four Hundred Monitor
  • IBM i PTF Guide
  • Media Kit
  • Subscribe

Search

Copyright © 2025 IT Jungle