February 9, 2018

(E)JES users,

The purpose of this letter is to alert you to an issue in (E)JES releases V5R6 and V5R7 with potential for an outage.

If you have not installed, or do not use, (E)JES Web then you are not affected. If you do not run (E)JES Web in an LPAR with one or more zIIP processors, you are not affected.

(E)JES Web supports use of the <Esc> key in a manner similar to what’s supported by (E)JES for the <Attn> key in ISPF and similar environments. A long-running FIND or similar operation can be halted by pressing <Esc> one time. If a CPU loop occurs in base code, which is quite rare and represents an error condition, pressing <Esc> twice should abend the looping code, produce an SVC dump, and release the (E)JES Web user’s session.

In an environment with a zIIP processor in which (E)JES base code is erroneously looping in an enclave SRB, an attempt by the (E)JES Web user to break the SRB loop by pressing <Esc> twice can result in WAIT804-4.

The main EJESAPII TCB is correctly abended U4001 via CALLRTM TYPE=ABTERM. Unfortunately, because RETRY=NO wasn’t specified on the CALLRTM macro, SDWACLUP is not set in the SDWA. This leads to a “race” condition between the TCB and the active SRB that can destroy the TSA stack. This, in turn, can lead to a situation where the SRB becomes non-preemptible and enters an FRR recovery loop attempting to manipulate the TSA stack.

The following service items address this issue:

We regret any inconvenience this situation might cause.

Sincerely,

Phoenix Software International, Inc.