Re: Kill a TSO session to Logon (Without 2nd Username)
Logon reconnect doesn't usually work if you're connected with TCP/IP and TN3270. That's just a bug that IBM can't be bothered fixing. I don't consider myself an IBM apologist, but with respect to Mr. Woren, I don't believe it's an IBM problem. This problem is simple to recreate, provided you're on a Win system and using an IP terminal emulator. Pull up a CMD prompt and enter IPCONFIG /RELEASE You immediately lose all mainframe and IP connections. Enter IPCONFIG /RENEW and you can connect again. As far as the mainframe is concerned, your session is still active and waiting for input. It wasn't notified the session died. The mainframe (and by extension, IBM) couldn't know this since IP is stateless. In this case, the problem stems from DHCP leases and the DNS. The DHCP leases expire and you have to renew them. This is when your session dies. A responsible LAN admin will time the DHCP leases to expire in the wee hours of the morning. They would do this by scheduling a global RELEASE/RENEW that affects every PC on an entire LAN. (I wish we had a LAN admin like that...) It's also something individual users can do as well since many leases are specified in 24 hour increments. Enter IPCONFIG /ALL and see when your lease expires. Schedule a RELEASE/RENEW in the wee hours of the morning. I know there are other causes, but this is a way to reduce your exposure to session drops. Regards, Kevin Kinney -- 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
Re: Kill a TSO session to Logon (Without 2nd Username)
That explanation does not cover all cases. There is also the dropped VPN problem, where DHCP lease has not changed, IP address has not changed, but VPN tunnel is dropped due to outside influences (timeouts due to volume at your ISP can cause this, I have been told). In these cases there is no reconnect possible in my experience. Unless of course there is a way to reconnect in that case that I am ignorant of, which is entirely too possible. I would love to be more educated about this, if anyone can enlighten me. Peter -Original Message- From: Kinney, Kevin [mailto:[EMAIL PROTECTED] Sent: Friday, June 10, 2005 9:49 AM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: Kill a TSO session to Logon (Without 2nd Username) Logon reconnect doesn't usually work if you're connected with TCP/IP and TN3270. That's just a bug that IBM can't be bothered fixing. I don't consider myself an IBM apologist, but with respect to Mr. Woren, I don't believe it's an IBM problem. This problem is simple to recreate, provided you're on a Win system and using an IP terminal emulator. Snipped Regards, Kevin Kinney _ This message and any attachments are intended only for the use of the addressee and may contain information that is privileged and confidential. If the reader of the message is not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail and delete the message and any attachments from your system. -- 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
Re: Kill a TSO session to Logon (Without 2nd Username)
http://bama.ua.edu/cgi-bin/wa?A2=ind0009L=ibm-mainP=R15338I=1 http://gsf-soft.com/Products/IKJEFLN2.shtml Best Regards, Sam Knutson, GEICO Performance and Availability Management mailto:[EMAIL PROTECTED] (office) 301.986.3574 Think big, act bold, start simple, grow fast... This email/fax message is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution of this email/fax is prohibited. If you are not the intended recipient, please destroy all paper and electronic copies of the original message. -- 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
Re: Kill a TSO session to Logon (Without 2nd Username)
Thanks for the archive pointer, Sam, that was very helpful. I did read about Gilbert's exit software earlier in the thread, but IANASP so I can't put it on the systems at my employer, I can only suggest it to the powers. Still, doesn't it seem strange to need an exit to get what should be normal behavior? Peter -Original Message- From: Knutson, Sam [mailto:[EMAIL PROTECTED] Sent: Friday, June 10, 2005 10:06 AM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: Kill a TSO session to Logon (Without 2nd Username) http://bama.ua.edu/cgi-bin/wa?A2=ind0009L=ibm-mainP=R15338I=1 http://gsf-soft.com/Products/IKJEFLN2.shtml _ This message and any attachments are intended only for the use of the addressee and may contain information that is privileged and confidential. If the reader of the message is not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail and delete the message and any attachments from your system. -- 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
Re: Kill a TSO session to Logon (Without 2nd Username)
In [EMAIL PROTECTED], on 06/10/2005 at 08:50 AM, Kinney, Kevin [EMAIL PROTECTED] said: The mainframe (and by extension, IBM) couldn't know this since IP is stateless. IP is stateless but TCP is not. -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- 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
Re: Kill a TSO session to Logon (Without 2nd Username)
[EMAIL PROTECTED] wrote: There is a RECONNECT parameter to the LOGON command... Maybe this would be more suitable to your need than killing the session. Logon reconnect doesn't usually work if you're connected with TCP/IP and TN3270. -- Ulrich Boche SVA GmbH, Germany IBM Premier Business Partner -- 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
Re: Kill a TSO session to Logon (Without 2nd Username)
On Thu, Jun 09, 2005 at 08:05:01PM +0200, Ulrich Boche ([EMAIL PROTECTED]) wrote: Logon reconnect doesn't usually work if you're connected with TCP/IP and TN3270. That's just a bug that IBM can't be bothered fixing. There are closed APARs on this topic telling you to use some IBM session manager product to cirvumvent the problem. (Refer to the comments in the bank thread about managers intentionally allowing or causing problems so they can sell you another product.) Most of our work is done off site, accessing the systems via DSL. There generally are not MVS techies at the office location, especially off-hours. I.e., nobody to call to ask for a session to be cancelled. Due to a flaky DSL at the previous office location that constantly caused us to lose connections, I wrote a little exec that we use by logging on to another id (everybody here has CONSOLE authority and at least 3 TSO ids) which given the userid with a broken connection, issues a V NET,INACT,F,ID=termid , waits 2 seconds, then V NET,ACT,ID=termid . LOGON RECONNECT then will work. I believe that the IBM bug is that TCPIP doesn't notify VTAM (or TCAS?) that a connection has been lost. In any case, there's a 100% probability that the bug is in IBM TCPIP -- proven by my workaround. I have a vague recollection that this used to work back in the late 1980s with MVS TCPIP for MVS V1 and V2. /Leonard -- 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
