>I'm an application programmer who is trying to reengineer a piece of our >infrastructure that uses subpool 241 (CSA/ECSA). My management wants to be >compatible with AllowUserKeyCSA(no) so I'm seeking advice on how this can be >done.
>The current design has been working well for many years. It uses a small >piece of storage in CSA to anchor a list of dataspaces. The server program >creates the anchor table in CSA (key 9), saves attributes of each dataspace >(ALET, size, usage statistics, etc.) into the anchor table, sets itself >non-swappable, and just waits to be stopped. The server process is >APF-authorized. >The client program is not authorized. It accesses the anchor table in CSA >via a name/token pair. It then uses the attributes found in the anchor >table to gain access to the dataspace. The client program must be able to >access and update the anchor table storage. >What is the best way to perform this functionality without a common area? >In other words, what technique can be used to store the list of dataspace >attributes so it's available to the client program? It's also important >that the client program not require APF-authorization. >Any and all ideas or references to design guides are greatly appreciated. Keep in mind that user key SCOPE=COMMON data spaces have the same security exposure as user key CSA, so if you are using them, you would be wanting to address that exposure as well as the exposure from your infrastructure's use of user key CSA. ALLOWUSERUSERKEYCDS(YES|NO) in DIAGxx is on my "to do" list. Jim Mulder z/OS System Test IBM Corp. Poughkeepsie, NY ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
