|
> If what you say is accurate, it's very un-400 like. I based what i said on the doc about tcp timemark.V4R4M0 and V4R5M0: Telnet Timemark Time-Out Parameter <quote>The TCP protocol utilizes a mechanism to probe if the client is still active. The TCP keep-alive parameter (TCPKEEPALV) specifies at which intervals the protocol begins to probe the client. When the value in this parameter has been reached, the TCP protocol will send a TCP keep-alive request to the client. If the client does not respond to the first request, the protocol will re-send the request until the client responds or until the tenth request has been sent. If the client does not respond to any of these requests, the protocol will assume the client is no longer active (for example, PC hanging or re-booting, network drop, and so on).</quote> Thia tells me the server is sending the probe to the client, which I find no diff than what SNA did with remote dumb terminals. It periodically sent probes to determine if still connected. Now, if you are saying the Client is dropping, and the server still shows an active session, like when a user presses ENTER and the Win hourglass just sits there, then 5250 screen goes blank, it is because the Client sent a request & got no response. If so, I would turn on comm trace and leave it on (set to *wrap) and next time user loses connection, end trace, dump it out, and see if the signal for that user's request "ever" made it to the 400. You will need to identify ip address of devices. When they first sign on, I think qhst log has ip address when 1st connecting (CPIAD12-Servicing user profile JANIS from client 10.0.1.20. Then follow that ip in trace till last entry. I think you will find last request never got to 400. Then jump on the network guys. btw - i am having a similar problem accessing 400 via internet w/CA. We found that it coincided with a smpt relay hack to our firewall NT. jim ----- Original Message ----- From: "John Taylor" <jtaylor@rpg2java.com> To: <midrange-l@midrange.com> Sent: Wednesday, September 05, 2001 9:22 PM Subject: RE: Client Access Session Drops > > > > > > I think it is sensitive to network unreliability or congestion. > > The 400 sends packets to the pc, and expects a proper response within a > > given > > time frame (kind of like a ping). No response? "No longer > > communicating ..." > > message. > > If what you say is accurate, it's very un-400 like. When the emulator > session drops, the host job is still active, with nothing in the joblog to > indicate that there was a problem. Nothing in QSYSOPR or QHST either. It > *seems* like it's the other way around. The emulator sends a message, > expecting a response, then immediately disconnects when it doesn't receive > an acknowledgement. > > > John Taylor > > > _______________________________________________ > This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list > To post a message email: MIDRANGE-L@midrange.com > To subscribe, unsubscribe, or change list options, > visit: http://lists.midrange.com/cgi-bin/listinfo/midrange-l > or email: MIDRANGE-L-request@midrange.com > Before posting, please take a moment to review the archives > at http://archive.midrange.com/midrange-l. >
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.