Qedit/UX displays "read error on CRT"

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.0, 10.01 PHNE_8409 PHNE_9436

10.10 PHNE_8414 PHNE_9437

10.20 PHNE_8415 PHNE_9438

10.30 Fixed N/A

HP-UX Version	Patch number	Integrated into
10.0, 10.01	PHNE_8409	PHNE_9436
10.10	PHNE_8414	PHNE_9437
10.20	PHNE_8415	PHNE_9438
10.30	Fixed	N/A

NOTE
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?

You can reproduce this problem in two ways:

Download a test program

You can download the readerr.exe (only 40 KB) test program directly from here. This is a simple program written especially to check proper block-mode functionality.

If you prefer, you can download it using anonymous ftp from ftp.robelle.com. The file is called readerr.exe in the faq directory.

Copy the program to your HP 9000.
Make sure it can be executed (e.g. chmod +x readerr.exe).
Run the program.
The program displays the following:
Hit block-mode ENTER when all five (5) lines are displayed!
abcdefghijklmnopqrstuvwxyz01234567890abcdefghijklmnopqrstuvwxyz
abcdefghijklmnopqrstuvwxyz01234567890abcdefghijklmnopqrstuvwxyz
abcdefghijklmnopqrstuvwxyz01234567890abcdefghijklmnopqrstuvwxyz
abcdefghijklmnopqrstuvwxyz01234567890abcdefghijklmnopqrstuvwxyz
abcdefghijklmnopqrstuvwxyz01234567890abcdefghijklmnopqrstuvwxyz
It will then wait for you to hit the block-mode ENTER key. This is usually the ENTER key or the PLUS "+" key on the numeric keypad.
Hit the ENTER key.
The program will read in the lines and display what it received.
The program will do two additional passes, displaying 10 lines and 15 lines respectively. You have to hit ENTER after each iteration.
If the program displays all lines and terminates with:
Testux95 passed!
stop: testux95
then block-mode should be working fine on your system.
If the program does not display all the lines back or you get an error message like "I/O error", you probably have the problem and need to install the patch.

Test with Qedit itself

Another 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.

What kind of environment?

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.

....Back to the Qedit Q&A Page