> You know who owns it because its defined as a PC and therefore has an entry > table assigned to it. Looking in the entry tables for a program is just as > common a practice as looking for "identified" programs. So finding PC > routines just requires different methods. Besides, if this is a stacking PC > which is the only type I use, the linkage stack has everything needed to > associate the call with the PC routine including the PC number.
The point is that SLIP LPAMOD= and the IPCS WHERE subcommand will not be able to identify your module by name. So when someone needs to refer to your module on a SLIP command, they will need to manually determine the address of your module in order to use use ADDRESS= (and the address could change every time your product starts, and is likely to be different of each member of a sysplex). As a z/OS diagnosis expert, I view that as a serviceability issue. > 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. So these can be released and refreshed as needed every time the > server recycles. Certainly, there are many PC routines that can't be freed. > But if a PC routine is designed to be called as part of an API or UI, then > API/UI recovery can easily recover the error and report it as the server > terminating. 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. However, a new copy can be loaded and > redefined which is why I like reusable LXs. Consider the case where the storage formerly occupied by the freed PC routine has been reassigned by VSM, and now contains data that happens to look like a valid instruction stream. So now your "PC routine" is executing unintended code, with the authority of the user and your PC routine. What will cause your API/UI recovery to get control, and if it does get control, how will it "easily recover the error"? How will it detect and repair any damage which occurred due to the execution of the unintended instructions? Jim Mulder z/OS System Test IBM Corp. Poughkeepsie, NY ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
