HP Services Software Patches - vsched_e07b021
Michael or Ray,
Here is the title for the abstract:
*PLY_SCD] VSCHED_E07B021 POLYCENTER Scheduler V2.1B (VAX) ECO Summary
The text of the abstract is below the line of "**********".
Copyright (c) Digital Equipment Corporation 1995. All rights reserved.
PRODUCT: POLYCENTER Scheduler OpenVMS
OP/SYS: OpenVMS VAX
SOURCE: Digital Equipment Corporation
ECO Kit Name: VSCHED_E07B021
ECO Kits Superseded by This ECO Kit: VSCHED_E05B021, VSCHED_E01B021
ECO Kit Approximate Size: Saveset A - 7902 Blocks
Saveset B - 9558 Blocks
Saveset C - 1764 Blocks
Cover Letter - 7 Blocks
Total of 4 files - 19231 Blocks
Kit Applies To: POLYCENTER Scheduler V2.1B
OpenVMS VAX V5.5-2, V5.5-2H4, V6.0, V6.1, V6.2
NOTE: This ECO is the complete POLYCENTER Scheduler
V2.1B product. POLYCENTER Scheduler V2.1B does
not need to be installed prior to installing
this ECO. However, a valid POLYCENTER Scheduler
license must be installed.
The product version will be V2.1B-7 after
installing this ECO.
System Reboot Necessary: No
ECO KIT SUMMARY:
An ECO kit exists for POLYCENTER Scheduler V2.1B on OpenVMS VAX V5.5-2
through V6.2. This kit addresses the following problems:
Problems addressed in the VSCHED_E07B021 kit:
o Summary information was not being written to the appropriate
VERMONT_CREAMERY file on all nodes. The Scheduler command CLOSE
LOG/SUMMARIZE would write summary information to the file
VERMONT_CREAMERY.LOG on some nodes and to the file
VERMONT_CREAMERY.OLD on other nodes. Scheduler now writes summary
information to the appropriate VERMONT_CREAMERY file on all nodes.
o The DECforms interface was incorrectly modifying the last exit
status field when other fields were modified. When viewed from the
command line interface with the SHOW JOB/FULL command, the last exit
status code showed an error. This problem has been corrected. The
DECforms interface is not available on OpenVMS Alpha in this
o Scheduler displayed corrupted records and "unknown messages" in the
Additional Comments column of VSS_REPORTS. This usually happened
when the Scheduler command CLOSE LOG/SUMMARIZE was issued while jobs
o History records were not being written to the appropriate
VERMONT_CREAMERY file. The Scheduler command CLOSE LOG/SUMMARIZE
would write summary information to the VERMONT_CREAMERY.OLD file
instead of the new VERMONT_CREAMERY.LOG file. Scheduler now writes
summary information to the VERMONT_CREAMERY.LOG file.
Note that if you use the Scheduler command SHOW HISTORY to display
summary information about a particular job before the summary
process has completed, you will receive a "no history" message. This
condition is temporary, and eventually you will be able to display
the new log file.
o Scheduler displayed the incorrect completion status for non-OpenVMS
remote agent jobs. When this happened, Scheduler incorrectly
reported that successful jobs had failed and failed jobs had
succeeded. The results could be obtained by using the SHOW HISTORY
and SHOW HISTORY /RECORDS commands, or displaying the event report
in VSS_REPORTS for the job.
This fix requires that you issue the Scheduler command CLOSE
LOG/SUMMARIZE before you install this version of Scheduler;
otherwise, job completion results may be misinterpreted due to the
restructuring of the log file. For example, the Scheduler command
SHOW HISTORY may incorrectly display a job's completion status on
reports that are contained in the log file, or in old completion
records in VERMONT_CREAMERY.LOG. The Scheduler installation
procedure contains an option that allows you to issue the CLOSE
LOG/SUMMARIZE command as part of the installation.
The event report in VSS_REPORTS sometimes incorrectly displays the
following message in the Additional Information column when
reporting information about a failed job:
%SYSTEM-S-NORMAL, normal successful completion
To work around this issue, check the job entry in the Exit Status
column to determine the correct success or failure exit status code.
o Some jobs were being load balanced to the wrong node. This problem
happened mostly when custom load balancing was used.
o The Scheduler command SHOW JOB returned a PAD length error. When
used to display a job that runs in batch mode and the job's batch
queue entry is greater than six characters (larger than 999999), the
SHOW JOB command would return the following error:
(PR2) %PAS-F-PADLENERR, pad length error
Problems addressed in the VSCHED_E05B021 Kit:
o When a large number of job failures occur, the system logical table
could become full. This would prevent job failure notification from
o When installing Scheduler in a mixed-architecture cluster, an error
occurred during the startup procedure when the procedure could not
find the shareable run time library file SCHED_RTL.EXE. The startup
procedure now runs correctly.
o The Scheduler command SHOW JOB/SYMBOLS displayed a large decimal
number instead of a blank space for SCHED$SJOB and SCHED$TJOB, when
no SJOB or TJOB had been specified. Scheduler now correctly
displays a blank space.
o Schedule Set Fiscal_Year would be off by one week if the /Start_Date
qualifier was used to modify the base date.
o Scheduler failed to send a warning message to mail distribution
lists when a job's specified max time was exceeded.
o Scheduler database was not validated after a reboot. The database
is now always validated upon reboot.
o A job with multiple dependencies could be stuck in a scheduled state
and never run if one of the predecessor jobs was set with /NORETAIN
and the dependent job was restricted to a cluster node that was not
the default executor.
o The Scheduler command SHOW JOB node"username"::job-specifier would
not work if the user name specified was not the same as the default
proxy user name. The command now works properly.
o In earlier versions of Scheduler, wide area network support was set
up manually. The Scheduler installation procedure now automatically
sets up wide area network support for DECnet Phase IV or Phase V.
The installation procedure determines which you are running, and
sets up the appropriate wide area network support.
Problems addressed in the VSCHED_E01B021 kit:
o In POLYCENTER Scheduler V2.1B-1, jobs scheduled using fiscal month
intervals were incorrectly scheduled to run a day earlier than
expected. For example, /INTERVAL=FMD2 scheduled the job to run on
26 February, rather than 27 February.
o When multiple jobs on two separate clusters were all dependent on
the same job running on a remote node, the dependent jobs on the
two clusters would run multiple times because the jobs would
receive multiple completion messages from the job on which they
depend. This would occur when commands to synchronize the jobs on
one cluster were interspersed with commands to synchronize the jobs
on the other cluster.
o If a batch mode job was set to run on a queue that was not on the
default node and the default node did not have any job slots
available, the job would go into a wait state. If the target node
had no job slots available but the default node did, the job would
POLYCENTER Scheduler now correctly checks the job count and job max
for the node on which the requested batch queue resides. If any of
the following conditions occur, POLYCENTER Scheduler will assume
there are slots available and attempt to submit the job:
+ The queue is a generic queue
+ The queue is stopped or unavailable
+ The queue is not a batch queue
The job will then fail because of the condition and the job failure
will be handled as specified when the job was created or modified.
o The command SCHED SHOW JOBS jobnumber/STATUS=job returned the
following error instead of the job's status information:
%NSCHED-F-JOBSNOTFND, No jobs specified were found
o The COPY command did not copy the identifiers RDID, EXID, and WRID
to the new job.
o If a remote job failed before the job started running, the graphical
interface did not display the failure. For example, this may occur
if the agent on which the job should run was down.
o Using more than 32 remote child dependencies caused the error
message "%PAS-F-STRASGLEN, string assignment length error" when the
command SHOW JOB/FULL or DELETE was issued.
o The latest SBQUEUE.COM has been included in this ECO kit.
The system/cluster does not need to be rebooted after this kit is
installed. However, the POLYCENTER Scheduler should be shutdown and
restarted in order for all kit changes to take effect.
Please take the following actions after the installation completes:
1) Make sure that your system startup procedure contains the following
You may want to edit SCHEDULER$STARTUP.COM to change default values
for MAX_JOBS, or to enable load balancing.
Users who are currently logged on must log off and then back on
again to gain access to the Scheduler's DCL command interface.
2) Make sure that your site specific system shutdown procedure,
SYS$MANAGER:SYSHUTDWN.COM, contains the following line:
This will assure a proper shutdown of POLYCENTER Scheduler.
You may run the Installation Verification Procedure at any time by typing
Please see the Release Notes for this ECO kit for further important
information regarding the installation of this kit.
Files on this server are as follows: