When a job runs on a different LPAR to the MUF it issues error:
DB00501E - OPEN ERROR - RETURN CODE 87 (003)
This indicates an XCF External Security violation.
XCF is externally secured by using the DTSYSTEM resource class with a resource name of cxxname.XCF
If permission is denied to the MUF userid, XCF external security is in place.
Message DB00220I will be issued during MUF startup to indicate XCF is externally secured:
DB00220I - EXTERNAL SECURITY ACTIVE FOR cxxname ON XCF
If XCF is externally secured the MUF checks if jobs are allowed from the remote system by checking the DTSYSTEM resource class using a resource name of cxxname.XCFFROM.from-system.groupname.
Permission must be allowed to the MUF userid. If permission is denied, the job is not allowed to run and will fail with a RC 87 (003).
Normally external security messages of the DTSYSTEM resource checks are suppressed in the MUF.
Add the following option to the MUF startup parameters to not suppress the security messages:
This will show all the external security messages during startup.
The security definitions for the resource class DTSYSTEM must be defined as follows :
Resource name cxxname.XCF - the MUF userid must be denied access to turn on XCF external security.
Resource name cxxname.XCFFROM.from-system.groupname - the MUF userid must be allowed access to allow jobs to run against the MUF from that system and group.
The following security rules need to be coded to resolve this:
RDEFINE [email protected] cxxname.XCF UACC(NONE) PERMIT cxxname.XCFFROM.* CLASS([email protected]) ID(muf_userid) ACC(ALTER)
$KEY(cxxname) TYPE(DTS) XCF UID(*) PREVENT XCFFROM.- UID(muf_userid) ALLOW
TSS PER(ALL) DTSYSTEM(cxxname.XCF) ACCESS(NONE) TSS PER(muf_userid) DTSYSTEM(cxxname.XCFFROM.) ACCESS(ALL)
Another way to resolve this is to force the job to run in the same LPAR as the MUF by adding the following card after the JOB card: