Hi John, No, all the applications are AMODE(31). The assembler routine currently temporarily changes to AR mode on each call to access the dataspace. The ALET is stored in the CSA when the dataspace is created so the assembler routine picks it up from there. if we go ahead and put the tables above the bar then the 64 bit address of the start of the tables would similarly be stored in the CSA. Yes, that's what I'm wondering: whether the fact that the assembler routine, which is in the home address space, is scanning tables in the dataspace is more costly than if those same tables were above the bar in the same home address space.
The fact that each memory address resolution when accessing the dataspace involves displacement+base+access register and the DAT uses a different segment/page table to get to the real address makes me think it should be faster using a 64 bit address in the home address, but that's just a feeling. I'd be interested in anyone else's experience on this. Regards, John. On 20 January 2014 15:03, John McKown <[email protected]> wrote: > On Mon, Jan 20, 2014 at 3:38 AM, John Blythe Reid > <[email protected]>wrote: > > > Hello, > > > > I just wanted to sound people out about converting a dataspace to a > common > > area above the bar. The main interest is the effect it would have on CPU > > usage. > > > > To put it into context, the dataspace is used for a set of tables which > are > > used by the application programs. There are around eight thousand tables > > currently occupying about a gigabyte of virtual storage. This is a large > > installation with excess of 700 million transactions per month plus a > heavy > > batch load. The application programs make extensive use of these tables. > > > > Whenever an application program needs an element of one of the tables it > > calls a standard assembler module which uses access register mode to > search > > the table in the dataspace and then returns the requested element to the > > application program. > > > > If the set of tables were placed above the bar then access register mode > > would not be needed as the tables would be directly addressable in 64 bit > > addressing mode. > > > > It all seems much simpler so, at first sight, it would be expected to use > > less CPU. A reduction in CPU would be the main justification for doing > the > > conversion. > > > > I would be very interested on anyone's opinion on this subject. > > > > Regards, > > John. > > > > > > > That's an interesting question. And it triggered some more questions in my > mind. First, is your entire application written in AMODE(64)? If not, > doesn't that means that your assembler routine would be switching AMODEs > to/from AMODE(64) and the caller's AMODE on each call? Do you cache the > ALET for your data space somewhere easy to retrieve? What about the 64 bit > address of the AMODE(64) table? It is cached somewhere? Or, in either case, > does the caller supply the address/ALET to the assember routine. I guess > the main question that occurs to me is: "How much difference is there > between doing two SAC instructions (to change the enable/disable dual > address mode) between doing a BASSM and BSM (to change AMODEs)?" I also > wonder if there is any difference in speed in fetching some data from a > Data Space versus the home address space? > > > > > -- > Wasn't there something about a PASCAL programmer knowing the value of > everything and the Wirth of nothing? > > Maranatha! <>< > John McKown > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to [email protected] with the message: INFO IBM-MAIN > -- John Blythe Reid, Técnico de Sistemas de z/OS y de Sistemas Transaccionales, Barcelona, España. ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
