Restricted use common service area (RUCSA/Extended RUCSA)

IBM® recommends the elimination of the use of user-key (8-15) common storage, as it creates a security risk because the storage can be modified or referenced, even if fetch protected, by any unauthorized program from any address space.

IBM has provided APARs OA53355 and OA56180 to assist with identifying software programs that use user-key common storage. For those who cannot immediately eliminate all affected software programs or who need additional assistance in identifying all programs that reference user-key CSA storage, the more secure restricted use common service area (RUCSA) provided by the PTF for APAR OA56180 can be used. However, IBM still recommends the elimination of all user-key common storage.

RUCSA is a separate area from CSA that is situated between the CSA and PVT areas. Because it is a separate area, it can be managed as a secure resource. The security administrator can define, via the System Authorization Facility (SAF), which users have access to the RUCSA. Only those with SAF READ authority to the IARRSM.RUCSA profile in the FACILITY class can have access. Once defined, all requests for user key CSA storage will transparently obtain storage from the RUCSA. Application changes might not be necessary.

RUCSA (and extended RUCSA) are similar to CSA (and extended CSA) in that their storage ranges reduce the size of the 24-bit and 31-bit private area ranges for all address spaces. However, RUCSA (and extended RUCSA) differ in the following ways:
  • Only required by installations that have programs that require them.
  • Exclusively used as a user-key CSA area.
  • Accessible only from address spaces that are running under user IDs that have SAF READ authority to the IARRSM.RUCSA profile in the FACILITY class, or, on z/OS® V2R3 or earlier systems that have the VSM ALLOWUSERKEYCSA(YES) parameter specified in the DIAGxx member of parmlib. To ensure that a job has a consistent SAF authority while it is running, the authorization is checked at job start and not altered until the job ends. As such, a never-ending job that requires SAF authorization after it starts must be restarted.
  • Never converted to SQA or extended SQA.
The RUCSA is allocated just below the CSA, and the extended RUCSA is allocated above the extended CSA. They are specified in the following ways:
  • The SYSP parameter at the operator's console to specify an alternative system parameter list (IEASYSxx) that contains a RUCSA specification.
  • The RUCSA parameter at the operator's console during system initialization. This value overrides the current system parameter value for RUCSA that was established in the IEASYSxx member.
Note: Unless otherwise noted in z/OS documentation, consider RUCSA and extended RUCSA areas to be part of the CSA and extended CSA areas.

Considerations for RUCSA

Consider the following points to evaluate whether RUCSA meets your needs:
  • As RUCSA is one resource that is shared by multiple users, it does not prevent different SAF-authorized applications from altering or referencing each other's RUCSA storage.
  • RUCSA storage can only be specified in 1 MB increments. There is an approximate total of 16 MB of storage in the non-extended areas; therefore, when a non-extended RUCSA is required, adding 1 MB might not be acceptable, as it might not leave enough non-extended CSA for system-key users or non-extended private area for all address spaces.
  • RUCSA is only used for user-key CSA storage.
    • Unlike CSA, SQA cannot overflow into RUCSA storage.
    • RUCSA cannot be used for system-key CSA.
    • System-key CSA cannot be used for RUCSA.
    • It is possible for you to define a larger overall common area in order to accommodate peaks in user-key CSA (now RUCSA) and CSA usage at different times. A larger common area reduces the size of all the private areas.
  • RUCSA programming considerations:
    • RUCSA storage cannot be shared by using the IARVSERV SHARE service. RUCSA is common storage and does not need to be explicitly shared. Attempts to issue IARVSERV SHARE on RUCSA storage will be abended regardless of the VSM ALLOWUSERKEYCSA setting in DIAGxx or having SAF READ authority to the IARRSM.RUCSA resource in the FACILITY class.
    • Unlike CSA storage which all address spaces share, first references to fixed RUCSA storage by instructions that do not cause a page fault (such as LRA, LRAY, and TPROT) from an address space other than the obtainer's address space will fail with a condition code indicating that the storage is not valid. Issuers of such instructions must ensure that a page fault has occurred on RUCSA storage from the referencing address space prior to issuing the instruction.