Scott - Your response is excellent and well taken -Since IBM supply's an SSI DELETE Command i would think IBM could provide an IEFSSI REQUEST=DELETE macro to do the same function ---------- Original Message ---------- From: Scott Ballentine <[email protected]> To: [email protected] Subject: Re: Resource manager for subsystem Date: Mon, 12 Aug 2024 10:01:33 -0500
Hi all, I'll share a number of thoughts on this thread, in no particular order.... > I have found this thread interesting, and what I believe is needed > is a SSI ROLLBACK or UNDO function. So that in the ESTAE/ESTAEX routine > or in the init routine itself the "system" would remove any changes made > SSCVT, SSVT, Remove the SSID etc. The SETSSI DELETE command does as much as it is possible/appropriate/knowable for z/OS to do, which means that it can only manage the SSI control blocks like the SSCVT, SSVT, etc. z/OS does not know about any resources that the subsystem obtains on its own. However, the subsystem can register an EVENTRTN that will be called when the SETSSI DELETE command is issued. See here: https://www.ibm.com/docs/en/zos/3.1.0?topic=subsystem-considerations-deleting and here: https://www.ibm.com/docs/en/zos/2.4.0?topic=ixg-iefssi-dynamically-control-subsystem#opt Typically, you would do this out of the initialization routine. I think your subsystem has to be a dynamic subsystem to register an EVENTRTN but I could be mistaken on that. > Change the subsystem name in the SSCT (perhaps change one character to lower > case) and free everything. Of course, be careful that nothing is running in > the code dynamically loaded. At best, this would make the name available but not clean up anything else related to the subsystem (which I think was what the OP was looking for.) That said... a dynamic subsystem z/OS does have some other structures that are not programming interfaces that could know about the subsystem name so this might not work in all cases. > Removing an SSCT is not for the faint of heart. Among other problems, there are serialization considerations and you could potentially break other subsystems if you try to remove a SSCVT (SSCT). Trying to remove an SSCVT from the chain is not a good idea. > I guess I could always do an ATTACH on the subsystem initialization routine > and > And have a RESMGR for that TCB Do not assume that the task that is driving the subsystem initialization routine is going to stay around after the initialization routine returns to the system. This has lots of implications for the INITRTN when obtaining storage, attaching subtasks, etc. - not that there aren't ways to deal with those issues, but you do need to give some thought to it. Scott Ballentine ([email protected]) z/OS MVS Development ---------------------------------------------------------------------- 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
