Overview of Job Queue’s in MPE/iX 6.0
A long awaited feature of MPE finally made it into the operating system with 6.0. This is the concept of user defined job queues. In the ‘old way of doing things’ you had a global job limit that controlled the total number of jobs that could be running at any given time, or you bought a commercial product (or maybe used something in the contributed library) to do job queues. For some, or even many people, this is just fine, but other people want to be able to have more granular control that is tightly coupled with the operating system.
For example, you only want one datacomm job to log on at a time, but there are 100 that need to run, and at the same time you need to let users run their reports, and you want to allow only 2 compile job to run at a time. Normally you would set your job limit down to 1 and shuffle job priorities around and let jobs go manually. In a multiple job queue controlled environment you would be able to define a DATACOMM job queue whose limit was 1, and ENDUSER job queue whose limit was 6 (for example), and a COMPILE job queue whose limit was 2, and a total job limit of 20 to accommodate your other jobs that may need to run.
Three new commands have been added to MPE to accommodate the job queue feature, they are;
NEWJOBQ qname [;limit=n] PURGEJOBQ qname LISTJOBQ
The commands LIMIT, ALTJOB, JOB and STREAM have all been modified to include the new parameter ;JOBQ=.
So as an example I am going to create a new job queue called SHOWTIME that has a job limit of one. 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. Alternatively I could have said STREAM SHOWTIME.JCL;JOBQ=SHOWTIME to put it into my job queue.
NEWJOBQ SHOWTIME;LIMIT=1 !JOB SHOWTIME,MANAGER.SYS,PUB;JOBQ=SHOWTIME ! !SETVAR HPAUTOCONT TRUE ! !SHOWTIME ! !SHOWCLOCK ! !SHOWME ! !SHOWVAR HPDA@ !SHOWVAR HPTI@ ! !ECHO !HPDATEF !ECHO !HPTIMEF ! !PAUSE 300 ! !EOJ
I just streamed 5 copies of the job, and using the new LISTJOBQ command I am able to see the default system defined job queue HPSYSJQ, but I never did find out why it indicates a limit of 3500 since my current job limit was 30. You can see my SHOWTIME job queue with a limit of 1, with 1 executing and 5 total jobs, so 4 are currently in a wait state. This is obvious in the SHOWJOB command that follows.
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
.
limit +1;jobq=showtime
altjob #j131;jobq=hpsysjq
You will probably notice that there are a number of nice enhancements to ALTJOB and LIMIT made in support of the job queues, but have 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 you always 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 immediatly 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, but 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 immediatly.
There is another side affect benefit of job queues, and that is ensuring that never more than 1 of a job logs on. If for example 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 the 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. (CIERR 12255)
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, and 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. I would deem this a major bug.
There is a glaring ommission in that the JOBFENCE command does not support the JOBQ parameter, and it would seem logical that it should to make the package complete. With independent JOBFENCEs for JOBQs, you would really have true multiple spooler/job queues, but with the current implementation you are only part way there.
Hopefully this helps you get started using the new job queue features. HP has done a nice job in bringing us this new feature, and hopefully they will fix up the few problems I found and add JOBFENCE in a new release of the operating system in the new future to make this wonderful new feature complete.