> 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 thread ...

Follow-Ups:
Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

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.