On Monday, 10/20/2014 at 07:46 EDT, Dennis Foreman <[email protected]> wrote: > Thanks for the details Alan. It's been a long time since those old modem > days. What is the default value of the timeout in SYSTEM CONFIG? Has it > changed over the years?
The default is the venerable value of 15 minutes. It's not really a modem thing. It's actually a feature of the I/O architecture that only provides for NOT READY -> READY notifications (unsolicited DE). READY -> NOT READY is not something the hardware tells you since it may be transient and there's nothing for the OS to do about it, and it's not a problem unless the the OS wants to talk to the device during the NOT READY interval. Remember the TEST/NORMAL switch? The reason we used it was that it generated the unsolicited DE and got the OS' attention (no pun intended). Same as turning the power switch off/on. I think that over the years CP has gotten a bit confused about terminal connects and disconnects and what to do about them. CP has two goals in this arena: 1. Prevent illicit reconnection to an active terminal session. 2. Deal with virtual machines that are disconnected waiting on terminal input (VM or CP READ). The first is no longer possible. When a local non-SNA 3270 is powered on (i.e. you telnet into an OSA-ICC), along comes that DE. At this point CP should disconnect whatever user was associated with the RDEV and then (if ENABLEd) write the logo. That solves the reconnect threat quite handily, and it should be (and is, I think) done regardless of any settings in SYSTEM CONFIG. The second is a religious discussion. Back when the disconnect timeout was invented, systems were small, the number of users large, and there were no secondary users. So it meant that the virtual machine was irrevocably stalled, waiting for wetware intervention. In order to handle the relatively frequent line drops of the day, the slow human element had 15 minutes to reconnect and resuscitate the virtual machine. Otherwise it was considered a waste of valuable resources and CP forced the virtual machine to reclaim them. These days, *VMEVENT is notified when a disconnected user's fuse is lit, so IMNSHO I don't think it is any longer CP's responsibility to manage disconnected users, but that of the customer's automation software. Some virtual machines deserve immediate oblivion. Others deserve being placed in stasis. Still others require calling a team in to revive it ASAP. To that end, I would set the DISCONNECT_TIMEOUT in SYSTEM CONFIG to zero and lean on my automation software to figure out what to do about users who get into a forced disconnect state. Alan Altmark Senior Managing z/VM and Linux Consultant Lab Services System z Delivery Practice IBM Systems & Technology Group ibm.com/systems/services/labservices office: 607.429.3323 mobile; 607.321.7556 [email protected] IBM Endicott ---------------------------------------------------------------------- For LINUX-390 subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 ---------------------------------------------------------------------- For more information on Linux on System z, visit http://wiki.linuxvm.org/
