That is more how I remember it except that we had a row of remote 3215s sitting across the machine room from the CPUs. Resource recovery was the bigger, in fact the only, issue for us since our access was from behind the locked doors.
Regards, Richard Schuh > -----Original Message----- > From: The IBM z/VM Operating System > [mailto:[email protected]] On Behalf Of Les Koehler > Sent: Thursday, September 24, 2009 9:05 PM > To: [email protected] > Subject: Re: Where is the VM/CMS timeout value set > > BTW: The 'old old days' I'm talking about is when we had > terminal rooms full of 2741's and they were just starting to > install 3270's. CP was so primitive back then that I wrote > IAMA3270 EXEC and IAMA2741 EXEC for users to run when they > reconnected to a different device, as there was always > someone who wanted the next available 3270. > > Les > > Mike Walter wrote: > > The reason back in the "old old days" the reason was > primarily security... > > this was written back when REAL MEN only used real 3270's > -- which had > > no LOCK function. > > > > But even now it still serves a bit of a purpose ... it > causes users to > > get a fresh 'ACCESS' to all their MDISKs. True, our MAINT > 190 S-disk > > does not change often. And the Y-disk has been moved to > SFS (with an > > exact shadow copy maintained on the MAINT 19E for servers > that come up > > before that SFS server does). > > > > And it allows our overnight cross-volume MDISK compression code to > > move un-LINKed MDISKs around to create larger free disk space pools. > > > > But most importantly... it was hard to write (the local timezone > > support). As soon as I stop using it, someone will ask for > it to be > > implemented again. So THERE! ;-)~ > > > > Mike Walter > > Hewitt Associates > > The opinions expressed herein are mine alone, not my employer's. > > > > > > > > "Les Koehler" <[email protected]> > > > > Sent by: "The IBM z/VM Operating System" <[email protected]> > > 09/24/2009 04:03 PM > > Please respond to > > "The IBM z/VM Operating System" <[email protected]> > > > > > > > > To > > [email protected] > > cc > > > > Subject > > Re: Where is the VM/CMS timeout value set > > > > > > > > > > > > > > In the 'old old days', I was once told that a long-time > idle CMS user > > only occupied one 4k page of storage, so it was pointless > to risk the > > damage to them from forcing them off. Have things changed? Or does > > your site have a very unusual workload? > > > > Les > > > > Mike Walter wrote: > >> To be a little more specific, z/VM does not provide such a > service. > >> But at least one performance monitor provides exits to do > what you wish. > >> > >> We use Velocity Software's ESAMON product to do exactly this, the > > TUNEFRC > >> EXEC provides the proper call. We've modified that a lot > to manage > >> forcing users idle for 3+ hours between the time of 9PM and 5AM in > >> their > > > >> own timezone - but that is a very site-dependent requirement. > >> > >> I'm not sure if other performance management products provide the > >> same sort of capability, but it would seem likely. Any z/VM site > >> serious > > about > >> using z/VM needs a supported performance management product. > >> > >> Mike Walter > >> Hewitt Associates > >> The opinions expressed herein are mine alone, not my employer's. > >> > >> > >> > >> > >> > >> "Martin, Terry R. (CMS/CTR) (CTR)" <[email protected]> > >> > >> Sent by: "The IBM z/VM Operating System" <[email protected]> > >> 09/24/2009 08:16 AM > >> Please respond to > >> "The IBM z/VM Operating System" <[email protected]> > >> > >> > >> > >> To > >> [email protected] > >> cc > >> > >> Subject > >> Where is the VM/CMS timeout value set > >> > >> > >> > >> > >> > >> > >> Hi > >> > >> Where do you set the timeout value for an idle VM/CMS user for > >> automatic > > > >> logoff? > >> > >> Thank You, > >> > >> Terry Martin > >> Lockheed Martin - Information Technology z/OS & z/VM Systems - > >> Performance and Tuning Cell - 443 632-4191 Work - 410 786-0386 > >> [email protected] > >> > >> WFH on Tuesdays and Fridays > >> > >> > >> > >> > >> > >> The information contained in this e-mail and any accompanying > >> documents > > may contain information that is confidential or otherwise protected > > from disclosure. If you are not the intended recipient of this > > message, or if this message has been addressed to you in > error, please > > immediately alert the sender by reply e-mail and then delete this > > message, including any attachments. Any dissemination, > distribution or > > other use of the contents of this message by anyone other than the > > intended recipient is strictly prohibited. All messages sent to and > > from this e-mail address may be monitored as permitted by > applicable > > law and regulations to ensure compliance with our internal policies > > and to protect our business. E-mails are not secure and cannot be > > guaranteed to be error free as they can be intercepted, > amended, lost > > or destroyed, or contain viruses. You are deemed to have > accepted these risks if you communicate with us by e-mail. > >> > > > > > > > > > > > > > > The information contained in this e-mail and any > accompanying documents may contain information that is > confidential or otherwise protected from disclosure. If you > are not the intended recipient of this message, or if this > message has been addressed to you in error, please > immediately alert the sender by reply e-mail and then delete > this message, including any attachments. Any dissemination, > distribution or other use of the contents of this message by > anyone other than the intended recipient is strictly > prohibited. All messages sent to and from this e-mail address > may be monitored as permitted by applicable law and > regulations to ensure compliance with our internal policies > and to protect our business. E-mails are not secure and > cannot be guaranteed to be error free as they can be > intercepted, amended, lost or destroyed, or contain viruses. > You are deemed to have accepted these risks if you > communicate with us by e-mail. > > > > >
