DICKEY%gmr.com@RELAY.CS.NET (02/05/90)
Has anyone ever experienced any problems when running MVS client Telnet from terminals attached to SNA control units? When I try Telnet from a 3179 attached to an SNA control unit I get repeated IKT00405I SCREEN ERASURE CAUSED BY ERROR RECOVERY ROUTINE errors. When I try Telnet from the same terminal attached to a NON-SNA control unit everything works fine. Note that I don't have any problemwith TSO, SPF, GDDM, etc... on either the SNA or NON-SNA terminal. Thanks, -Keith Dickey Software Systems Analyst GM Research Laboratories
DAVIDC@CLEMSON.BITNET (David Condrey 656-2733) (02/06/90)
> Has anyone ever experienced any problems when running MVS client Telnet from > terminals attached to SNA control units? When I try Telnet from a 3179 attache > to an SNA control unit I get repeated IKT00405I SCREEN ERASURE CAUSED BY ERROR > RECOVERY ROUTINE errors. When I try Telnet from the same terminal attached to > a NON-SNA control unit everything works fine. Note that I don't have any > problemwith TSO, SPF, GDDM, etc... on either the SNA or NON-SNA terminal. I currently have an APAR open with IBM for this problem and they are working on a fix. The APAR number is HB17741. Here are the symptoms that we have found: - Telnet in transparent mode from a Model-5 (SNA and non-SNA) terminal with different primary and alternate screen sizes is a problem. After connection, the screen size is switched, but the local host does not know anything about it. When the local host tries to write data to the screen, like "Telnet Command:" when the PA1 key is hit, it tries to write the data out of bounds, thus the SCREEN ERASURE error. The terminal is then hung. - Telnet in transparent mode from terminal models 3,4, and 5 using the Extended Data Stream (EDS) feature fail from SNA connected terminals. The SCREEN ERASURE message is issued as soon as it tries to write the first screen. We never tried EDS from non-SNA, we assumed (with agreement from the support center) that SNA and non-SNA would act the same. Sounds to me like they don't now. I should add that the support center has been great. I expect that a fix will be available soon. -David --------------------------------------------------------------------------- |David S. Condrey |Bitnet: DAVIDC@CLEMSON | |MVS Systems Programmer/Tech Rep. |Internet: DAVIDC@CLEMSON.CLEMSON.EDU | |Clemson University Computer Center |Telephone: (803) 656-2733 | | "These opinions don't belong to anyone, especially Clemson." | ---------------------------------------------------------------------------
HILLER@YKTVMZ.BITNET (Dean Hiller) (02/06/90)
>On Mon, 5 Feb 90 09:45:00 EST >DICKEY%gmr.com@RELAY.CS.NET wrote: >Has anyone ever experienced any problems when running MVS client Telnet from >terminals attached to SNA control units? When I try Telnet from a 3179 attached >to an SNA control unit I get repeated IKT00405I SCREEN ERASURE CAUSED BY ERROR >RECOVERY ROUTINE errors. When I try Telnet from the same terminal attached to >a NON-SNA control unit everything works fine. Note that I don't have any > problemwith TSO, SPF, GDDM, etc... on either the SNA or NON-SNA terminal. On Mon, 5 Feb 90 13:27:00 EST David Condrey 656-2733 <DAVIDC@CLEMSON.BITNET> responded: > >I currently have an APAR open with IBM for this problem and they are >working on a fix. The APAR number is HB17741. Here are the symptoms that >we have found: > - Telnet in transparent mode from a Model-5 (SNA and non-SNA) terminal > with different primary and alternate screen sizes is a problem. After > connection, the screen size is switched, but the local host does not > know anything about it. When the local host tries to write data to > the screen, like "Telnet Command:" when the PA1 key is hit, it tries > to write the data out of bounds, thus the SCREEN ERASURE error. The > terminal is then hung. > - Telnet in transparent mode from terminal models 3,4, and 5 using the > Extended Data Stream (EDS) feature fail from SNA connected terminals. > The SCREEN ERASURE message is issued as soon as it tries to write the > first screen. We never tried EDS from non-SNA, we assumed (with > agreement from the support center) that SNA and non-SNA would act the > same. Sounds to me like they don't now. These are two different problems. Non-SNA and SNA attached terminals do not behave the same in all circumstances. The first problem was/is caused by attempting to issue a Read Partition structure field without first unlocking the keyboard. This will work on a Non-SNA attached terminal but not on an SNA attached terminal. >On Friday, 5 Jan 1990 15:20:22 EST, I said: >The problem appeared as PROG729 errors on SNA attached terminals when >issuing the TSO Telnet command. The PTF's to correct the problem are >now ready to be distributed. They are UB02868 for HTCP100, UB02869 >for HTCP102 and UB02870 for JTCP104. > >The PTF is available by calling the support center. For overseas >customers it is available by contacting your local support who can >then contact the support center and request the PTF. The second problem only occurs when PA1 is pressed, and only occurs if the terminal has been put into the default size by an erase write command or the clear key and the terminal has more than 80 columns. The address of where to write the "Telnet command:" string is calculated based on the alternate number of columns rather than the default number of columns. When they are not the same, if the address is off the screen the error occurs. Dean Hiller IBM T.J. Watson Research Center
Y019@DDATHD21.BITNET (Eva Hocks) (02/06/90)
The information I got from my support center for that problem is IBM closed the ARPA HB16528 at 2nd of January this year but didn't ship it so far. /Eva.
DAVIDC@CLEMSON.BITNET (David Condrey 656-2733) (02/06/90)
> The information I got from my support center for that problem is > IBM closed the ARPA HB16528 at 2nd of January this year but didn't > ship it so far. > /Eva. I have it on my target system. The PTF associated is UB02870. As far as I can tell, the problem(s) is(are) still present. -David --------------------------------------------------------------------------- |David S. Condrey |Bitnet: DAVIDC@CLEMSON | |MVS Systems Programmer/Tech Rep. |Internet: DAVIDC@CLEMSON.CLEMSON.EDU | |Clemson University Computer Center |Telephone: (803) 656-2733 | | "These opinions don't belong to anyone, especially Clemson." | ---------------------------------------------------------------------------