Walt If you are using TN3270E support for the SYSREQ function (SysRq key), you just don't get a chance to enter the TYPE operand. See section 2.9.4.4, "USSPARM macroinstruction" of z/OS Communications Server IP Configuration Reference:
<quote> ... Usage Notes ... Parameters used by Telnet are: LOGON APPLID,LOGMODE,DATA LOGOFF IBMTEST # of retries </quote> I knew I was going to have to try to track this down eventually so I did the research. There is no mention in the Communications Server IP Configuration Guide or Reference (searching on "LOGOFF") concerning *which* of the 3 flavours of LOGOFF (TYPE(COND), TYPE(UNCOND) or TYPE(FORCE)) is used. There is the faintest hint in the section I quoted above that the default, as defined by VTAM in section 5.12.16.5, "TYPE" of z/OS Communications Server SNA Resource Definition Reference, TYPE(UNCOND), is used. At the bottom of section 2.9.4.4, "USSPARM macroinstruction", you can see that LOGOFF is not allowed any operands. Logically this suggests that the default values for the TYPE operand is used. If RFC 2355[1] actually allowed a proper USS LOGOFF command to be entered, the HOLD operand could also be specified which could be mapped to whether or not the TELNET connection was disconnected. I was reminded of this while searching for anything in the Guide or Reference mentioning the USS LOGOFF command. I see that there are some quite complex rules trying to control this disconnection. Chris Mason [1] My apologies. In an earlier post I referred to RFC 1647 when it should have been 2355 - to be properly up to date. ----- Original Message ----- From: "Walt Farrell" <[EMAIL PROTECTED]> Newsgroups: bit.listserv.ibm-main To: <[email protected]> Sent: Monday, 15 January, 2007 12:12 PM Subject: Re: Interrupting DSLIST > On 1/12/2007 2:50 PM, Paul Gilmartin wrote: > > In a recent note, Sandy Stone said: > > > >> Date: Fri, 12 Jan 2007 12:23:28 -0600 > >> > >> So, Gil, has your DSLIST ended yet? > >> :~) > >> > > I killed my terminal emulator. Even as in the Bad Old Days I used > > to unplug the coax. But neither of those techniques, nor operator > > cancel, ought to be necessary assuming competent design of TSO, ISPF, > > and their applications. > > > > For whatever reason, TN3270 doesn't let me reconnect nowadays. > > Formerly, pulling the coax didn't always work because I might just > > reconnect to the same hangup. Turning reconnect off is no help, > > of course. > > A LOGON RECONNECT would not help you in this case, of course, because > you'd just be back to the same spot in your session, waiting for the > DSLIST to complete. You need a true logoff. Press your SYSREQ key then > LOGOFF or possibly LOGOFF TYPE(UNCOND) or LOGOFF TYPE(FORCE). > > Also, to get RECONNECT working again, have your network system > programmers look at the TN3270 parms. There's one in there (sorry, I > don't know which one) that affects detection of disconnected terminals > that should allow faster detection of your disconnection, and thus allow > RECONNECT to work. > > Walt ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
