>>A key reason for the last is so that someone can use LSQA for an SRB that >>is not associated with a TCB, for which you might not want private storage >>obtained by the SRB to be freed just because some task terminates.
>Seems like a weak reason. Are there other ways SRBs are protected from poor >subpool choices? It is far from a weak reason. It is an extremely strong reason. If this is a "poor subpool choice" then what would be a good subpool choice? Any task-related subpool will have its storage freed when that task terminates. An SRB *can* (but need not) be tied to a particular task. When it is, it can rely on a task-owned subpool associated with that task (or a parent of that task). When it is not, it ought not to rely on such. The SRB, in that case, needs to use a subpool that has no task association. That is either LSQA or common. If anything, I'd say that common would be a "poor subpool choice" if addressability from multiple address spaces is not needed. 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
