IBM Support

PI98247: After batch events config change, batchManagerZos hangs waiting for job completion; batch joblog events not published correctly.


You can track all active APARs for this component.

APAR status

  • Closed as program error.

Error description

  • After batch events config change, batchManagerZos hangs
    waiting for job completion; batch joblog events not
    published correctly.

Local fix

Problem summary

  • ****************************************************************
    * USERS AFFECTED:  All users of IBM WebSphere Application      *
    *                  Server Liberty- Batch                       *
    * PROBLEM DESCRIPTION: After batch events config change,       *
    *                      batchManagerZos hangs waiting for job   *
    *                      completion; batch joblog events not     *
    *                      published correctly.                    *
    * RECOMMENDATION:                                              *
    The problem with the batchManagerZos client can be explained by
    first explaining the more general problem here.
    The batch events function, which publishes a series of JMS
    messages upon different batch job lifecycle events, is enabled
    and configured by the "batchJmsEvents" element.
    By default, these messages are published to a documented topic
    tree with root of "batch".  However, a different root can be
    chosen, with server config such as:
      <batchJmsEvents topicRoot="root" />
    One of these events is the writing of a new job log part, and
    the corresponding message is published to topic:
    The problem here is that the batch job logging component issuing
    this message caches a reference to a batch events component
    activated from a previous configuration.   If the
    "batchJmsEvents" configuration is updated later in the lifecycle
    of the batch job logging component, it will incorrectly continue
    as if the old batch events configuration were in effect.   The
    job log event could be published to the wrong topic root, or not
    published when it should be, or published when it shouldn't be.
    Now, back to batchManagerZos, the batchManagerZos client will
    commonly be run with the --wait and --getJobLog to wait for a
    final execution status and the final job log part for the
    associated job.     This is implemented by waiting for the
    corresponding batch events.   So the fact that the final job log
    part may be published to the wrong topic tree, or not published
    at all, can cause the batchManagerZos client to hang, waiting
    for a response which won't come.
    In a similar manner, any other user processing built depending
    or waiting for this job log part message to be published could
    be disturbed or broken.

Problem conclusion

  • The batch job logging component was fixed to dynamically obtain
    a reference to the publisher component with the latest batch
    events configuration.
    One caveat:
    This whole discussion shouldn't be read to imply that
    batchManagerZos can begin subscribing to one topic root, and
    then, within the course of waiting for a single job to complete,
    adjust to handle a new topic root or a deactivation.    It just
    means that, over the life of the server, the batch events
    configuration can be changed.
    Though it is not disallowed to change batch events configuration
    during the execution of a job, this can be confusing, and is
    definitely not recommended if any other process is waiting or
    otherwise depending on the results, as batchManagerZos is in the
    case when both  --wait and --getJobLog parameters are specified
    on job submission.
    The fix for this APAR is currently targeted for inclusion in fix
    pack  Please refer to the Recommended Updates page for
    delivery information:

Temporary fix

  • Make your "batchJmsEvents" configuration problems before
    starting the server, or after starting the server but before
    beginning any use of the batch function.   Another alternative
    would be, for batchManagerZos, to use only --wait (but not --
    wait and --getJobLog), if the job log can be obtained in some
    separate manner.


APAR Information

  • APAR number


  • Reported component name


  • Reported component ID


  • Reported release


  • Status


  • PE




  • Special Attention

    NoSpecatt / Xsystem

  • Submitted date


  • Closed date


  • Last modified date


  • APAR is sysrouted FROM one or more of the following:

  • APAR is sysrouted TO one or more of the following:

Fix information

  • Fixed component name


  • Fixed component ID


Applicable component levels

  • RCD0 PSY


Document information

More support for: WebSphere Application Server

Software version: CD0

Reference #: PI98247

Modified date: 23 May 2018

Translate this page: