Questions regarding the SAFHFUSR User exit
We are beginning to test an in-house written version of the CA-Top Secret SAFHFUSR user exit program.
We have a few questions about the implementation and use of the SAFHFUSR user exit program.
1) The SMP/E Usermod "UD00001" indicates that we need to IPL in order to activate the SAFHFUSR User exit program. Would we also need to IPL if we need to make some updates/modifications to the source code of the SAFHFUSR User exit program?
2) We need the ability to dynamically bypass the calling of the SAFHFUSR User exit program if the SAFHFUSR User exit program happens to malfunction or operate incorrectly. Its not obvious to us if there is a way to dynamically bypass the calling of the SAFHFUSR User exit program. Did we overlook something in the CA-Topsecret manuals or some documentation in the sample SAFHFUSR User exit program?
3) We cannot find any documentation regarding a requirement for padding of the 255-byte field ( the +8 address of the parmlist ) in the "path name translation function" of the SAFHFUSR User exit program.
4) Reviewing the installation/implementation documentation of a few IBM and NON-IBM z/OS software products, we have not found any reference on how to implement HFSSEC security rules for those products. It seems that the HFSSEC security resource class has been available for a few years but the documentation for a few products that we looked at does not have any reference to the HFSSEC security rules.
1. The need to IPL to activate this USERMOD is INCORRECT. No IPL is necessary. Once the USERMOD has been applied to your SMP library you can perform an LLA REFRESH and then reload the SAF module with the command 'F TSS,REFRESH(SAFHFSEC)'. This procedure will also work for any subsequent modifications to the code. We will change the instructions to reflect this.
2. The only way to deactivate the exit once it has been enabled is to SMP RESTORE off the USERMOD change and then perform the same LLA REFRESH and F TSS,REFRESH(SAFHFSEC) command as you will in step 1.
3. There is no requirement to pad this field, it cannot be longer then the 255 characters provided at entry.
4. Most sites using USS choose to use native USS security to protect their USS directories. It is the responsibility of the vendor application to document their security directory requirements. We can take the documentation and convert it to HFSSEC which is basically PERMITting a user to USS directories that need access to them.