OpenVMS VAXQMAN03_070 VAX V5.5-2 - V7.0 Queue Manager ECO Summary
TITLE: OpenVMS VAXQMAN03_070 VAX V5.5-2 - V7.0 Queue Manager ECO Summary
NOTE: An OpenVMS saveset or PCSI installation file is stored
on the Internet in a self-expanding compressed file.
The name of the compressed file will be kit_name-dcx_vaxexe
for OpenVMS VAX or kit_name-dcx_axpexe for OpenVMS Alpha.
Once the file is copied to your system, it can be expanded
by typing RUN compressed_file. The resultant file will
be the OpenVMS saveset or PCSI installation file which
can be used to install the ECO.
Ray,
Here is the title for the abstract:
*OpenVMS] VAXQMAN03_070 VAX V5.5-2 - V7.0 Queue Manager ECO Summary
The text of the abstract is below the line of "**********".
Angela
********************************************************************************
Copyright (c) Digital Equipment Corporation 1997. All rights reserved.
OP/SYS: OpenVMS VAX
COMPONENT: Queue Manager
SOURCE: Digital Equipment Corporation
ECO INFORMATION:
ECO Kit Name: VAXQMAN03_070
ECO Kits Superseded by This ECO Kit: VAXQMAN02_070
VAXQMAN01_070
VAXQMAN01_062
VAXQMAN03_061
VAXQMAN02_061
VAXQMAN01_061 (CSCPAT_1176)
VAXQMAN02_060
VAXQMAN01_060 (CSCPAT_1175)
VAXQMAN8_U2055
VAXQMAN07_U2055 (CSCPAT_1165)
VAXQMAN06_U2055
VAXQMAN05_U2055
VAXQMAN04_U2055
VAXQMAN03_U2055
QMAN$02_U2055
QMAN$01_U2055
ECO Kit Approximate Size: 2862 Blocks
Saveset A - 126 Blocks
Saveset B - 522 Blocks
Saveset C - 504 Blocks
Saveset D - 558 Blocks
Saveset E - 648 Blocks
Saveset F - 504 Blocks
Kit Applies To: OpenVMS VAX V5.5-2, V5.5-2H4, V5.5-2HF,
V6.0, V6.1, V6.2, V7.0
System/Cluster Reboot Necessary: Yes
Installation Rating: 3 - To be installed on all systems running
the listed versions of OpenVMS which
are experiencing the problems described.
NOTE: In order to receive the full fixes listed in this kit,
the following remedial kits also need to be installed:
None
ECO KIT SUMMARY:
An ECO (patch) kit exists for the Queue Manager and Job Controller
on OpenVMS VAX V5.5-2 through V7.0. This kit addresses the following
problems:
Problems addressed in VAXQMAN03_070 for OpenVMS VAX
o Being re-issued to keep Message Routines current with Library
RTL kit. There are no new fixes in this kit.
Problems addressed in VAXQMAN02_070 for OpenVMS VAX V6.1, V6.2, and V7.0:
o Delete/Entry on a starting job fails to stop the job. The job
stays in an aborting state and processes to completion.
o When F$GETQUI is used at DCL to obtain queue manager information,
certain combinations of items can hang the process.
o The queue manager stops after the following messages are
issued in OPCOM:
%%%%%%%%%%% OPCOM 8-MAY-1996 14:52:17.83 %%%%%%%%%%%
Message from user QUEUE_MANAGE on HULAW3
%QMAN-W-LOWMEMORY, the queue manager process may require more
virtual memory than is currently available
%%%%%%%%%%% OPCOM 8-MAY-1996 14:53:07.20 %%%%%%%%%%%
Message from user QUEUE_MANAGE on HULAW3
%QMAN-F-ALLOCMEM, error allocating virtual memory
%%%%%%%%%%% OPCOM 8-MAY-1996 14:53:07.24 %%%%%%%%%%%
Message from user QUEUE_MANAGE on HULAW3
-LIB-F-INSVIRMEM, insufficient virtual memory
Problems addressed in VAXQMAN01_070 for OpenVMS VAX V6.1, V6.2, and
V7.0:
o Latsym symbiont processes run with less than the maximum
number of queues assigned.
NOTE: According to OpenVMS Engineering, the fixes discussed below
have been included in OpenVMS VAX V7.0. There are some fixes
that have been included in previous versions of OpenVMS and
those versions are specified in text following the problem
descriptions.
Problems addressed in VAXQMAN01_062 for OpenVMS VAX V6.2:
o With OpenVMS Alpha V6.2, a 'SUBMIT' command using a wildcard
character fails to create a batch job. This is a change in
behavior from OpenVMS V6.1.
o The log files created via the 'SUBMIT/NOPRINT' command executed
from within SYSTARTUP_VMS.COM are placed in the SYS$SYSTEM directory
instead of the SYS$MANAGER directory as expected. This is not
consistent with the behavior of SYSTARTUP_VMS.COM on all previous
versions of the operating system.
o The SYS$COMMON:[SYSEXE]SYS$QUEUE_MANAGER.QMAN$JOURNAL queueing
system journal file extends to approximately 41,000 blocks
after the upgrade from OpenVMS Alpha V6.1 to OpenVMS Alpha V6.2.
Problems addressed in VAXQMAN01_062 for OpenVMS VAX V5.2-2,
V5.5-2H4, V5.5-2HF, V6.0, V6.1, V6.2:
o Over time, the number of symbiont processes running on the
system increases.
o When image accounting is enabled, the ASTCNT for a batch job
grows from its initial setting, and the batch job subsequently
fails with the following messages:
RMS-F-BUG, Fatal RMS Condition, process deleted.
R0 = 1C (EXQUOTA)
R2 = FFFFFFF8 (CANTDOAST)
Each time an image is activated and terminated in a batch
process, the AST quota of the process is incremented by 1.
Problems addressed in VAXQMAN03_061 for OpenVMS VAX V5.5-2, V5.5-2H4,
V6.0 and V6.1:
o VAXQMAN02_061 and previous VAXQMAN ECO kits contained both QMAN
(queue manager, job controller) and PRTSMB (print symbiont) fixes.
This ECO kit, VAXQMAN03_061, contains only the QMAN fixes and
supersedes only that portion of the previous kits. The PRTSMB
fixes have been moved to a new kit, VAXPRTS01_061, which
supersedes the PRTSMB portion of the previous kits.
Problems addressed in VAXQMAN03_061 for OpenVMS VAX V6.0 and V6.1:
o The accounting data reported by the DCL command
'ACCOUNTING/SUMMARY/REPORT=PAGES' command is not always correct.
Incorrect data is reported after jobs are reprinted and occurs
because the number of pages printed is accumulated in each
separate accounting record instead of being overwritten. For
example:
Print Seq Acctng Record ACCOUNTING/SUMMARY/REPORT=PAGES
number Pages Printed Output
--------- -------------- -------------------------------
1 3 3
2 6 9
3 9 18
The actual number of pages printed by the user is nine but the
summary accounting reports eighteen pages.
o At startup the queue manager may dump with a BADLOGIC error in
the WILD_MASTER_NAME routine. After this occurs, it is necessary
to recreate the queue manager to restart the queue system.
o QMAN security fix.
Problems addressed in VAXQMAN02_061 for OpenVMS VAX V6.1, VAXQMAN02_060
for OpenVMS VAX V6.0, and VAXQMAN8_U2055 for OpenVMS VAX V5.5-2:
o If a 'START/QUEUE' DCL command is immediately followed by a
'STOP/QUEUE/RESET' DCL command, the symbiont may dump with a
BADLOGIC error in PSM$REPORT. The queues managed by the failing
symbiont are stopped and there is a loss of service.
o When the queue manager rejects a symbiont message, the
INVSMBMSG signal sent to the operator log does not uniquely
identify the reason why the symbiont message is considered
invalid. An integer value has been added to the INVSMBMSG
signal to uniquely identify the reason why the queue manager
rejects a message from the symbiont.
o The 'SHOW/QUEUE/FORM' DCL command does not terminate the
form/char name search correctly. This might cause the
QMAN$MASTER.DAT file to be locked for unnecessarily
long periods which causes queue system response to be
intermittently slow. This occurs particularly on systems
with many queues and forms. On large production systems,
the delays can become severe if the problem occurs during
queue journal file checkpointing. The Queue Manager may
crash with a BADLOGIC error in the WILD_MASTER_NAME routine.
Problems addressed in VAXQMAN02_061 for OpenVMS VAX V6.1 and in
VAXQMAN02_060 for OpenVMS VAX V6.0:
o A print job may show a pending status due to a stock type
mismatch. This may occur even though the stock of the form
on the print job matches the stock of the form mounted on
the queue.
Problems addressed in VAXQMAN02_061 for OpenVMS VAX V6.1:
o The job controller may access violate and crash in the
IDENT_PACKET accounting routine.
Problems addressed in VAXQMAN01_061 for OpenVMS VAX V6.1,
VAXQMAN01_060 for OpenVMS VAX V6.0 and in VAXQMAN07_U2055
for OpenVMS VAX V5.5-2:
o In OpenVMS VAX V5.4, a DCL 'SHOW QUEUE' command listed timed
jobs in /AFTER_TIME order. Beginning with OpenVMS VAX V5.5,
timed jobs are listed by priority, then by /AFTER_TIME. Jobs
with the same /AFTER_TIME are listed in entry number order,
not in submit time order. This fix restores support for the
earlier 'SHOW QUEUE' order.
o When a symbiont sends a TASK_STATUS request other than
DEVICE_STATUS to the Queue Manager and no job is active, then
the request is rejected with the following message:
Message from user QUEUE_MANAGE on ARDAS1 %QMAN-I-INVSMBMSG,
invalid data in message from symbiont on queue TEST is being
ignored
Support has also been added for additional TASK_STATUS requests
besides DEVICE_STATUS when there is not an active job.
o Issuing the PRINT/DELETE command for may files (several
thousand) may cause the Queue Manager to crash with an
Access Violation (ACCVIO) because data is not properly
copied from one address to another.
o The file associated with a 'PRINT/DELETE' job is deleted
even if the print is unsuccessful.
Problems addressed in VAXQMAN01_061 for OpenVMS VAX V6.1 and
in VAXQMAN01_060 for OpenVMS VAX V6.0:
o Timed jobs of equal priority sometimes execute in submit
time order, not in release time (/AFTER_TIME) order. This
occurs when multiple jobs are pending execution.
o Memory that is allocated for storing output values for a DCL
'SHOW QUEUE/MANAGER' command is not deallocated after command
completion. If a user does a series of SHOW QUEUE/MANAGER
commands the job controller can crash with an insufficient
virtual memory error.
Problems addressed in VAXQMAN01_061 for OpenVMS VAX V6.1:
o If there are outstanding jobs during a failover of the Queue
Manager, the Job Controller may crash the system with the
system service NOMOREPROC error status.
o When $GETQUI with the DISPLAY_JOB function and the THIS_JOB
flag is called from a non-batch process, a JOBQUEDIS error is
returned even when the queue manager is running. This problem
also occurs when a process is spawned from a batch process.
Problems addressed in VAXQMAN07_U2055 for OpenVMS VAX V5.5-2:
o A display of user-written and image accounting records
generated by a batch job shows no queue entry number, queue
name or job name for that job.
Problems addressed in VAXQMAN06_U2055 (and previous kits) for
OpenVMS VAX V5.5-2:
o If a print job is submitted and then modified to use the
default form, the next time the form reference counter is
decremented it could attempt to go past zero which would
force the Queue Manager to crash.
o When a job is printed or submitted to a generic queue using
either the PRINT/NOTIFY or SUBMIT/NOTIFY command, the notifi-
cation message incorrectly displays the name of the generic
queue instead of the execution queue.
o A privileged user doing a SUBMIT/USER where the USER account has
more than 256 rights identifiers, can cause the Queue Manager to
fail with an ARBTOOBIG error. The Queue Manager should not fail,
it should return the error to the submitter.
o The Queue Manager disables a queue when there are exactly 28
target queues.
o If an entry, characteristic or form number is supplied to
$GETQUI via the QUI$_SEARCH_NUMBER item code and the
QUI$V_SEARCH_WILDCARD flag is set in the QUI$_SEARCH_FLAGS
item, the queuing system treats the request as a wildcard even
though an entry was specified. If a second call is then made
to $GETQUI using the same item list, a JBC$_NOMOREXXX status
is returned.
o A pending job assigned from a stopped queue to an idle queue
using the ASSIGN/MERGE command is not immediately scheduled.
The job remains pending until the target queue is stopped and
restarted, or until another job is queued to execute on the
target queue.
o The SJC$_ALTER_JOB function with the SJC$_NO_NOTE or the
SJC$_NO_OPERATOR_REQUEST item has no effect on the target
job.
o During system shutdown, if the job controller reports the
following error:
%JBC$-W-SYSERRORPC, LIB$CONVERT_DATE_STRING of
SHUTDOWN$TIME system service error ...
the queuing system terminates instead of pausing momentarily
while the Queue Manager fails over to another node.
o When the rename process of the queue journal file fails, only
the primary RMS status is sent to OPCOM. The secondary status,
which in many cases contains the true cause of the problem, is
not signaled.
o If an invalid directory or device specification is entered
in a 'START/QUEUE/MANAGER device:[directory]' command or the
queue file cannot be found in the specified directory, the
running Queue Manager will abort.
o During failover of the Queue Manager, a node can sometimes
receive a link request from the new Queue Manager before
the data structures associated with the previous link are
cleared. When this occurs, the node will not be able to
communicate with the new Queue Manager.
o During a heavy system load, a process may lose the response
to a queueing request causing the queue command to hang
indefinitely.
o A number of tables in the Queue Manager do not include entries
for reserved function codes. This can cause the the Job
Controller or the Queue Manager to terminate if an application
is written that uses these codes.
o A non-privileged program can cause the Job Controller to
terminate if a reserved $SNDJBC function is used.
o When moving the queue database in a cluster environment, the
the logical 'QMAN$MASTER' must be defined on all nodes before
Queue Manager is restarted in order to use queue-related
commands. If the logical is defined after the Queue Manager
is started, queue commands will hang.
o If a symbiont responds to a Queue Manager request after
the specified queue has been stopped, the Queue Manager
creates a process dump but then recovers. The process
dump shows that the symbiont message was being processed
on a stopped queue.
o If a user-written or user-modified symbiont calls
SMB$INITIALIZE or PSM$PRINT and specifies an invalid
maximum stream number, the Queue Manager may crash.
o In OpenVMS VAX V5.4, if the STOP/QUEUE/NEXT command was
issued to stop a queue and then a START/QUEUE command
was quickly issued, the Stop_Pending status set by the stop
request would be cleared. In OpenVMS VAX V5.5, this ceased
to be true.
o If the PRINT/USER or SUBMIT/USER commands are used to enter
a job into a queue, the account name associated with the
job is that of the submitter and not that of the user as
it should be.
o The queue database contains all of the job information in
the SYS$QUEUE_MANAGER.QMAN$JOURNAL file. Sometimes disks
containing the queue database are backed up with the expec-
tation that the backed up version of the database can be
used on the next reboot. The queuing system does not support
backing up the journal file of its database. The result is a
database that contains no jobs.
o If the Queue Manager fails over to another node and more than 84
blocks are used in the journal file of the queue database to
record the failure, a start up related transaction may be split
across the journal file that is created to prevent the old one
from growing too large. If there is another failure within a
the next few minutes while the "new" journal file is current, the
Queue Manager's attempt to start up with this new journal file
fails.
o If a program is written using $SNDJBC and the item code
'SJC$_CHARACTERISTIC_NUMBER' is specified after SJC$_FILE_COPIES,
SJC$_FILE_IDENTIFICATION or SJC$_FILE_SPECIFICATION in the item
list, the values of those item codes will be lost.
o If the QUEUE_MANAGER process is abnormally aborted (node crash)
after it has committed a queue transaction, but before it is able
to modify the queue file, the next incarnation of the
QUEUE_MANAGER process will corrupt the queue record.
o If the DCL command 'START/QUEUE/SEARCH=nnn' is issued, the
following informational message is displayed:
%JBC-I-ITEMREMOVED, meaningless items were removed
from request
o SUBMIT/AFTER=time/PRIORITY=nn does not schedule jobs properly.
For example, if two jobs are submitted at the same time, but
with different priorities, the job that is scheduled first is
the one that comes off the timer queue first even if is not
the one with the highest priority.
o The queue and journal file error handling routine produces
a process dump when the disk on which the queue or journal files
reside is write locked. A write locked disk should be handled
as an environment problem, not a coding problem. A process dump
is not necessary when this condition is encountered.
INSTALLATION NOTES:
In order for the corrections in this kit to take effect, the system
must be rebooted. If the system is a member of a VMScluster, the
entire cluster should be rebooted.
This patch can be found at any of these sites:
Colorado Site
Georgia Site
Files on this server are as follows:
vaxqman03_070.README
vaxqman03_070.CHKSUM
vaxqman03_070.CVRLET_TXT
vaxqman03_070.a-dcx_vaxexe
vaxqman03_070.b-dcx_vaxexe
vaxqman03_070.c-dcx_vaxexe
vaxqman03_070.d-dcx_vaxexe
vaxqman03_070.e-dcx_vaxexe
vaxqman03_070.f-dcx_vaxexe
|
