home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
ftp.robelle3000.ai 2014
/
2014.06.ftp.robelle3000.ai.tar
/
ftp.robelle3000.ai
/
faq
/
readerr.txt
< prev
next >
Wrap
Text File
|
1997-08-06
|
7KB
|
181 lines
Qedit/UX displays "read error on CRT"
Updated August 7, 1997
We have received a number of reports where full-screen mode in Qedit/UX
would return one or more of the following error messages:
-Read error on CRT. Try again or reduce speed
-I/O error
-Missing or invalid status line, no UPDATE
------------------------------------------------------------------------
What Are The Symptoms?
Depending on the amount of text on your screen, you might get one of the
above error messages after hitting the Enter key or a function key (with
Set Visual Update On). Typically, you would also get the "I/O error"
message at the bottom of the screen, below the template line.
------------------------------------------------------------------------
What could be the problem?
You could get these error messages if your connection settings on the
terminal or terminal emulator are not quite correct.
The following settings should work well with Reflection1. The location
of these settings will change depending on your equipment. In
Reflection1 version 5.20 for Windows95, they are under Setup/Terminal
EMULATION tab
Terminal type (ID) HP2392 or HP700/9x
ADVANCED button
Host Prompt NONE
Inhibit Handshake ON
Inhibit DC2 ON
You should also set and export these UX environment variables:
TERM=hp
RCRTMODEL=2
Since the introduction of HP-UX 10.xx and Windows95, these errors seem
to occur more frequently.
There is a known problem in the tty driver provided with HP-UX 10.0,
10.01, 10.10 and 10.20. To fix the problem, you should install one of
the following patches:
HP-UX Version Patch number Integrated into
10.00 10.01 PHNE_8409 PHNE_9436
10.10 PHNE_8414 PHNE_9437
10.20 PHNE_8415 PHNE_9438
10.30 Fixed N/A
The individual patch numbers 8409, 8414 and 8415 will not change in the
future. However, they could be integrated with other patches so the
numbers 9436, 9437 and 9438 could change.
You can download these patches from HP's Electronic Support Center using
your Web browser (you must have a support contract). If you are in
America or Asia-Pacific, go to http://us-support.external.hp.com. If you
are in Europe, go to http://europe-support.external.hp.com.
You can also download these patches using anonymous ftp (no
restriction):
$ftp us-support.external.hp.com
OR
$ftp europe-support.external.hp.com
>login: anonymous
>password:
>cd hp-ux_patches/s700_800/10.X
>get PHNE_xxxx
If you do not have access to these sites, please call your local HP
office.
NOTE: We have received a few reports of this happening with HP-UX 9.04.
These reports are still under investigation. We will update this
document with new information as it becomes available.
------------------------------------------------------------------------
What Is Causing This?
Communication between the terminal and HP-UX requires multiple layers of
software (network protocol, telnet protocol, pty/tty terminal drivers).
Qedit/UX full-screen mode uses block-mode I/O. This means the whole
screen gets transferred to the host when you press Enter. Usually, there
are hundreds of characters transferred all at once. Some of the buffers
used to exchange information between telnet and the pty drivers are
overflowing causing corruption. HP-UX then reports an I/O error to
Qedit/UX.
------------------------------------------------------------------------
How Can I Reproduce The Problem?
An easy way to identify the problem is to go in full-screen mode with
an empty scratch file. Fill up the first line with some text and remove
all blank lines that might follow, keeping only the home line, the
status line, the text line and the template.
Example:
===>
Start of file 1 /usr/tmp/qscr.CAAa02492 "" Hint: bla bla bla
* aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
// ....+....1....+....2....+....3....+....4....+....5....+....6....+...
Hit Enter. If it works, create a second text line. You can replicate
the first one or add a different one. Hit Enter again. Keep doing this
until it fails. In our tests, we have seen the failure after about 6
lines. Your test may vary.
The important thing here is that it should work with a few lines and
stop after a certain point.
We have been able to reproduce it with different environments. The most
common environment is a PC running WRQ's Reflection 1 emulator and using
Windows 95 TCP/IP stack.
Windows 95
| |
Reflection1
| |
Windows TCP/IP
| |
telnet to MachineA
| |
HP-UX 10.xx
| |
Qedit/UX
We were also able to reproduce the problem using a dumb terminal
connected to another (or the same) HP-UX machine and telnet'ing over to
the machine running HP-UX 10.xx.
Login to MachineA
| |
telnet MachineA
| |
login again
| |
HP-UX 10.xx
| |
Qedit/UX
------------------------------------------------------------------------
Is There Another Solution?
The patches are the only permanent solutions that will solve this for
all your Qedit/UX users.
However, the problem does not occur if you are using WRQ's Reflection
Network Series (RNS) TCP/IP stack. In block-mode, the Windows95 stack
transfers the whole screen in a single packet. On the other hand, RNS
breaks the block down, sending only one line per packet. These smaller
packets are handled correctly by telnet on HP-UX.
RNS must be purchased from WRQ so this is not an option for most
customers.
------------------------------------------------------------------------
Update: August 7, 1997
Patch PHNE_9437 for HP-UX 10.10 has been integrated into PHNE_10585.
Patch PHNE_9438 for HP-UX 10.20 has been integrated into PHNE_10601.
A few customers reported similar problems with version 9.04 of HP-UX.
Although the symptoms are exactly the same, we have not been able to
reproduce it on our system. We have also been unable to find an
equivalent patch for 9.xx versions. On these few instances, HP's
response centre recommended that the customer installed the latest
"mux and pty cumulative patch". At the time of this writing, the latest
one for 9.04 is PHNE_10416. We have not yet received any confirmation
whether this fixes the problem or not. We will post any findings on this
page as they become available.
------------------------------------------------------------------------