BTW (off topic) REFR, not RENT, if a module's storage may *never* be modified in any way.
On 15/08/2021 21:49, Bernd Oppolzer wrote: > 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 > . > ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
