<snip> CSVQUERY OUTLENGTH that "The length returned is the number of bytes used to contain the module. This size can be different depending on whether the module was loaded from a PDS or a PDSE." That doesn't sound like the number I need to put on a STORAGE OBTAIN. I need the length of the module *as loaded*. </snip> It is true that the "size" will differ depending on whether the module lives in a PDS or PDSE. The value from the directory entry can be used. If there was need to round up to a page multiple, for example, the value will reflect that.
<snip> > module knowable to others (including diagnostic tooling). > This would seem to be a problem. </snip> There is no practical problem. If someone uses the name randomly to execute some code that is on their problem, it is not yours. They could just as easily branch to your code directly, randomly. But, as I said, it helps diagnostic tools (be that IPCS or SLIP or whatever) should you have occasion to need them. <snip> but that it is not an error to load the same name (even if actually from a different source) more than once, and so no need to avoid name clashes? Is there a downside to loading multiple copies/versions, and then deleting them (carefully, of course) out of the creation order? </snip> It is indeed not an error to load the same name more than once. If someone does a lookup by name, they will get the most recent. Deleting in any order is fine (you would need to use the token returned on the add to identify the proper copy). It is almost never the case that you can delete any module placed into common storage (LPA or otherwise) and maintain system integrity. Can you know with certainty that there is no authorized code that was executing within that module, perhaps now undispatched (by z/OS or LPAR), that will misbehave if that storage is freed and reused? <snip> Perhaps CSVDYLPA can associate such data with the loaded image? </snip> It cannot. <snip> I understood that an LPA module that's marked REFR (and maybe just RENT) doesn't need to be paged out, and so my store might be silently lost. Probably I have this wrong, that is, if the change bit is on in a page it *will* be paged out if the frame is needed. </snip> z/OS ignores REFR aside from REFRPROT. But it is true that changes made to a PLPA (not page-fixed) module will be lost "randomly" because the system knows that it is free to steal the real storage, use it for something else, then upon need restore the module from where it paged PLPA during IPL. This does not happen for dynamic LPA. I assume it doesn't happen for MLPA. And of course it wouldn't happen for FLPA because of being page-fixed. 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
