You don't need to put anything in ECSA. Your name/token pair can return all of the pertinent information for PC call. The PC call can then extract everything else from the secondary address space. I think the three things that need to be in the name/token pair are the ALET, PC # (which I think can be left out if it's the only PC number, which should be zero, right?), and the address of an anchor block of data in the secondary address space.
It doesn't resolve the need for an APF authorized program, but it does resolve a need for anything in (E)CSA. David Logan Manager of Product Development, Pitney Bowes Business Insight http://centrus.com W: (720) 564-3056 C: (303) 818-8222 -----Original Message----- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Dave Day Sent: Friday, September 26, 2008 13:47 To: [email protected] Subject: Re: Living without User Key CSA Let me try this again. Hopefully without doing 2 things at once. You can have your server create a PC routine that does the authorized functions. The PC number is placed in the ECSA block of storage. The client code picks up the PC number, and calls the authorized functions by executing the PC. Depending upon where you place the PC routine, you will either need to make it a space-switch routine, or a current primary. Check out the Extended addressability guide. Establishing a PC routine is a fairly straight forward coding function. Send me an e:mail offlist if you need help. --Dave ----- Original Message ----- From: "Patrick Roehl" <[EMAIL PROTECTED]> Newsgroups: bit.listserv.ibm-main To: <[email protected]> Sent: Friday, September 26, 2008 2:33 PM Subject: Living without User Key CSA > 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. > > ---------------------------------------------------------------------- > 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 > ---------------------------------------------------------------------- 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 ---------------------------------------------------------------------- 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
