SYS$QUEUE_MANAGER.QMAN$JOURNAL file

[Michael Pacenza]

I have a Sys$Queue_Manager.Qman$journal file that is 886k blocks. Howq can I remove/delete this file and start a new file?

[Steven Schweda]

Sounds like an old bug. VMS version?

http://h71000.www7.hp.com/wizard/wiz_2787.html

I quote:

The Answer is :

$ run sys$system:jbc$command
jbc$command> DIAG 7

[Ian Miller.]

or the one line version
$ MCR sys$system:jbc$command diag 7

This still works on VMS V8.2

[Michael Pacenza]

RE: Sys$Queue_Manager.Qman$Journal

VMS 6.2 and no I will not be updating to a newer version.

[Steven Schweda]

I don't remember if there was ever an ECO to
V6.2 to fix this, but you might look.

The magic command shrinks the file (back to
something very small, as I recall).

Try it. It's harmless. Double your money back
if you're not completely satisfied.

[Steven Schweda]

_I_ may not remember, but Google does. Try:

ftp://ftp.itrc.hp.com/openvms_patches/alpha/V6.2X/ALPQMAN03_062.txt

I quote:

o The queuing system journal file,
SYS$COMMON:[SYSEXE]SYS$QUEUE_MANAGER.QMAN$JOURNAL, grows to a
large size (approx. 41k blocks) after upgrading from OpenVMS
Alpha V6.1 to OpenVMS Alpha V6.2

If that sounds good, then:

ftp://ftp.itrc.hp.com/openvms_patches/alpha/V6.2X/ALPQMAN03_062.A-DCX_AXPEXE

If you needed this one, you might find some
other useful stuff in the same neighborhood.

[Ian Miller.]

AFAIK the diag 7 sends a command to the queue manager and asks it to start a new journal file. As I said it still works on VMS V8.2.

[Steven Schweda]

I think you'll find that it doesn't start a
new one; it cleans out the old one.

[Volker Halle]

Steven,

JBC$COMMAND> DIAG 7 actually creates a new SYS$QUEUE_MANAGER.QMAN$JOURNAL;1 file, writes all current job information to that new file and then deletes the old one (which it at first temporarily renamed to SYS$QUEUE_MANAGER.QMAN$JOURNAL_OLD;1).

Note: the on-disk size of the new journal file is about 10 times the number of In-memory blocks as displayed by the DIAG 7 command.

Here is an example:

$ dir *.qman*/date/fi/siz=all

Directory SYS$COMMON:[SYSEXE]

SYS$QUEUE_MANAGER.QMAN$JOURNAL;1
(22155,16,0) 2/132 22-OCT-2005 13:41:54.33
SYS$QUEUE_MANAGER.QMAN$QUEUES;1
(7330,12,0) 51/51 22-JUL-2004 08:54:56.65

Total of 2 files, 53/183 blocks.
AXPVMS $ mc 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

$ dir *.qman*/date/fi/siz=all

Directory SYS$COMMON:[SYSEXE]

SYS$QUEUE_MANAGER.QMAN$JOURNAL;1
(21520,57,0) 2/102 23-OCT-2005 08:36:25.97
SYS$QUEUE_MANAGER.QMAN$QUEUES;1
(7330,12,0) 51/51 22-JUL-2004 08:54:56.65

Note that the file-id and the creation date of the journal file has changed, so it's a NEW file.

Volker.

[Volker Halle]

Michael,

did you ever try a SHOW QUEUE/ALL command to see, if there might be lots of pending/holding/retained-on-error jobs in your system ? This could also explain a large journal file size - and that problem would NOT go away with DIAG 7 !

Volker.

[Arch_Muthiah]

Hi Mike,

I would not use these command
< Run sys$systen....
< jbc$command> DIAG 7.

Becuase this command is mainly used before taking the backup of QUEUE database files.

The above cmd does this functions...
1. checkpoint the in-memory journal files to avoid adding new job entries.

2. As we are going to take backup, the system temporarily --"deletes"-- the contents of the queue DB files from the disk as the copy of these two queue files (both *.qman_queues and *qman_journal) will be available in the memory for later copy (3rd step)

3. swap the memory contents back to the original files locations, but with new file version (1).

This job takes lots of time as the system does defragmentations while inserting the data to same locations. Now the file size naturally will be small, but not big difference.

I would suggest to try
1. stop the queue manager
2. take the backup of all three DB files
3. delete the queue files
4. create the new queue manger with /NEW_VERSION qualifier.
and
5. Restore (if need) only the master file, and queue file (qman$master.dat, *.qman_queue). As we restore the master files - gman$master.dat, make sure the new queue db files (3) locations be same as earlier)

