Spool main task gets error messages ESF761 and ESF775 at startup.

Products

• Spool

Issue/Introduction

During SPOOL main task start up messages ESF761 and ESF775 are always displayed.

ESF761 JES->ESF INTERFACE - SUBSYSTEM REQUEST ERROR, RC=00, SSOBRETN=32, SSS2REAS=36
ESF775  SAPI REQUESTS FOR DEST=ESF     DISABLED

The error may refer to other destinations besides ESF.

 

Environment

JES2 JES2PARM is setup with DESTDEF NODENAME=REQUIRED

Spool ESFPARM is setup with:

 XFERSAPI=YES (default)
 XFERDEST=FORCE
 XFEROPT=8

Cause

When the JES2 DESTDEF parameter is set to NODENAME=REQUIRED, the XFERSAPI interface posts the following messages:

ESF761 JES->ESF INTERFACE - SUBSYSTEM REQUEST ERROR, RC=00, SSOBRETN=32, SSS2REAS=36
ESF775  SAPI REQUESTS FOR DEST=ESF     DISABLED

This return code means that Spool has requested a SYSOUT for a destination that is not defined to JES.
Since it is not possible to create a SYSOUT for a destination that is not defined to JES2 when NODENAME=REQUIRED is set, Spool should not be configured to make that request.

Resolution

These messages normally do not require any action unless the reported name IS supposed to be defined in JES2.

Since JES2 thinks the request is invalid, we would never get any sysout returned for it.  

With that being the case, there is no reason to continue to make a request that will always be flagged as invalid.  

With the exception of the request for sysout whose destination is equal to the Spool SUBID, the messages can be eliminated by using the XFERNODE parameter on the NODE to remove the invalid request.  

To eliminate the messages when the SUBID destination is reported as disabled, the simple solution would be to define a DESTID equal to your SUBID ESF as follows:

$ADD DESTID(ESF),DEST=Unnn

(where Unnn must specify an unused local JES2 route code)

If the destination is supposed to be defined and it has been added to JES2, you will have to issue a Spool REINIT command to add it to the list of requests for SAPI processing. 

You should no longer receive the ESF761/ESF775 messages after this change.

An alternative solution if this node is not receiving files from JES2 via XFER is to add the keyword XFERNODE=NO to the NODE definition.