My CMS PROFILE EXEC does CP SET RUN ON, so it is always on. Then I boot Linux. I let Linux finish the boot and it then displays the usual Linux login prompt. The monitor says RUNNING, not CP READ. I them close the window. SSH to the Linux VM now fails. I log back in on 3270, hit enter and the Linux prompt re-appears (so Linux did not get killed). Again, no CP READ. Now I do #CP DISC. SSH works now.
So Alan's comments about the system timer don't seem to apply. The timer MUST be greater than 0, because I can wait a while (haven't tried to see just how long) and Linux is still alive, but the SSH fails unless I #CP DISC. So why can't CP see the SSH if no READ is posted to the terminal to make CP think it has to check the timer? Regards, DJ THANK YOU for deleting my address (unless it is pertinent), all other addresses, and personal information from this e-mail, if you plan to forward it. THANK YOU also for using "BCC " instead of "TO" and "CC " when initiating e-mails to multiple users. This may help prevent spammers and hackers from obtaining addresses and thus may prevent spam and/or identity theft. -----Original Message----- From: Linux on 390 Port [mailto:[email protected]] On Behalf Of Scott Rohling Sent: Wednesday, October 22, 2014 11:46 PM To: [email protected] Subject: Re: can't SSH after 3270 disconnect Your saying SET RUN ON makes me wonder if you are typing that in or something before you close the 3270 window.. ? You say you immediately reconnect to 3270 and Linux is still there... Do you mean you get a z/VM logo and login and Linux is still there? If you open your 3270 window and Linux is sitting there - not a z/VM logo - then I'd be mystified.. the 3270 session didn't really end then. It is almost sounding to me like you put the machine in CP Read somehow when you 'close the 3270 window' -- but when you do a proper #CP DISC - everything is fine. Don't know --- but #CP DISC is always the proper way to leave a guest running ... just closing the window is never a good idea. Still don't understand your particular symptoms as just closing the 3270 window shouldn't halt the machine or cause anything to happen immediately - it will take some time before the guest is forced off by the system. Seems to the point where we need to see screenshots, etc to make sure we see exactly what's being entered and done... Scott Rohling On Wed, Oct 22, 2014 at 4:38 PM, Dennis Foreman <[email protected]> wrote: > If I connect & boot Linux, and do NOT login to it, but just close the 3270 > window (SET RUN ON), and immediately try to SSH, it fails, BUT I can then > immediately re-connect to 3270 and Linux is still there (so the machine has > not been forced off) and I can #cp disc and SSH will work. > > > Subject: Re: can't SSH after 3270 disconnect > > 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/ > > ---------------------------------------------------------------------- > 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/ > ---------------------------------------------------------------------- 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/ ---------------------------------------------------------------------- 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/
