|
I believe your issue is with the System Value QDEVRCYACN Device recovery action. If set to *DSCMSG your telnet jobs will be disconnected for a period of time based on QDSCJOBITV, say 120 minutes for example. With predetermined device names this works well. With QPADEVxxxxx telnet devices, this is not much good other than allowing for some analysis before the job actually ends. Your telnet sessions that are ended from the client side should be generating an I/O error which in turn looks to the QDEVRCYACN to determine the next action to take. -----Original Message----- From: owner-midrange-l@midrange.com [mailto:owner-midrange-l@midrange.com]On Behalf Of John.McLellan@nlynx.com Sent: Tuesday, December 15, 1998 6:51 PM To: MIDRANGE-L@midrange.com Subject: Re: Stubborn Telnet Sessions Nlynx has a product that should support your users called Interlynx/S. Here is the page http://www.nlynx.com/solutions/remoteaccess/interlynx.asp "Larry D. Bolhuis" <lbolhui@ibm.net> on 12/15/98 04:52:33 PM Please respond to MIDRANGE-L@midrange.com To: Midrange Systems Mailing List <MIDRANGE-L@midrange.com> cc: (bcc: John McLellan/austin/Nlynx) Subject: Stubborn Telnet Sessions We have a large number of dialup users who access the AS/400 via Telnet. Being dialup they often either lose connection accidentally or on purpose in an incorrect manner, leaving the telnet sessions hanging. We have the Telnet TimeMark Timeout (CFGTCPTELN option 1) set at 90 seconds but the sessions never end. It was my understanding that the session would be ended if there was no response to this timemark. What it Seems to do if you watch the Idle Time in WRKTCPSTS *CNN is that some time shortly after reaching 90 seconds it just drops back to 0 and resumes climbing back to 90 again. We know that there cannot be a response because we have turned off the PC! We are running V3R2M0, The Inactivity timeout is set at 0 (we don't want legitimate still connected sessions to get creamed) TIA - Larry -- Larry Bolhuis | Arbor Solutions, Inc | Two rules to success in life: (616) 451-2500 | 1. Never tell people everything you know. lbolhui@ibm.net | +--- | This is the Midrange System Mailing List! | To submit a new message, send your mail to MIDRANGE-L@midrange.com. | To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com. | To unsubscribe from this list send email to MIDRANGE-L-UNSUB@midrange.com. | Questions should be directed to the list owner/operator: david@midrange.com +--- +--- | This is the Midrange System Mailing List! | To submit a new message, send your mail to MIDRANGE-L@midrange.com. | To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com. | To unsubscribe from this list send email to MIDRANGE-L-UNSUB@midrange.com. | Questions should be directed to the list owner/operator: david@midrange.com +--- +--- | This is the Midrange System Mailing List! | To submit a new message, send your mail to MIDRANGE-L@midrange.com. | To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com. | To unsubscribe from this list send email to MIDRANGE-L-UNSUB@midrange.com. | Questions should be directed to the list owner/operator: david@midrange.com +---
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.