George You need to insert the "T" between "TN3270E" and "CONN" just as indicated by Patrick Lyon.
It is only from Communications Server V1R10 that it becomes unnecessary. - If this still doesn't work - although I expect it will now work - you can also try using the LU name, for example: LUNAME=TELNE588 or the IP address and port number, for example: IPPORT=10.210.12.190..1303 - > The other thing I noticed is that the number changes very quickly. I don't understand what you mean here, you have shown two examples of use of the command for two different connections. As far as I can tell from the manuals the number shown as the "connection identifier" corresponds to some sort-of control block reference within the TN3270E program or maybe the Communications Server IP main address space and so you should not try to give it any external significance. I think you may be seeing a wide variation in the numbers because you have a busy system and there is not such a variation in the examples in the manuals because they are taken from otherwise idle test systems. - Incidentally, since it was nearby in the System Administrators Commands manual, I noticed the DISPLAY,TCPIP,TN3270E,T,PROF,DET command. This could be a quick way to show what your TN3270E PROFILE data set looks like for the purposes of following up on all the possibly relevant TN3270E program functions which might be affecting your original problem. - Which reminds me, what do you mean by the sentence(?): > We found a tech-note in Attachmate's database that seems to be helping the timeout problem. Has the problem disappeared so that the only time a client's SNA session and TCP connection are ended is following a deliberate disconnection or the timeout specified by the TN3270E PROFILE, 30 minutes (1800 seconds)? Is there an on-line reference to the "tech-note in Attachmate's database" you could provide so that I could check it out? - Something I noted in your command output is that, because the mode name shown in the "connection list" is "SNX32702", the TN3270E "device code" must be one of IBM-3278-2, IBM-3278-2-E, IBM-3279-2 or IBM-3279-2-E, probably IBM-3278-2-E. - Finally, I actually took the trouble to look up the EZZ6035I message and I see I jumped to a wrong conclusion when I explained the "missing comma" problem. >...>> EZZ6035I TELNET DEBUG PROFILE WARNING,LINE: 26 MOD: EZBTMPRP >...>> RCODE: 8043-00 Parameter not used for this statement. >...>> PARM1: PARM2: TELNETDE PARM3: SNX32702 >...> The missing comma means that the analysis "sees" a third positional parameter, PARM3, which doesn't belong on the statement. With the comma in place the two names all become one long parameter - as it needs to be. In the way the error messages are to be interpreted, PARM3 is indeed the parameter in error but it is shown as PARM3 because it is the parameter in error and not because it occupies the 3rd positional parameter position in the statement. PARM2, on the other hand, does *not* occupy the 2nd positional parameter position in the statement - as I should have noted - but is the statement in error - or at least the first 8 characters of the statement in error - thus "TELNETDE". I hope that clears that up! Chris Mason On Wed, 26 Jan 2011 15:08:12 -0500, George Rodriguez <[email protected]> wrote: >I tried the decimal conversion of the hex number shown, but it was still a >no go...The other thing I noticed is that the number changes very quickly. >When I enter the command: > >D TCPIP,TN3270E,TELNET,CONN > >It displays this: > > EN TSP >CONN TY IPADDR..PORT LUNAME APPLID PTR LOGMODE >-------- -- ---------------------- -------- -------- --- -------- >000396FB 10.210.12.190..1303 TELNE588 CICSPRDT TAE SNX32702 > >then when I do it again: > >EZZ6064I TELNET CONNECTION DISPLAY 373 > EN TSP >CONN TY IPADDR..PORT LUNAME APPLID PTR LOGMODE >-------- -- ---------------------- -------- -------- --- -------- >000399EC 10.66.14.176..2025 TELNE66A CICSPRDT TAE SNX32702 > >Here's what I get with the command: > >D TCPIP,TN3270E,CONN,CONN=235259 >EZZ6048I TELNET DISPLAY COMMAND FAILED WITH RCODE 803E >EZZ6035I TELNET DEBUG PROFILE WARNING,LINE: *N/A* MOD: EZBTMCMD > RCODE: 803E-00 Parameter on command is invalid. > PARM1: PARM2: PARM3: CONN > >Any other ideas? >* >* >*George Rodriguez* >*Specialist II - IT Solutions* >*Application Support / Quality Assurance* >*PX - 47652* >*(561) 357-7652 (office)* >*(561) 707-3496 (mobile)* >*School District of Palm Beach County* >*3348 Forest Hill Blvd.* >*Room B-332* >*West Palm Beach, FL. 33406-5869* >*Florida's Only A-Rated Urban District For Six Consecutive Years* > > > >On Wed, Jan 26, 2011 at 2:35 PM, Chris Mason <[email protected]>wrote: > >> George >> >> I scanned the IP System Administrators Commands manual in order to check >> on this matter of the CONN operand. There's no actual explanation but it's >> suspicious that, when entered as a command operand, the value is always >> decimal in the examples whereas the CONN column in output is clearly >> hexadecimal. It's not at all "user-friendly" that the number would need to >> be >> converted - particularly when very large as yours are! >> >> If this is correct your 38B37 needs to be entered as 232247. This is >> clearly >> useless operationally. There's a faint chance that you can enter the number >> in >> any C format so you could try 0x38B37. That is just a wild guess but it's >> worth >> a try. >> >> Chris Mason >> >> On Wed, 26 Jan 2011 13:56:20 -0500, George Rodriguez >> <[email protected]> wrote: >> >> >Hi Chris, >> > >> >Thanks for the comma...It worked. In one of my previous posts I explained >> >that the command you're asking me enter is not working. When I looked at >> the >> >manual, it showed this: >> > >> >D TCPIP, tnproc,Telnet,CONNection >> > >> >When I entered it, this was the output: >> > >> >D TCPIP,TN3270E,TELNET,CONN >> >EZZ6064I TELNET CONNECTION DISPLAY >> > EN TSP >> >CONN TY IPADDR..PORT LUNAME APPLID PTR LOGMODE >> >-------- -- ---------------------- -------- -------- --- -------- >> >00038B37 10.213.10.216..3431 TELNE040 CICSPRDT TAE SNX32702 >> >00038C33 10.150.6.55..1560 TELNE0AD CICSPRDT TAE SNX32702 >> >00038B39 10.213.12.143..1144 TELNE041 CICSPRDT TAE SNX32702 >> >00038C35 10.114.12.232..3289 TELNE0AE CICSPRDT TAE SNX32702 >> >00038B3B 10.234.14.200..3055 TELNE042 TPE >> >00038C37 38.101.18.2..35276 TELNE0AF CICSPRDT TAE SNX32702 >> > >> >When I used number from the column CONN and use it on your command this >> s >> >what I got: >> > >> >D TCPIP,TN3270E,CONN,CONN=38B37 >> >EZZ6048I TELNET DISPLAY COMMAND FAILED WITH RCODE 803E >> >EZZ6035I TELNET DEBUG PROFILE WARNING,LINE: *N/A* MOD: EZBTMCMD >> > RCODE: 803E-00 Parameter on command is invalid. >> > PARM1: PARM2: PARM3: CONN >> > >> >Am I doing something wrong? >> >* >> >* >> >*George Rodriguez* >> >*Specialist II - IT Solutions* >> >*Application Support / Quality Assurance* >> >*PX - 47652* >> >*(561) 357-7652 (office)* >> >*(561) 707-3496 (mobile)* >> >*School District of Palm Beach County* >> >*3348 Forest Hill Blvd.* >> >*Room B-332* >> >*West Palm Beach, FL. 33406-5869* >> >*Florida's Only A-Rated Urban District For Six Consecutive Years* >> > >> > >> > >> >On Wed, Jan 26, 2011 at 1:09 PM, Chris Mason >> <[email protected]>wrote: >> > >> >> George >> >> >> >> Two points: >> >> >> >> 1. You do not need the TELNETDEVICE statements since the names you are >> >> providing are set up by default. Please read that TELNETDEVICE tutorial >> >> post - >> >> carefully and tell me about anything you do not understand. That Table - >> >> it's >> >> 33 in my manual - is just telling you what is set up by default so only >> if >> >> you >> >> need to change the default do you need to use a TELNETDEVICE >> statement. >> >> >> >> 2. The reason you have an error is that there needs to be a comma >> between >> >> the first and second mode table entry names without any blanks. For >> example >> >> >> >> TELNETDEVICE 3278-2-E NSX32702,SNX32702 >> >> >> >> The missing comma means that the analysis "sees" a third positional >> >> parameter, PARM3, which doesn't belong on the statement. With the >> comma in >> >> place the two names all become one long parameter - as it needs to be. >> >> >> >> My advice in order to try to keep your life as simple as possible is to >> >> throw out >> >> all these TELNETDEVICE statements. >> >> >> >> Two more things: >> >> >> >> A. In case the Attachmate change does not help, we should be prepared in >> >> knowing what all of the PROFILE data set in the TN3270E procedure looks >> >> like >> >> so I would be obliged if you would post it. >> >> >> >> B. Mainly for curiosity but following up on our discussions concerning >> the >> >> RFC >> >> 2355 negotiation - and assuming there is a standard Attachmate >> >> configuration - I would like to know what "device type" you are actually >> >> using. >> >> You need to look for a line like >> >> >> >> PROTOCOL: TN3270E LOGMODE: SNX32702 DEVICETYPE: IBM-3278-2-E >> >> >> >> in a >> >> >> >> DISPLAY tcpip,tnserv,CONN,CONN=nnn >> >> >> >> command output. >> >> >> >> In any case, you should probably be familiar with the use of this >> command >> >> when looking into problems with your TN3270 connections. >> >> >> >> Chris Mason >> >> >> >> On Wed, 26 Jan 2011 12:04:58 -0500, George Rodriguez >> >> <[email protected]> wrote: >> >> >> >> >Hi Chris, >> >> > >> >> >Sorry for not getting back to you sooner. We found a tech-note in >> >> >Attachmate's database that seems to be helping the timeout problem. In >> the >> >> >next few days we are rolling it out to more than the 3 telnet terminals >> >> that >> >> >the change was applied to. >> >> > >> >> >I did make the following change to the telnet profile based on a table >> >> >(Table 26. Device type and logmode table) in the manual: >> >> > >> >> >TELNETDEVICE 3278-2-E NSX32702 SNX32702 >> >> >TELNETDEVICE 3278-3-E NSX32702 SNX32703 >> >> >TELNETDEVICE 3279-3-E NSX32702 SNX32703 >> >> >TELNETDEVICE 3278-4-E NSX32702 SNX32704 >> >> >TELNETDEVICE 3279-4-E NSX32702 SNX32704 >> >> >TELNETDEVICE 3278-5-E NSX32702 SNX32705 >> >> >TELNETDEVICE 3279-5-E NSX32702 SNX32705 >> >> > >> >> >but I'm getting these errors: >> >> > >> >> >EZZ6035I TELNET DEBUG PROFILE WARNING,LINE: 26 MOD: EZBTMPRP >> >> > RCODE: 8043-00 Parameter not used for this statement. >> >> > PARM1: PARM2: TELNETDE PARM3: SNX32702 >> >> >EZZ6035I TELNET DEBUG PROFILE WARNING,LINE: 27 MOD: EZBTMPRP >> >> > RCODE: 8043-00 Parameter not used for this statement. >> >> > PARM1: PARM2: TELNETDE PARM3: SNX32703 >> >> >EZZ6035I TELNET DEBUG PROFILE WARNING,LINE: 28 MOD: EZBTMPRP >> >> > RCODE: 8043-00 Parameter not used for this statement. >> >> > PARM1: PARM2: TELNETDE PARM3: SNX32703 >> >> >EZZ6035I TELNET DEBUG PROFILE WARNING,LINE: 29 MOD: EZBTMPRP >> >> > RCODE: 8043-00 Parameter not used for this statement. >> >> > PARM1: PARM2: TELNETDE PARM3: SNX32704 >> >> >EZZ6035I TELNET DEBUG PROFILE WARNING,LINE: 30 MOD: EZBTMPRP >> >> > RCODE: 8043-00 Parameter not used for this statement. >> >> > PARM1: PARM2: TELNETDE PARM3: SNX32704 >> >> >EZZ6035I TELNET DEBUG PROFILE WARNING,LINE: 31 MOD: EZBTMPRP >> >> > RCODE: 8043-00 Parameter not used for this statement. >> >> > PARM1: PARM2: TELNETDE PARM3: SNX32705 >> >> >EZZ6035I TELNET DEBUG PROFILE WARNING,LINE: 32 MOD: EZBTMPRP >> >> > RCODE: 8043-00 Parameter not used for this statement. >> >> > PARM1: PARM2: TELNETDE PARM3: SNX32705 >> >> > >> >> >Can you help me out of this jam? >> >> > >> >> >Thanks... ---------------------------------------------------------------------- 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
