As promised in my previous article, here's the CHGJOBITPS (Change Job Interrupt Status) command that will simplify the task of setting or querying a job's current interrupt status. As noted in the aforementioned article, you need to set the QALWJOBITP (Allow Jobs To Be Interrupted) system value to enable jobs to be interrupted.

The RTVJOBITPS command provides a simple and readily-available CL command interface to retrieve a job's current interrupt status, primarily from within a CL program, and has the following command prompt panel:

---

 Retrieve Job Interrupt Status (RTVJOBITPS)

 

Type choices, press Enter.

 

CL var for ITPSTATUS     (1) . . _______  Character value

---

The CHGJOBITPS command is equally uncomplicated and offers the ability to query or modify a job's current interrupt status. Here's the command prompt of the CHGJOBITPS command:

---

      Change Job Interrupt Status (CHGJOBITPS)

 

Type choices, press Enter.

 

Interrupt status . . . . .   *CHECK        *CHECK, *DLWITP,
*ALWITP  
 

---

Both commands include an online, cursor-sensitive help text panel group, which provides all the details.

Basically, you have two options when modifying the QALWJOBITP system value, which by default will prevent any attempt to either allow a job to be interrupted or performing a job interrupt. One option is to enable all jobs to have their interrupt status changed, but initially disallow the job to be interrupted. The other option is to allow all jobs to be immediately interruptible.

Since I'm using the job interrupt facility to be able to run commands in other jobs, it's important for me to ensure that these other jobs will allow me to do so. As for the first option, it's fine for interactive jobs, where you can easily run the CHGJOBITPS command at a later point, should you need to do so, but you'll be in trouble if the job in question is a batch job.

By default, allowing commands to be run in other interactive jobs might constitute an unwanted security exposure and integrity risk. For me and my company's external IT auditors, we prefer to ensure that the cooperation of the current job user is required to run commands in his or her job.

So the ideal option for me would be if I could have the system allow interactive jobs to interrupt later and batch jobs to interrupt immediately. Maybe IBM at some point might choose to add such an option, but for now I've settled for my own, homegrown solution. For the batch jobs in which I want to have the option of running a command immediately, I have added a routing entry in the subsystem executing these jobs, which will allow me to set the job interrupt status of all jobs being routed by this entry.

Normally the default batch routing entry will point the system to the system default QSYS/QCMD routing program, which is the first program to be called when a job is initiated on a System i, but I have created my own routing program -- a very simple CL program named CBX976.

The function of the CBX976 CL program is to set the current job interrupt status for batch jobs to the value specified by the CHGJOBITPS command, which for this purpose is to allow job interrupts. Immediately following the job interrupt status setting, the CBX976 program transfers control to the system default QSYS/QCMD routing program and is then consequently removed from the job program stack. From there on, everything works as usual as far as work management is concerned.

To configure CL program CBX976 as the primary routing program for batch jobs in a given subsystem, a routing entry must be added to the subsystem description for which the above change is desired. Here's an example:

                                                            
  ADDRTGE SBSD(QGPL/QBATCH)                
          SEQNBR(9998)                     
          CMPVAL(QCMDB)                    
          PGM(CBX976)                      
          CLS(*SBSD)      

The above command will ensure that this program, by default, is run for all jobs submitted by the Submit Job (SBMJOB) command to a job queue pointing to subsystem QBATCH, provided that the SBMJOB command's default routing data value QCMDB is not changed.

All other jobs routed into subsystem QBATCH with a routing data value of QCMDB will also be altered by this routing program, following the above change. Before running the above ADDRTGE command, please verify that there is not already a routing entry in the specified subsystem with a sequence number value of 9998 or a compare value of QCMDB, and make the appropriate changes if necessary.

To ease the configuration process, you can also download and use the WRKRTGE (Work with Routing Entries) command, which was published in an earlier APIs by Example article in the Programming Newsletter; you can look up the article and code here. In case you didn't catch my previous article about the job interrupt concept and its use in the RUNJOBCMD (Run Job Command) utility, check out this link to get the details.

The following source code is included with this article:

CBX976      CLP         Set Job Interrupt Status Routing Program  

CBX9761     RPGLE       Change Job Interrupt Status - CPP         
CBX9761H    PNLGRP      Change Job Interrupt Status - Help        
CBX9761X    CMD         Change Job Interrupt Status               

CBX9762     RPGLE       Retrieve Job Interrupt Status - CPP       
CBX9762H    PNLGRP      Retrieve Job Interrupt Status - Help      
CBX9762X    CMD         Retrieve Job Interrupt Status             

CBX976M     CLP         Job Interrupt Status - Build commands     

To have all command objects and the CBX976 routing program created for you, compile and run the CBX976M program, following the instructions in the source header. Please note that if you want to make use of the subsystem routing entry technique to control the job interrupt status of specific jobs, you'll need to follow the instructions above -- the CBX976M program only compiles the CBX976 routing program.

You can download a zip file containing all the source code from the URL
http://systeminetwork.com/files/jobitps.txt.zip

Note: As with all new programs, test these routines thoroughly before placing them into a production environment. No warranty is expressed or implied.