Getting S047 abend in MQ Series, CA LDAP Server or IBM HTTP Server (IMWEBSRV) when using SSL connections with CA-ACF2 for z/OS and IBM PTFs UA76980 or UA76979 are applied

Document ID : KB000056934
Last Modified Date : 14/02/2018
Show Technical Document Details

Description

The S047 abend may be caused by a

RACROUTE REQUEST=AUTH,CLASS=XFACILIT,STATUS=ACCESS,ENTITYX=GSK.ENABLE.SSLV2.DEFAULT
or
RACROUTE REQUEST=AUTH,CLASS=XFACILIT,STATUS=ACCESS,ENTITYX=GSK.ENABLE.SSLV3.DEFAULT

issued by SSL processing.

RACF does not require APF authorization for this call - ACF2 DOES
require APF authorization because it shows a user's access to a
resource.


Required Updates

The solution is to create a GSO SAFDEF record to allow the call to run
NON-APF authorised.
The situation has been seen in different environments where SSL is involved.
One environment was within CA LDAP Server  - which is running entirely out of a USS environment.
When that is the case, the SAFDEF should be coded as...

      ACF
      SET CONTROL(GSO)
      INSERT SAFDEF.NOAPF ID(@NOAPF) PROGRAM(*PATHNAM) RB(*PATHNAM) NOAPFCHK -
      RACROUTE(REQUEST=AUTH,CLASS=XFACILIT,STATUS=ACCESS)
      F ACF2,REFRESH(SAFDEF)
      END

Note: *PATHNAM is the actual name used for programs in the USS environment.
This will allow the RACROUTE to process.

If the environment that is getting the S047 abend is in MQ series,
the SAFDEF should be coded as...
 
      ACF
      SET CONTROL(GSO)
      INSERT SAFDEF.NOAPF ID(@NOAPF) PROGRAM(CSQXSERV) RB(CSQXSERV) NOAPFCHK -
      RACROUTE(REQUEST=AUTH,CLASS=XFACILIT,STATUS=ACCESS)
      F ACF2,REFRESH(SAFDEF)
      END

If the environment that is getting the S047 abend is in HTTP Server (IMWEBSRV),
the SAFDEF should be coded as...
 
      ACF
      SET CONTROL(GSO)
      INSERT SAFDEF.NOAPF ID(@NOAPF) PROGRAM(IMWHTTPD) RB(IMWHTTPD) NOAPFCHK -
      RACROUTE(REQUEST=AUTH,CLASS=XFACILIT,STATUS=ACCESS)
      F ACF2,REFRESH(SAFDEF)
      END

Create the SAFDEF, refresh the in-storage SAFDEF table with F ACF2,REFRESH(SAFDEF)
command and then recreate the situation.

If it is recreatable after the SAFDEF is coded - please run a ACF2 SAF SECTRACE

so that the PROGARM and RB values for the SAFDEF can be obtained.

ST SET,ID=APF,JOBNAME=xxxxxxxx,FORMAT=DUMP,TRACE=ALL,END

then run ACFRPTST with the DETAIL option.
NOTE: If the SECTRACE is not run with TRACE=ALL/DETAIL option you will not see the
RACROUTE request in the SECTRACE report.
A SECTRACE record consists of two types of entries.

A "before" entry (before ACF2 has process the request.)
An "AFTER" entry (after ACF2 has processed the request.) 

When a RACROUTE request abends, you will only see the "BEFORE" entry.

When you see that the "before" entry does not have an "AFTER" entry,

use the PROGRAM and RB values to create the SAFDEF.  

This process was brought in by IBM PTFs UA76980 UA76979 for SSL
processing.

 

For details on the ACF2 SAF SECTRACE operator command see the CA ACF2™ for z/OS
Systems Programmer Guide, Chapter 6: Special Usage Considerations section 'Tracing SAF
Requests'.