$MCR SYS$SYSTEM:JBC$COMMAND diag 7 ( is optional - standalone, and mandatory - cluster wide queues to avoid any new entry while doing backup).

[Steven Schweda]

I wouldn't use the magic command on my system,
either. But I'm not running VMS V6.2 (without
the fix), and my journal file size is about 2
blocks, not 800K blocks. This was a known
problem on V6.2, and that was the official
work-around until the fix appeared. I haven't
needed to run the magic command for several
years, so what do I know? Ask the Wizard, I
always say.

Re: Making a new journal file.
Interesting. I always saw the ";1" and
figured that it was the same file. Apparently
not.

[Volker Halle]

Michael,

before you try to take action to try to reduce the size of your journal file, consider to spend some time analysing the possible problem.

$ MC JBC$COMMAND DIAG 5 can be used to run self-diagnostics of the queue manager:

Example:

$ mc 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

Try to find out what In-memory blocks says on your queue database. The new journal file will be created with at least 100 blocks. If the number is higher than 100, the new journal file could be up to 10 times as big as the in-memory blocks. With a huge number, you risk running out of disk space on your system disk !

If you don't have many jobs in your queue database and have DCL procedures in place to re-create your queues (and re-submit your jobs), consider to just stop the queue-manager (STOP/QUE/MANA/CLUSTER) and re-create the queue database (START/QUE/MANAGER/NEW).

Regarding the methods to be used to save and restore the queue manager database, I would like to suggest, that you read the chapter:

Managing the Queue Manager and Queue Database
- Saving and Restoring the Queue Database

in the System Manager's Manual Volume 1: Essentials

http://h71000.www7.hp.com/doc/82FINAL/aa-pv5mj-tk/aa-pv5mj-tk.HTMl

Volker.

[Volker Halle]

Michael,

when further researching this problem, I also found a huge SYS$QUEUE_MANAGER.QMAN$JOURNAL file (128k blocks) on our V6.2 VAX system (does not have patch VAXQMAN05_062 installed).

There also is another ATW (Ask The Wizard) article about this problem:

http://h71000.www7.hp.com/wizard/wiz_3333.html

Both of the ATW articles suggest the JBC$COMMAND> DIAG 7 workaround. It's an unsupported utility, but it's been provided by the people, that bring you OpenVMS, so some kind of trust should be allowed ;-)

Once our weekend batch jobs on the VAX V6.2 are done, I'll try it on our system and report back here...

Volker.

[Wim Van den Wyngaert]

I have a 7.3 on which the file is 26Kblocks.

The queues are empty. My guess is that it is a high water mark of the number of entries in the queues (did some testing on this one) ?

Any way, I did diag 7 and it is small again. And the file was re-created.

Wim

[Volker Halle]

The SYS$QUEUE_MANAGER:QMAN$JOURNAL file is normally re-created from time to time (look at it with DIR/DATE=ALL on a working system).

This mechanism seems to somehow fail on V6.2, hence the file seems to grow over time...

Here is the official TIMA article describing this problem and the DIAG 7 workaround:

http://h18000.www1.hp.com/support/asktima/operating_systems/CTI_SRC950803000686.html

I have now run this command on our OpenVMS VAX V6.2 system (with some batch jobs still active) and it has reduced the size of the journal file as expected. The batch-jobs are continuing to run...

VAXVMS $ dir/siz=all/date=all sys$system:*.qman$journal

Directory SYS$COMMON:[SYSEXE]

SYS$QUEUE_MANAGER.QMAN$JOURNAL;1
123888/123400 21-JUN-2004 04:00:22.14 17-AUG-2005 10:46:27.21

VAXVMS $ mc 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
VAXVMS $ dir/siz=all/date=all sys$system:*.qman$journal

Directory SYS$COMMON:[SYSEXE]

SYS$QUEUE_MANAGER.QMAN$JOURNAL;1
2/100 24-OCT-2005 12:55:47.17 24-OCT-2005 12:55:47.17

If you trust OpenVMS (and me), go ahead and run the JBC$COMMAND> DIAG 7 command (after saving your queue database files as described in the system manager manual - which you would always do before executing such an 'unsupported' tool, even if you trust OpenVMS).

Volker.

[Steven Schweda]

Sigh.

[Wim Van den Wyngaert]

I find it strange that it is unsupported.
Should be a VMS command.

Wim