Update PIPE in ACFREP (aka AOFRSRPY) to expose messages IEE600I in order to allow further AT processes to trap IEE600I

We would like to suggest an enhancement for the way ACFREP (AOFRSRPY) replies to WTORs.
Currently, the PIPE named ISSUECMD executes the reply command via CORRCMD and then locates the message IEE600I and save to a stem named resp. This works gracefully, however, the last stage is "LOGTO NETLOG", which causes the message IEE600I to be registered in NetView's log but cannot be processed by any other AT entry.

This way, users who have alerts based on WTORs (in addition to them) are not able to suppress these alerts when the WTORs are answered, unless the DOM action and Actiondl functions are used. Having the message IEE600I would simplify this process.

The suggestion for analysis and possible implementation is to use the stage EXPOSE, instead of LOGTO NETLOG, which will cause the message to be registered in the NetView's log and also be exposed for processing by further AT entries. Since the ACFREP program internally calls AOFRSA0E in order to process the reply response, and is also defined to SA z/OS AT INGMSGSA based on message IEE600I, this internal call could be removed in order to avoid duplicities in execution of AOFRSA0E.

We understand this code is available for a long time with no problems, and we also understand a deep impact analysis must be performed, but we would like to suggest this as an enhancement to SA z/OS (possibly via APAR for the available and supported releases, or for the next releases that have not yet been GA).

Below is an example, from Netlog, of how processing of message IEE600I works with LOGTO NETLOG or EXPOSE:

LOGTO NETLOG:
PIPE LITERAL /IEE600I REPLY TO 001 IS/ | LOGTO NETLOG
IEE600I REPLY TO 001 IS

EXPOSE:
PIPE LITERAL /IEE600I REPLY TO 001 IS/ | EXPOSE
CNM493I INGMSGSA : 03260039 : AOFRSA0E
IEE600I REPLY TO 001 IS