Peter H's version is a first-order match for how the history was related to me when I first took over ownership of the "old" (pre-WLM) sysevents approximately two and a half bazillion years ago. To add a bit:
- It's the caller's intent about the duration of non-swappability that distinguishes which of the two you call. If it's "just for a second or three" dontswap is fine; if it's for hours, or more usually (until the address space terminates, which might be months), you want transwap because of the preferred storage consequence. - Historically, the latency costs were drastically different. The differences narrowed, when states like "logically swapped" were added. Transwap then was overkill for cases that dontswap could handle. - Similarly, the consequences (how long might it take to vary a storage element offline?) vary drastically. Waiting for an I/O or 3 to complete (the intended dontswap case) might be tolerable, waiting until some PC target address space (typically a long-running server) terminates ... what could happen if it used dontswap instead of transwap and it page-fixes non-preferred frames in the element you want offline... was "frowned upon". - As others have noted, being non-swappable is NOT equivalent to page-fixing frames. Work units running in non-swappable address space(s) and referencing pageable storage CAN take page faults (unless they're in state that does not permit them to be suspended, in which case they're ABENDed). John Arwe ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
