|
|
 |
OpenVMS VAXQMAN02_071 VAX V7.1 JOB CONTROLLER/QUEUE MANAGER ECO Summary
|
TITLE: OpenVMS VAXQMAN02_071 VAX V7.1 JOB CONTROLLER/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.
Copyright (c) Compaq Computer Corporation 1999. All rights reserved.
Modification Date: 11-FEB-99
Modification Type: Updated Kit Supersedes VAXQMAN01_071
PRODUCT: OpenVMS VAX
COMPONENTS: Job Controller (JBC$JOB_CONTROL.EXE)
Queue Manager (QMAN$QUEUE_MANAGER.EXE)
SOURCE: Compaq Computer Corporation
ECO INFORMATION:
ECO Kit Name: VAXQMAN02_071
ECO Kits Superseded by This ECO Kit: VAXQMAN01_071
ECO Kit Approximate Size: 558 Blocks
Kit Applies To: OpenVMS VAX V7.1
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 kit exists for JBC$JOB_CONTROL and QMAN$QUEUE_MANAGER on OpenVMS
VAX V7.1. This kit addresses the following problems:
Problems Addressed in the VAXQMAN02_071 Kit:
o False Audit Alarm When Batch Job Submitted
Submitting a job to a batch queue, set up with a default protection,
generated a CONTROL access audit alarm, even though the user did not
request control access. As a result, OPERATOR.LOG was flooded with
security audit messages. For example, doing
$ SET AUDIT/CLASS=QUEUE/ALARM/ENA=ACCESS=FAIL:
$ SUBMIT X.COM/QUE=TEST/NOLOG/NOTIFY
%%%%%%%%%%% OPCOM 3-MAR-1998 12:08:20.38 %%%%%%%%%%%
Message from user AUDIT$SERVER on CHEN
Security alarm (SECURITY) on CHEN, system id: 65422
Auditable event: Object access
Event time: 3-MAR-1998 12:08:20.38
PID: 000000DF
Source PID: 000000CE
Username: USER
Process owner: [LASTNAMEO,FIRSTNAMEO]
Object class name: QUEUE
Object name: TEST
Object owner: [SYSTEM]
Object protection: SYSTEM:M, OWNER:D, GROUP:R, WORLD:S
Access requested: CONTROL
Status: %SYSTEM-F-NOPRIV, insufficient privilege
or object protection violation
Job X (queue TEST, entry 4) started on TEST
$
Job X (queue TEST, entry 4) completed
o Two Spool Problems Occurred:
1. Files copied to a spooled device were not deleted from the
spool area when its corresponding entry was deleted from the
queue.
2. Prior to OpenVMS V6.2, a spooled batch queue could run without
a problem, even if the command procedure was broken. However,
on OpenVMS V6.2 and OpenVMS V7.1, a broken command procedure
passed to a spooled batch queue would result in lost files.
o Queue Manager-related STKNOTCHANGE Errors
An error can occur when the Default Form reference count is
incremented in two similar circumstances:
1. The error can occur while batch queues are being created.
2. It can also occur when generic queues are initialized.
Changing the stock on the DEFAULT form can result in an error, even
when there are no references (jobs, queues, ...) to the DEFAULT
form. The following error was observed:
$ DEFINE/FORM /STOCK=NEW_STOCK DEFAULT 0
%JBC-E-STKNOTCHANGE, the stock associated with a form
NOTE: If a customer uses multiple Queue Managers on a system,
ALL Queue Managers must be running in order for a form
update to occur. If all Queue Managers are not running,
the STKNOTCHANGE error will occur.
Problems Addressed in the VAXQMAN01_071 Kit:
o BATCH/PRINT problems corrected:
+ The DCL command SHOW QUEUE/MANAGER would hang on some
nodes. The job controller process would hang in the LEF
state.
+ After queue manager failover from VAX to Alpha, the job
controller process (on Alpha) hangs in LEF causing the
queues on the Alpha system to remain in a starting state.
The queues remain there until the job controller is
stopped and restarted. Also, the SHOW QUEUE/MANAGER
command hangs.
o When booting in a new node or failing over the queue manager,
the cluster appears to hang. The job controller continually
produces dump files at SYS$SYSTEM:JBC$JOB_CONTROL.DMP. The
error reported in the dump is "feature incompatible with
previous system version".
o DCPS-F-STREAMUSE and queue become stuck in starting errors:
+ Occasional flagging of a DCPS-F-STREAMUSE error while
starting DCPS queues.
+ Print Queues (either LAT, DQS or DCPS) may hang stuck in a
starting state.
o When SJC$_DELETE_FILE_ALWAYS deletes a print job created through
PATHWORKS, the spool file is not always deleted. It deletes only
when the job is in an execution state.
INSTALLATION NOTES:
The images in this kit will not take effect until the system is rebooted.
If there are other nodes in the VMScluster, they must also be rebooted in
order to make use of the new image(s).
If it is not possible or convenient to reboot the entire cluster at this
time, a rolling re-boot may be performed.
|
Files on this server are as follows:
|
»vaxqman02_071.README
»vaxqman02_071.CHKSUM
»vaxqman02_071.CVRLET_TXT
»vaxqman02_071.a-dcx_vaxexe
|
