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

Fixes are available

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:
<root>/jobs/execution/jobLogPart.

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 18.0.0.2.  Please refer to the Recommended Updates page for
delivery information:
http://www.ibm.com/support/docview.wss?rs=180&uid=swg27004980

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.

Comments

APAR Information

APAR number
PI98247
Reported component name
LIBERTY PROFILE
Reported component ID
5724J0814
Reported release
CD0
Status
CLOSED PER
PE
NoPE
HIPER
NoHIPER
Special Attention
NoSpecatt / Xsystem
Submitted date
2018-05-22
Closed date
2018-05-23
Last modified date
2018-05-23

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
LIBERTY PROFILE
Fixed component ID
5724J0814

Applicable component levels

RCD0 PSY
UP

[{"Business Unit":{"code":"BU059","label":"IBM Software w\/o TPS"},"Product":{"code":"SSEQTP","label":"WebSphere Application Server"},"Platform":[{"code":"PF025","label":"Platform Independent"}],"Version":"CD0","Line of Business":{"code":"LOB45","label":"Automation"}}]

Document Information

Modified date:
04 May 2022

Tips

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

Fixes are available

Subscribe

APAR status

Closed as program error.

Error description

Local fix

Problem summary

Problem conclusion

Temporary fix

Comments

APAR Information

APAR number

Reported component name

Reported component ID

Reported release

Status

PE

HIPER

Special Attention

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

Share your feedback

Need support?