| » contact hp |
search: |  | more options |
| Supportall of hp US

|  | HP Services Software Patches |

» | software & drivers
» | ask Compaq
» | reference library
» | forums & communities
» | support tools
» | warranty information
» | contact support
» | parts
» | give us feedback
patches by topic
» | DOS
» | OpenVMS
» | Security
» | Tru64 Unix
» | Ultrix 32
» | Windows
» | Windows NT
associated links
» | what's new
» | contract access
» | browse patch tree
» | search patch tree
» | join mailing list
connection tools
» | nameserver lookup
» | traceroute
» | ping
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.
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

privacy statement | using this site means you accept its terms |
© 1994-2002 Hewlett-Packard Company