>since most of the stuff I write is RMODE64. >Really? Perhaps you meant AMODE 64. But I'm not sure what that has to do with PC routines.
And it has a lot to do with PC routines sine the LPA is 24/31 bit storage. If you want to exploit RMODE64, you can't currently do that in the LPA. PC routines can be called from any amode, any Rmode and any environment (the new transaction environment excluded) except SACF 256 and 768. That is why PC routines are important. More than 2/3rds of the server (approximately 500K of code) executes in a common memory object. The code that does not is mostly involved in SVC screening, runs as IRBs, run as tasks in the server or are specialized services that make a lot of non-PC MVS service calls. Since most of the server including the API are designed to run in cross memory mode, there are no SVC calls. Since PC calls such as STORAGE, ESTAEX and CSVQUERY (which is all the services normally used by the server) are RMODE64 capable this presents no problem. Some of the API services branch call MVS services and even do I/O. Since all the code is ARCHLVL=2 and is self-relocating, I copy the guts (macro expansions) of these calls into a 31 bit work area enclosed in a BSM back to the RMODE64 code. My RTM exit recognizes abends in these relocated copies and report them accordingly. The 2 big issues were RTM exits and getting the PCAUTH to accept my 64 bit addresses. I got around these issues through a concept I call surrogation. I create a 31 bit stub program that contains the entry points to all the PC calls and their RTM exit (they all share the same RTM estaex or FRR exits). This code handles the redirection into the memory object. I could not find methods provided by MVS to do these things (I did not spend a whole lot of time searching). So I designed and wrote my own methods. I designed the server to run in RMODE64 from day 1 so when 1.13 was released, I was able (through a few macros and the surrogate program) to get many of the server programs above the bar in a single day. With time, I've moved most of the server including much of the UI above the bar. I even execute ISPF calls above the bar by replacing the CALL macro with a self-written macro. Again, my point is that I don't believe in designing servers to the lowest common denominator provided you are willing to write the code to fill in the gaps. Kenneth -----Original Message----- From: IBM Mainframe Discussion List [mailto:[email protected]] On Behalf Of Peter Relson Sent: Tuesday, July 09, 2013 6:42 AM To: [email protected] Subject: Re: Dynamic LPA Services >You know who owns it because its defined as a PC and therefore has an >entry table assigned to it. I suspect that every diagnostician in the world disagrees with you about using LOAD with ADDR=. It is true of course that you could navigate from the PC number to the entry table to the target address for the PC. But then you want to know what module is at that target address. Having a "name" that has been provided by the module owner (presumably one that follows the module owner's naming conventions) makes that easiest. The same is true if you blow up at address "x" and want to find out in what module "x" is. Using dynamic LPA for things in common makes that easier. And has no significant downside. >since most of the stuff I write is RMODE64. Really? Perhaps you meant AMODE 64. But I'm not sure what that has to do with PC routines. >MVS is going to treat it as authorized simply because it's in the LPA. That means that it is accepted as the target of a LINK, LOAD, (etc) from an authorized requestor. It does not mean that it will get control in an authorized state from EXEC PGM=. That requires AC=1. >To say that you can't ever free a PC routine is untrue. Almost any >space switching PC will terminate as soon as the server that defined it >terminates. I carelessly omitted, but the thread had already established, that we were talking about non-space-switch PC's. >Certainly, any PC routine that is defined as non-space switching >system PC routine that can be called without any provided interface >probably cannot be freed. The only such "interface" that I can think of is one that increments a counter (or sets a flag if that suffices) before issuing the PC and freeing of the area is not allowed if the counter is non-0. Such counters/flags are notoriously problematic due to memterm considerations. >However, a new copy can be loaded and >redefined which is why I like reusable LXs. Everyone should like reusable LX's. But you still do have to get rid of the old one first so there's a window when neither is available. >In my book, PC routines are the only way to fly. I don't think anyone is disagreeing with you. I was only pointing out that LOAD with ADDR= is not the way to go. Peter Relson z/OS Core Technology Design ---------------------------------------------------------------------- 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
