By Shawn Gordon
A powerful feature of MPE is the concept of user-defined job queues. You can use these JOBQ commands to exert granular job control that is tightly coupled with MPE/iX. HP first introduced the commands in the 6.0 release.
For example, you only want one datacomm job to log on at a time, but there are 100 that need to run. At the same time you need to let users run their reports, and you want to allow only two compile jobs to run at a time. Normally you would set your job limit down to 1, then manually shuffle job priorities around and let jobs go. In the new multiple job queue controlled environment, you can define a DATACOMM job queue whose limit was 1, an ENDUSER job queue whose limit was 6 (for example), and a COMPILE job queue whose limit was 2. You could also set a total job limit of 20 to accommodate your other jobs that may need to run.
Three commands accommodate the job queue feature:
NEWJOBQ qname [;limit=n]
ALTJOB, JOB and
STREAM all include the parameter
As an example, I am going to create a new job queue called SHOWTIME that has a job limit of 1. You will notice the job card of the sample job has a JOBQ parameter at the end to specify what queue it is to execute in.
STREAM SHOWTIME.JCL;JOBQ=SHOWTIMEto put it into my job queue. Here’s the coding to do this:
!SETVAR HPAUTOCONT TRUE
I just streamed five copies of the job, and using the
LISTJOBQ command I am able to see the default system defined job queue HPSYSJQ. I haven’t been able to find out why it indicates a limit of 3500, since my current job limit was 30. [Editor’s Note: Gavin Scott reports that “All job queues have a LIMIT that is separate from the one true system LIMIT. This includes the default HPSYSJQ. The 3500 default is a number large enough that you should never run into the case where the existence of this second, un-obvious, limit on normal jobs affects you.”]
You can see my SHOWTIME job queue with a limit of 1, with one executing and five total jobs, so four are currently in a wait state. This is obvious in the SHOWJOB command below.
listjobq JOBQ LIMIT EXEC TOTAL HPSYSJQ 3500 12 12 SHOWTIME 1 1 5 SHOWJOB JOB=@J JOBNUM STATE IPRI JIN JLIST INTRODUCED JOB NAME #J2 EXEC 10S LP TUE 7:09A NP92JOB,MGR.MINISOFT #J3 EXEC 10R LP TUE 7:09A BACKG,MANAGER.VESOFT #J4 EXEC 10S LP TUE 7:09A WTRSH,MGR.WTRSH #J5 EXEC 10S LP TUE 7:09A MSJOB,MGR.MINISOFT #J6 EXEC 10S LP TUE 7:09A MASTEROP,MANAGER.SYS #J7 EXEC 10S LP TUE 7:09A VCSSERV,MGR.DIAMOND #J8 EXEC 10S LP TUE 7:09A VCSCHED,MGR.DIAMOND #J9 EXEC 10S LP TUE 7:09A JINETD,MANAGER.SYS #J10 EXEC 10S LP TUE 7:09A JWHSERVR,MANAGER.SYS #J12 EXEC 10S LP TUE 7:25A GUI3000J,MANAGER.SYS #J19 EXEC 10S LP TUE 8:08A BROLMSGJ,JOBS.REVIEW #J130 EXEC 10S LP TUE 1:06P SHOWTIME,MANAGER.SYS #J131 WAIT:1 8 10S LP TUE 1:06P SHOWTIME,MANAGER.SYS #J132 WAIT:2 8 10S LP TUE 1:06P SHOWTIME,MANAGER.SYS #J133 WAIT:3 8 10S LP TUE 1:06P SHOWTIME,MANAGER.SYS #J134 WAIT:4 8 10S LP TUE 1:06P SHOWTIME,MANAGER.SYS 16 JOBS (DISPLAYED): 0 INTRO 4 WAIT; INCL 0 DEFERRED 12 EXEC; INCL 0 SESSIONS 0 SUSP JOBFENCE= 6; JLIMIT= 30; SLIMIT= 60
Now if I want to increase the job limit for my SHOWTIME job queue, I can use the following command
You will probably notice that there are a number of nice enhancements to ALTJOB and LIMIT in support of the job queues, having uses outside of the job queues. For example, LIMIT now allows you to use a plus or minus value to increase or decrease the number, so you don’t have to use an absolute value. It is common to up the limit by one to allow another job to execute, but previously you had to check the current job limit, change it, then change it back. At least now you can just do +1 to let the job launch.
On the ALTJOB command, you can now specify HIPRI to cause a job to start up immediately and not have to play with limits to let it go. You can also alter the output device of the job. I did find during my tests that altering a job to a queue that had open slots didn’t seem to allow the job to release if you sent it to the system default HPSYSJQ. However, if you sent it to a user-defined job queue that had room left in it for another job to execute, then it would launch immediately.
There is another side benefit of job queues, and that is ensuring that never more than one version of a job logs on. For example, if you have some background job running and you cannot have a second copy running, but there is nothing that prevents it, you could create a job queue for it with a limit of 1 that would keep any extra copies from launching.
This is just one example of an extended use of the feature. If you try to purge a job queue that is currently in use, you will receive this message:
Cannot purge job queue as
there are jobs
running/waiting in that queue. (CIERR 12251)
If you try to stream a job into a queue that does not exist you will receive the message
JOBQ parameter expected.
Spooler internal error occurred. (CIERR 4522)
The job will be streamed regardless — however, it won’t start executing, because there is no queue for it to execute in. The major problem is that the job will stream into a WAIT state because there is no queue available for it. At this point you can’t abort it, you can’t create the queue it was intended for and have it work, you can’t alter it into the system job queue because of whatever the problem is that we described earlier. Finally you can try to create a new queue and alter it into it. The LISTJOBQ will show it as a job for that queue, but it will never start executing. The only way to get rid of the job is to shut down the system and do a START NORECOVERY.