Activated PACKAGE_SHIP_WITH_ALTID=ON in Endevor and now get S913 on SPFTEMPn.CNTL when doing a package ship
Article ID: 71605
Updated On:
Products
Endevor
Endevor Natural Integration
Endevor - ECLIPSE Plugin
Endevor - Enterprise Workbench
Issue/Introduction
Why are we getting S913 authorization failure on file ???.SPFTEMPn.CNTL (??? is the user's ID) and how can we fix this?
Environment
Endevor base all releases
Resolution
- This is why the authorization error happens on SPFTEMPn.CNTL.
The option PACKAGE_SHIP_WITH_ALTID=ON was initially added to package ship function done via API during the life of release 15.0 and didn't affect shipping via ISPF. This changed with 17.0 fixes RO78325 and RO78326. These changes (which are also present at 18.0) extended the PACKAGE_SHIP_WITH_ALTID logic to shipping done from ISPF.
First, the JCL is generated with the help of ISPF file tailoring services. This is done under the user's ID. Note that ISPF services always run under the user's ID and we cannot change that. The FTOPEN service creates the temporary dataset ???.SPFTEMPn.CNTL (where 'n' is the ISPF screen number). This file is owned by the user's ID ???
Next step depends on the setting of PACKAGE_SHIP_WITH_ALTID.
If it is DISABLED, the file is submitted by ISPEXEC SELECT CMD(%CISUB xxxx) where xxxx is the name of the SPFTEMPx dataset created by ISPF. %CISUB is a trivial CLIST we supply that issues a SUBMNIT command for the dataset. This runs under the user's ID and should work in all cases.
If it is ENABLED, then we submit that job under the alternate ID by the following steps::
1) Swap the TCB to the alternate ID
2) Dynamically allocate the dataset as well as an internal reader
3)Copy the dataset to the internal reader
note: CLIST CISUB is not called to submit the job.
This results in a job being submitted by the alternate ID, and has the side effect of the alternate ID reading the SPFTEMPn file which is owned by the user's ID.
Summary:
The original purpose of this option is to swap to the ALTID using the API. The API does not use the ISPF services the same way so this work in that method. We cannot swap to the ALTID directly under ISPF. As such we cannot do the File Tailoring (Skels) to a ALTID controlled file.
First, the JCL is generated with the help of ISPF file tailoring services. This is done under the user's ID. Note that ISPF services always run under the user's ID and we cannot change that. The FTOPEN service creates the temporary dataset ???.SPFTEMPn.CNTL (where 'n' is the ISPF screen number). This file is owned by the user's ID ???
Next step depends on the setting of PACKAGE_SHIP_WITH_ALTID.
If it is DISABLED, the file is submitted by ISPEXEC SELECT CMD(%CISUB xxxx) where xxxx is the name of the SPFTEMPx dataset created by ISPF. %CISUB is a trivial CLIST we supply that issues a SUBMNIT command for the dataset. This runs under the user's ID and should work in all cases.
If it is ENABLED, then we submit that job under the alternate ID by the following steps::
1) Swap the TCB to the alternate ID
2) Dynamically allocate the dataset as well as an internal reader
3)Copy the dataset to the internal reader
note: CLIST CISUB is not called to submit the job.
This results in a job being submitted by the alternate ID, and has the side effect of the alternate ID reading the SPFTEMPn file which is owned by the user's ID.
Summary:
The original purpose of this option is to swap to the ALTID using the API. The API does not use the ISPF services the same way so this work in that method. We cannot swap to the ALTID directly under ISPF. As such we cannot do the File Tailoring (Skels) to a ALTID controlled file.
- This is how to fix the issue with PACKAGE_SHIP_WITH_ALTID=ON.
- Give security access to the altid to read all files that have SPFTEMPn.CNTL
- Disable the option PACKAGE_SHIP_WITH_ALTID and include USER=altid (your altid) to the jobcards of the package ship JCL.
- Create exit as described in KB000016332. This will swap to the altid in the remote job.
Feedback
Yes
No
Powered by
