Usual response is "it depends". In general, a TCB in a WAIT is using up private storage for control blocks, user dynamic storage, and programs. If the programs are marked RENT, then contents supervision will only load a single copy regardless of how many times the program is used. The CPU overhead while in a WAIT is likely in the "noise" level. Personally, I probably wouldn't worry about it. There is more cost to do the DETACH and ATTACH to stop and start the TCB than leaving them in a WAIT. Also, responsiveness would be slightly better.
On Thu, Apr 18, 2013 at 12:02 PM, Phil Smith <[email protected]> wrote: > We have a z/OS server task that takes requests from clients and does, > like, things with them. The server manages a pool of TCBs. We have various > controls on those TCBs, so a single rogue client can't just cause a zillion > of 'em. But there are times that a client program gets a spike and hammers > our server, which dutifully creates a bunch of TCBs. > > The question arises when that spike abates: these TCBs currently remain > idle more or less forever. We could add a mechanism to reap idle TCBs after > some period, but the utility of this is unclear. Obviously if the spike > does reoccur, they'll be useful. > > So the question is: What's the real cost of having a TCB sitting there > idle? My performance experience is with z/VM and Linux on z. Certainly on > z/VM, an idle userid gets paged out and is essentially "free" (modulo a > tiny bit of memory used for the VMDBK and page tables and like that). To > what extent is an idle TCB on z/OS impacting things? Are there system- > and/or primary TCB-based limits on numbers of TCBs that we're pushing > against? Each TCB uses maybe 25K of memory in our address space, and > presumably some small amount of system memory. > > Thanks in advance to the collected wisdom of the group, > > ...phsiii > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to [email protected] with the message: INFO IBM-MAIN > -- This is a test of the Emergency Broadcast System. If this had been an actual emergency, do you really think we'd stick around to tell you? Maranatha! <>< John McKown ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
