Many thanks! Very helpful and clear Am 15.08.2021 um 19:25 schrieb Peter Relson:
The rules for DELETE have existed unchanged for over 40 years (maybe over 50 by now). For a reentrant module, a use count is incremented in a CDE that is used for all instances of this job step's use of this module. Each loading task gets a LLE which itself has a use count. Storage is not freed until the module use count reaches 0. You'd generally expect the sum of the use counts in the LLE's to match the use count in the CDE. For a non-reentrant module, each LOAD gets a new CDE and each loading task gets a new LLE. The use count in each of these would be 1. 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. 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 But since it really doesn't matter when things are reentrant, and reentrant forms are preponderant, it is highly unlikely after all this time that an alternate approach would be provided rather than saying "you need to make your module reentrant or do things from different tasks" if somehow you needed the sequence of Load non-reentrant copy 1, Load non-reentrant copy 2, Delete copy 1. 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. 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). 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
