I think you need to stop and read/refresh your cross-memory knowledge from the "Synchronous Cross-Memory Communication" section of the "MVS Extended Addressability Guide".
What you are attempting to do is dangerous without full understanding of the above. Remember that the basic purpose of a PC-ss is issued from a *client* address space is to change the *primary* address space ID so that it can easily access storage in the "server" address space - eg adding requests to queues etc etc. The originating (HOME) address space ID does not change. If your PC-ss captures information and then adds a request to a queue for later async processing by another server task then you *CANNOT* rely on the H<>P<>S environment as most likely the request handling code is running H=P=S. If the async server task needs to communicate with or resume the client, then SRB processing will probably be required - typical example is that PC-ss will SUSPEND client until async processing is complete and then client will be RESUMEd by SRB scheduled back into client ASID. If this is the case, then make your PC-ss capture as much client identification information that it needs and store it in the request control block so that you can keep track of your callers. Rob Scott Lead Developer Rocket Software 77 Fourth Avenue . Suite 100 . Waltham . MA 02451-1468 . USA Tel: +1.781.684.2305 Email: [email protected] Web: www.rocketsoftware.com -----Original Message----- From: IBM Mainframe Discussion List [mailto:[email protected]] On Behalf Of Phil Smith Sent: 25 June 2014 17:42 To: [email protected] Subject: Re: Address space puzzle Rob wrote: >I would be surprised if RACROUTE did not support x'00000001' or x'00000002' as >valid values in ACEEALET - therefore I am guessing that the ACEE pointer that >you have is incorrect. Well now. This is very interesting. I happen to have 16 bytes of reserved storage in a common control block, so at the point in the first module where I'm about to extract stuff from the ACEE (and have done the SAR to the home address space) I copy ACEEUSRI into that area, along with storing the address of the ACEE. Around the RACROUTE, I load R4 with that stored ACEE value, do the SAR again (on AR4 this time!), and dump. What I find is that R4 is pointing to empty storage, but the copied ACEEUSRI is correct. So it feels like the definition of "home" has changed. Is that possible? This is a multitasking STC. I'm still fuzzy on the concept of a "home" address space, but it seems like if this STC has multiple clients, "2" to mean "home" can't mean the same thing all the time. I don't fully understand (maybe I should stop saying that--it's obvious!) what happens between the first module, which gets control just after the PC, and the later one, which is much later, but it seems like the environments must have changed, since we're not running as the client at that point. For example, if I force a program check in the first module, DB2 kills the client program and reports "Y'all took an 0C1". If I do the same in the second module, I get a dump and the STC exits. Does this help any? The guy who wrote this code had a fair amount of experience with cross-memory stuff, and so the fact that he does an ALESERV ADD makes me think it *is* necessary. I still wonder why the ESAR (after the SAR with 2) and LOCASCB and copying the STOKEN and doing the ALESERV didn't work. That would seem like it should have gotten me the real ASID (and looking at the value stored at the time, it looked right). ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
