Seymour I am agreeing with you ---------- Original Message ---------- From: Seymour J Metz <sme...@gmu.edu> To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Using AN EAX value of PC Routineto index into the Authority Table Date: Sun, 19 Jul 2020 13:47:32 +0000
I didn't claim that "every Address Space that needs to access data be defined as a subsystem." What I did say is that the easy way for a *server* to provide access is to be a subsystem. The address spaces accessing data from that server would not normally be subsystems. Don't confuse the address space needing access with the address space providing access. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 ________________________________________ From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of esst...@juno.com [esst...@juno.com] Sent: Sunday, July 19, 2020 9:02 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Using AN EAX value of PC Routineto index into the Authority Table Seymour and Joe . Thanks for participating in this dialogue. I'm still unclear on this procedure. . . Seymour I agree that AS2 should be a subsystem, I cant see every Address Space that needs to access data be defined as a subsystem. . Joe 'Im not sure I understand you comment - Are You saying that each accessing address space would provide a unique EAX. . What would be the advantage of using this procedure over a traditional cross memory environment. . Paul D'Angelo ---------- Original Message ---------- From: Seymour J Metz <sme...@gmu.edu> To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Using AN EAX value of PC Routineto index into the Authority Table Date: Sun, 19 Jul 2020 12:04:00 +0000 Part of designing a server address space is creating a mechanism for clients to identify it. The easy way is to be a subsystem. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 ________________________________________ From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of Joe Monk [joemon...@gmail.com] Sent: Sunday, July 19, 2020 7:46 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Using AN EAX value of PC Routineto index into the Authority Table "Sorry for the garbled message -.If the AS2 has the capability of switching to supervisor state; why can't it (AS2) create its own Cross Memory environment allowing Address Space (AS1) the ability to issue a PC to AS2 and the PC Service Routine use AR Mode to transfer data from the Target Address Space (AS2) to the Accessing Address Space (AS1) ?" How does it know what address space is the accessing address space (AS1) before it is called by that address space? Joe On Sun, Jul 19, 2020 at 6:39 AM esst...@juno.com <esst...@juno.com> wrote: > ---------- Original Message ---------- > From: Joe Monk <joemon...@gmail.com> > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: Using AN EAX value of PC Routineto index into the Authority > Table > Date: Sat, 18 Jul 2020 20:27:39 -0500 > > This is explained on page 113: > > "The example also shows the difference between cross memory data movement > with a move to primary (MVCP) and a data movement performed through ARs and > the MVC instruction. PGM1 uses the SSAR instruction to establish AS2 as the > secondary address space, then it uses MVCP to move data from AS2 to AS1. > PCRTN issues the SAC instruction to change the ASC mode to AR mode. Having > loaded the addresses and ALETs into the AR/GPR correctly, PCRTN uses MVC to > move data from AS2 to AS1." > > Joe > > On Sat, Jul 18, 2020 at 1:56 PM esst...@juno.com <esst...@juno.com> wrote: > > > Hello. I’m reading Chapter 5 Using Access Registers in MVS > > Programming Extended Addressability Guide (SA23-1394-30). Pages 113 > – > > 116 “Procedures for establishing addressability to an address > > space”Regarding Figure 38I understand the EAX value of PCRTN > indexes > > into the AT of AS2.I understand PC routine contains an ALESERV ADD > request > > for an address spaceI understand Issuing the ETDEF macro to build the PC > > routine's ETD with the EAX parameter code.It’s the Target Address > > Space (AS2) that I have issues with.First of all – I am assuming > > PCRTN resides in the Private Area of the Accessing Address Space (AS1) > and > > PCRTN is defined as a Non- Space Switching, Stacking PC , with a System > LX. > > Is My understanding correct ?.Second - if AS2 (The Target Address space) > > can switch to Supervisor State, issue ATSET and a Cross Memory Post why > > can’t it simply Establish and Setup Its Own Cross Memory > Environment, > > allowing AS1 or any other Address Space the capability of issuing a PC > > calls to it directly ? The procedure described for AS2 in Figure 38 seems > > un-necessary to me..Third – Given the technique described for > Figure > > 38 – wouldn’t it be more appropriate for AS1 to define two > > Non-Space Switching PC routines. One residing in the Private Area of AS1, > > and the other in LPA. This would allow AS2 to PC to the second PC routine > > (in LPA) to issue ATSET and a Cross Memory POST. Does this make better > > sense?.Fourth – is any one on this discussion list aware of any IBM > > product, or OEM Vendor product, or installation written software, that > uses > > the technique described with Figure 38 ?.Paul D’Angelo. > > > > ---------------------------------------------------------------------- > > For IBM-MAIN subscribe / signoff / archive access instructions, > > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
