On Sun, 15 Aug 2021 13:25:03 -0400, Peter Relson wrote: >The rules for DELETE have existed unchanged for over 40 years (maybe over >50 by now). > If I had searched diligently, would I have found those rules documented?
>... >As to "which gets deleted", it would have to match a LOAD done from the >same task now doing the DELETE (as represented in an LLE). >The first matching LLE for the task is going to win. And that, in turn, is >usually going to be the one that is newest for that task. So if that's not >the behavior you want, don't use non-reentrancy this way. > IOW, probably LIFO. fork() might add complexity. Does fork() replicate the parent's CSV control blocks in thee child's process space sufficiently that a child can DELETE (its image of) a module that was loaded by its parent. (UNIX provides nice control of descriptors. A descriptor may be given a close-on-fork attribute; I suspect there's no corresponding DELETE-on-fork attribute for load modules. And it's customary for a child to close() (its copy of) descriptors inherited from the parent. I might expect a programmer likewise to DELETE legacy load modules to reclaim storage.) >DELETE is "by name". That was undoubtedly easier way back when (the user >"knew" the name, and did not have to keep track of the address), but isn't >a robust way of doing things. some of the FileSystem-based loads are "by >address" which are more flexible in terms of identifying which copy is the >one to delete > ... >Just as was the response for the case mentioned in one of the appends >where the use count reached/exceeded the maximum: do something else. > A colleague has told a war story of an era in which the use count was kept in 8 bits. He LOADed a module 257 times then DELETEd it once. Then he did "something else". A conscientious developer would have checked for overflow and failed the LOAD. >In many cases that "something else" could have been "pre-load the first time" >and then all the other times load+delete, if there was not some reason to >save the result of the first load and just use it subsequently (that being >much faster than load+delete). > It's a pity that Rexx has no built-in LOAD function to support that optimization. I once found DATE() using several hundred milliseconds per call in a loop because it was searching my large STEPLIB concatenation for locale support. WAD. -- gil ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
