George This response is in three parts so keep reading after the first two quoted parts.
You have two types of EZZ6034I messages here and there are "multiples" of them and so, in order to avoid too many messages giving essentially the same information, you have composite messages with "MULTIPLE" replacing the LU name. The first type of EZZ6034I message says that the TCP connection was "dropped", disconnected, "CONN DROP", because of the "timemark" mechanism, "TIMEMARK". As far as I have been able to work out from what you have told me of your definitions, the only use of the "timemark" mechanism you use id the one invoked by the TIMEMARK statement value in conjunction with the SCANINTERVAL statement value. This arranges to disconnect the server end of the TCP connection when no response can be provoked from the client end of the supposed TCP connection after 30 to 32 minutes. The second type of EZZ6034I message says that the TCP connection was "dropped", disconnected, "CONN DROP", because there was no activity on the SNA session for a specified length of time, "INACT-S". The length of time is specified by the INACTIVE parameter and the value is 1800, meaning again 30 minutes. This means that the SNA session and the TCP connection will be ended after 30 minutes and before 60 minutes if there is no activity. On Thu, 27 Jan 2011 08:23:22 -0500, George Rodriguez <[email protected]> wrote: >Hi Chris, > >There's one more thing I've noticed coming up on SYSLOG: > >EZZ6034I TELNET CONN 0003C8B7 LU TELNE1D0 CONN DROP TIMEMARK > IP..PORT: 10.28.7.202..1264 >EZZ6034I TELNET CONN 0003C844 LU MULTIPLE CONN DROP TIMEMARK > IP..PORT: 10.112.13.126..3192 >EZZ6034I TELNET CONN 0003C900 LU TELNE1E8 CONN DROP INACT-S > IP..PORT: 10.174.9.147..1866 >EZZ6034I TELNET CONN 0003C852 LU MULTIPLE CONN DROP INACT-S > IP..PORT: 70.147.33.145..15415 > >Some one must have turned on something to make these messages come up. Since >there's another systems guy here, I'll assume he made a change... I'll take >a look at the message to see what it means... >* >* >*George Rodriguez* - I don't know from where you get this consolidated information arises but I'll take it at face value as a summary of the EZZ6034I messages with "CONN DROP". I have already explained your 863 TIMEMARK events and the 65 INACT-S events. Additionally, you have 7 NSEXIT events which look as if they are caused by failures in the SNA part of the network, perhaps abnormal termination of the primary LU application. I would need the actual message with all the codes in order to try to work out where the ERR 2011 came from. The ERR 4002 and ERR 4005 are protocol errors on the TN3270E traffic and "should not occur". If it's possible to try to work out the circumstances when these problems arise, you stand a chance of taking a trace at the correct time and then passing it on to IBM support. Alternatively you may have a specialist to hand who is capable of analysing the problem. If the problems are intermittent and they appear to happen one in a hundred connections, you may just have to live with them. On Thu, 27 Jan 2011 10:20:18 -0500, George Rodriguez <[email protected]> wrote: >message EZZ6034I is proving to be very interesting. We collect the SYSLOG >daily at midnight and yesterday's SYSLOG GDG put's the problem we are having >into perspective. Starting at 6:00 am here's an extract of the action that I >see and the reason: > >Action: CONN DROP >Reason: TIMEMARK, INACT-S, ERR 4005, ERR 4002, NSEXIT and ERR 2011 > >The vast majority of errors comes from reason TIMEMARK which says: > >TIMEMARK (X'06') A TIMEMARK request was not answered by the client in > the specified time indicating a lost connection. > >The INACT-S says: > >INACT-S (X'03') The INACTIVE timer detected no session activity for > the specified time. > >NSEXIT says: > >NSEXIT (X'07') The Telnet LU NSEXIT is being driven because of session > breakage. > >ERR 2011 says: > >2011 VTAM macro REQSESS failed. > The PARM1 value is the return value, the PARM2 value is the return > code, and the PARM3 value is the RPLrtncd/RPLfdbk2; these values are > defined in z/OS Communications Server: SNA Programming. > >ERR 4002 says: > >4002 TN3270E header is in error. > The TN3270E header in the message received from the client has an > error. Using a client trace, analyze the header. If it appears the > header is correct, contact the IBM Software Support Center. > >ERR 4005 says: > >4005 TN3270E datatype is not supported. > Telnet does not accept BIND, UNBIND, or NVT data from the client. > Determine why the client is sending this data. > >Here are counts on the reason: > >TIMEMARK.....863 >INACT-S......65 >NSEXIT.......7 >ERR 4005.....6 >ERR 4002.....3 >ERR 2011.....1 > >Interesting... I'm going to dig into this TIMEMARK issue... > >Afaig thanks for all the support. . . > >*George Rodriguez* - Without being sure how exactly you set up the distinction between your "external" and "internal" users in terms of APPL name ranges, - and what the general structure of the IP network between the two sets of users and the system running the TN3270 server, I can't be sure what significance the connection terminations have or the relative counts which obviously need to be compared to the total generally active. Incidentally, I've no idea how any of this relates to your original problem. If, as we now know, you appear to have a firewall breaking your connections, I would expect your problem to be revealed as CLNTDISC since I would expect the firewall to simulate the client initiating a disconnection. Chris Mason On Thu, 27 Jan 2011 11:43:02 -0500, George Rodriguez <[email protected]> wrote: >... > >The other thins that's interesting is the LUNAME and if it has the word >MULTIPLE it means that more than one connection was dropped for the same >reason within a 15 second interval. > >The MULTIPLE count is 412, there's also 472 that have an actual LUNAME of >TELNEnnn (the E before the nnn stands for external) and 33 that have a >LUNAME of TELNInnn (I stands for internal [at my location]). > >Will continue reading... >* >* >*George Rodriguez* ---------------------------------------------------------------------- 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
