Apologies, but disregard question #2. I obviously have been doing something wrong in the past. I have everything set up perfectly, works great, permanent SVC installed, SVC working perfectly, PC routine working perfectly, etc. etc. etc.
So I went back and tried ASCMODE=AR again and SSWITCH=YES again with loading the PC routine into private storage again, and lo and behold, it seems to be happy. So, as is usually the case, I have no idea what I was doing wrong, but it seems to be happy now (and function as I would have expected now.) David Logan -----Original Message----- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Logan, David Sent: Saturday, December 15, 2007 5:28 PM To: [email protected] Subject: Basic Cross Memory questions I see one of my questions answered, and even with that, not entirely. So with that, let's jump in. I have three: (1) This one has been partially answered, but what is the *best* way for a problem state program to get XMS authorization to a PC routine in another address space (non-system LX)? I chose using an SVC, but that seems like a HUGE overkill in order to issue two entire macros (ATSET and LXSET.) (2) My PC routine must be in common storage. The manuals indicate that the PC routine can be in private memory of the target address space (PRIMARY, but not HOME). However, if I load my PC routine into private storage, I get an ABEND. It must be in common storage even if my ASCMODE=AR and SSWITCH=YES is specified on my ETDEF. What's up with that? I don't need my routine in common storage, don't want it in common storage. I just can't seem to "PC" to it unless it is in common storage. ----- Those are the two operational questions. Then I ran into a bizarre situation at a customer site when trying to beta this thing that I wrote. I knew that we weren't going to have enough time to contact their systems programming department and get an IPL and a permanent SVC in, so I used the SVCUPDATE macro as part of the intialization routine of the started task. However, it seemed that something under the covers either (a) prevented SVCUPDTE from working, but without any obvious return code, or (b) "reset" the SVC table to a previous value, causing the XMS setup (as described in #1) to fail intermittently. (3) Does anyone know of an MVS security setting, or a third party product that controls the use of SVCUPDTE? I thought once in supervisor state, you were there. Thanks! David Logan ---------------------------------------------------------------------- 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 NOTICE: This E-mail may contain confidential information. If you are not the addressee or the intended recipient please do not read this E-mail and please immediately delete this e-mail message and any attachments from your workstation or network mail system. If you are the addressee or the intended recipient and you save or print a copy of this E-mail, please place it in an appropriate file, depending on whether confidential information is contained in the message. ---------------------------------------------------------------------- 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
