Check out Application Environments in Workload Manager. Designed to do exactly this. Not sure what you would have to do to the application, to enable the AE's.
As to the actual cost of an idle TCB, it should be near zero.... HTH, <snip> 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. </snip> ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
