System Crawls when job sent to print queue...

[Larry_139]

I've got an application that sends an item to the print queue (sys$print). I've used this for years without issue.

Lately, once the item is sent to the queue - the processor slows to a crawl. My 'monitor modes' typically shows around 80-90% idle. Now when this app prints - it goes to 0%. It also takes minutes for the item to print when it used to take seconds.

I'm not a big whizzo on all of this - but any ideas on where to look to try to figure out what is happening.

Thanks in advance...

[David B Sneddon]

Larry,

What version of VMS? What hardware?
How many queues do you have on the system?
How big is the QUEMAN journal file?
($ DIR SYS$SYSTEM:*.QMAN$JOURNAL)
Has anything else changed, either system or network,
around the time the problem started?

Regards
Dave

[Volker Halle]

Larry,

how is the printer connected (SHOW QUE/FULL/ALL SYS$PRINT) ?
Is a single process using all of the CPU (MONI PROC/TOPCPU) ? Which mode is the CPU in (MONI MODE) ?

Volker.

[labadie_1]

is the symbiont telnetsym ? I remember problems with some specific configurations (telnetsym logicals)

[Robert Gezelter]

Larry,

In addition to the list of information that my colleagues have mentioned, the IO rate and whether there are any IO errors occuring on the disk that holds the Queue Manager's files would be a potentially important piece of information.

- Bob Gezelter, http://www.rlgsc.com

[Andy Bustamante]

What version of VMS? How is the printer connected? (LAT or TCP/IP?) Have there been any network changes? Verify the VMS host and the network (switch?) agree on speed/duplex configuration.

You should also check NIC counters for errors.

[John Gillings]

Warning - undocumented commands follow... use at your own risk!

Larry,
Try this (requires CMKRNL):

$ MCR JBC$COMMAND
JBC$COMMAND> DIAG 5

this should return some information about your journal files. On a "normal" system with mostly idle queues, the output will look something like:

JBC$COMMAND> DIAG 5
%JBC-I-DIAGNOSTIC,
Log for playback = 0
Save old Journal files = 0
Log all requests = 0
Self diagnostics: Memory status = 00000001, Index errors = 0
Dump on error = 0
Checkpoint: State = 0, In-memory blocks = 100


If your journal file is very large, you may be able to shrink it with

JBC$COMMAND> DIAG 7

I repeat, these are undocumented, unsupported and privileged commands. They might help, and might not. Although I'm not aware of anyone ever causing any damage using JBC$COMMAND with DIAG 5 and DIAG 7, I can't guarantee that it's not possible! I'd recommend against trying any other inputs though.

[Jan van den Ende]

John,


Try this (requires CMKRNL):

$ MCR JBC$COMMAND
JBC$COMMAND> DIAG 5


gives

%JBC-F-SYSERROR, SNDJBC system service error at PC 00010000
-NONAME-F-NOMSG, Message number 00000004

...

I was interested what our queue file would give, but this does not tell me much.

Background: many years ago we had a runaway job creation.
One user (with some enhanced in-database privs) managed to do some reporting. It turned out that he created a sequential scan through the db, and for each doc in it (>3M of those!!) he generated a one-page print job.
Even though that made itself quickly noticed, before we had our hands on it and killed the process, we had >50K print jobs pending! (We even succeeded in explaining to his manager why his extra rights were withdrawn.)
Ever since, our job numbers are mostly 7 digit numbers! The .QMAN$JOURNAL file has 18372 blocks allocated.

Now, this never was any real issue, but your info suggested that I might look into it.
No luck sofar.

4-node cluster, 3 ES & 1 DS, VMS V7.3-2, patches up to ultimo oct 2004.
QMAN$MASTER on cluster-common disk.

Any comment?

Proost.

Have one on me.

jpe

[Ian Miller.]

$ MCR JBC$COMMAND
JBC$COMMAND> DIAG 7

has worked on various versions of VMS for me to shrink the queue manager journal. However I have not tried it on V7.3-2 (It did work on V7.3-1)

[Jan van den Ende]

Ian,

DIAG 5 being 'only' reporting, and DIAG 7 also modifying,
I have no courage to try 7 when 5 gives unspecified errors... :-(

Proost.

Have one on me.

jpe

[Jeffery D. Urmann]

Ian, John and Jan,

fyi...

I confirm Jan`s results with Diag 5 on an DS20 with OpenVMS v7.3-1 (non-cluster) and share his hesitation to try Diag 7.

But then I bravely tried...

Â¥ $ MCR JBC$COMMAND
JBC$COMMAND> help DIAGNOSTIC
%JBC-I-DIAGNOSTIC, Invalide selection. Valid choices are SHUTDOWN, DIAGNOSTIC
JBC$COMMAND> DIAGNOSTIC=5
%JBC-I-DIAGNOSTIC,
Log for playback = 0
Save old Journal files = 0
Log all requests = 0
Dump on error = 0
Checkpoint: State = 0, In-memory blocks = 100

Enjoy,

--Je

[Hein van den Heuvel]

Hi Larry,

It is not at all clear to me where the CPU time is being spend. In which process, in which 'mode'?
- The user process doing the SYS$SNDJBC (that is what is being used no?)
- The job_controller?
- The print symbiont?

What other resources are being consumed? Just CPU time? Memory? IOs? Diskspace? Paging activity?

Have you tried a reboot ?
(Only joking... this is not a billy box)

Then again... how about restarting the queue manager (STOP / QUEU/MANAGER and/or print queue symbiont?


Good luck,
Hein.

[Dale A. Marcy]

ES47 VMS V7.3-2

$ mcr jbc$command
JBC$COMMAND> diag 5
%JBC-I-DIAGNOSTIC,
Log for playback = 0
Save old Journal files = 0
Log all requests = 0
Self diagnostics: Memory status = 00000001, Index errors = 0
Dump on error = 0
Checkpoint: State = 0, In-memory blocks = 100
$ mcr jbc$command
JBC$COMMAND> diag 7
%JBC-I-DIAGNOSTIC,
Log for playback = 0
Save old Journal files = 0
Log all requests = 0
Dump on error = 0
Checkpoint: State = 1, In-memory blocks = 100


With no apparent ill effects.