In article <[email protected]> you write:
> Point taken. But it's not clear why the designers chose to allow a program > to be both modifyable and reloadable. This leads to dreadful > unpredictability: > Behavior may differ depending on whether the program has been reloaded. > OK. Initialization code may set a flag (in each page?) that will be cleared > by > a reload. Critical code paths may check (before and after) that the flag > remains > set and re-initialize if it's found cleared. And the documentation should > conscientiously mention the need to do this. Ugh! The REFR attribute has existed since MVT version 19 or so. Core storage then was really core storage... toroidal ferrite cores threaded on wires, at a cost of a dollar a bit, or more. Saving a few bytes is sneered at as false economy, now. It wasn't, then. A refreshable load module might have inititalization code that needs to be run only once per time it's loaded, with that init code overwritten for scratch storage afterward. If the module's space is needed, the whole thing gets overwritten. Later it can be refreshed, and the initialization re-run. Or, a module might contain a dynamically reorganized search table, such as a move-to-front table. That's storage modification, and it's hard to make it re-entrant on a 360/65 with only TS as a locking mechanism. But it can be refreshable, reloading the initial configuration each time. ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
