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 Administrator’s 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
>
Home of Florida's first LEED Gold Certified School
Under Florida law, e-mail addresses are public records. If you do not want your
e-mail address
released in response to a public records request, do not send electronic mail
to this entity.
Instead, contact this office by phone or in writing.
----------------------------------------------------------------------
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
