On Fri, 14 Jul 2006 15:54:00 +0000 "Jeffrey D. Smith" <[EMAIL PROTECTED]> wrote:
:>========================================================= :>-----Original Message----- :>From: "Binyamin Dissen" <[EMAIL PROTECTED]> :>Sent: 7/14/2006 5:39 AM :>To: "[email protected]" <[email protected]> :>Subject: Re: cross memory assembler program help :>On Fri, 14 Jul 2006 07:17:40 -0400 Peter Relson <[EMAIL PROTECTED]> wrote: :>:>If you are in a cross-memory environment and need to access the ASXB, the :>:>following options are available: :>:> If you want the ASXB of the primary address space, locate the ASCB of :>:> the primary address space (for example, EPAR to extract the ASID, and :>:> the LOCASCB to get its ASCB, then use ASCBASXB to access the ASXB) :>:> If you want the ASXB of the home address space, use AR-mode with ALET=2, :>:> and PSAAOLD as the address of the ASCB :>:> If you want the ASXB of the secondary address space, you can use ESAR to :>:> extract the ASID, LOCASCB to get the ASCB address, and ALET=1 in AR-mode :>:> If you want the ASXB of a "random" address space, there are some things :>:> that are possible, and some that are not, depending on authority, :>:> depending on whether the target space is non-swappable. If the space is :>:> non-swappable, for example, and you can find its STOKEN (note that there :>:> is no general programming interface for returning to you the STOKEN of a :>:> random address space; in theory, something running in that space would :>:> have had to put it somewhere where you can access it), you could use :>:> ALESERV ADD to add the address space to your access list and use AR-mode :>:> with the returned ALET. :>:>This same information applies, basically, to anything in the private :>:>storage of an address space. :>If the primary address space has an appropriate AX so that access to the :>random address space would be allowed, another way to access its storage is to :>set it as secondary address space. :>The API to get the STOKEN is to SRB over and ALESERV EXTRACTH, though it does :>appear that the ASSB has it. :>What you are suggesting is violating system integrity rules. Abusing :>an AX=1 to look at an arbitrary address space is definitely not the :>intended design. "Looking back" at a secondary address space is designed :>for a unit of work that is dispatched from (or through) that space. It :>violates integrity rules to use SSAR to look at an arbitrary address :>space. What "integrity rules" are you referring to? AX=1 means that the unit of work can SSAR to any address space. That is its definition. :>The reason we have STOKEN is to avoid the integrity issues that arise :>from reusable ASN and other integrity exposures. Always a good idea to know what one is doing. :>If you really need to look at an arbitrary address space, then get its :>STOKEN and dispatch an SRB using that STOKEN instead of the ASCB. The SRB :>can then use a space-switch PC to deliver information back to your space. :>Somehow you must know "a priori" that you have the correct STOKEN. That is :>usually done by the target space putting its STOKEN somewhere (name:token :>services or common storage) that you can get it. Subject to delays and requires a dispatcher cycle. If that is adequate for your needs, fine. -- Binyamin Dissen <[EMAIL PROTECTED]> http://www.dissensoftware.com Director, Dissen Software, Bar & Grill - Israel Should you use the mailblocks package and expect a response from me, you should preauthorize the dissensoftware.com domain. I very rarely bother responding to challenge/response systems, especially those from irresponsible companies. ---------------------------------------------------------------------- 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
