We have a label printer issue where on-site technicians have been working for some time now to get the device back up and running.
The jobs that go to this queue are auto-generated (through scanning) and number about 1000-1500 jobs per day. Because of the on-going problem with the printer, the queue is permanently in a stalled state and total job numbers quickly run into the 1000s. Apart from deleting the VMS queue and letting the jobs just fly out the window, I was wondering what impact having 1000s of jobs being handled by the queue manager might have on overall performance, etc. I know we can clean up the queue on a daily basis, so once again, I'm just looking for any general guidance on the potential affects of having huge numbers of jobs being submitted to the queue....thanks.
I once did tests on a alphastation 500 running 7.3 and created more than 10.000 entries. No problems but when the problem is solved it's best to do a $ mcr jbc$command diag 7 to reset the queue db size.
Of course, if you monitor the queue entries in DCL or whatever, this could take a very long time to complete.
There isn't typically a huge effect here, and tens of thousands of entries in the queue database isn't all that much.
The DIAG 7 stuff is an old-time and formerly undocumented command that compresses part of the job controller database. It became documented in a copy of the release notes a while back:
-- You can shrink the size of the journal ï¬ le by having a privileged user issue the following DCL command: $ MCR JBC$COMMAND DIAG 7 Executing this DCL command check points the queue journal ï¬ le and shrinks the ï¬ le to the minimum size required for queue system operation. ---
Current versions of the Job Controller have become somewhat better in related areas, too. The usual "apply current ECO kits" rule applies here.
