It is really important to understand the difference between a real terminal (green-screen, so-called dumb terminal), hpterm/xterm/dtterm, and local terminal emulators such as Hyperterminal and Reflection for HP.
An HP terminal is typically a green, white or orange screen, series 700/9x or possibly an older HP2392A and is usually run in HP mode.
When you use hpterm (or xterm, etc), there is no such program on a PC. The PC is simply running code that interprets Xwindow graphics codes sent to it. The actual program is running on the server (HP-UX).
For local terminal emulators, there is no Xwindow code at all and the local program initiates a telnet session from the local emulator.
Each of the above scenarios are very different and need to handled differently. First: setting TERM=vt100 in /etc/profile or .profile will cause endless sysadmin problems. The only way to avoid problems when you hardcode the TERM value is to find every PC in your company and erase any program that performs a telnet connection, and install a terminal program which cannot be configured for any emulation except vt100. This also means that contractors, HP support, etc, must go through an inspection or training session before they are allowed to hook up to your network and connect to your HP-UX systems.
So, unless you can control the terminal or emulator used for every connection, remove TERM= statements and replace them with auto-ID using the ttytype program. To see how it works:
ttytype -s
which produces shell-compatible code to set TERM, LINES and COLUMNS based on the terminal being used. Replace any TERM-vt100 or similar code with:
eval $(ttytype -s)
This is especially important with the default /etc/profile which skips this step if TERM has been set prior to running /etc/profile. It turns out that telnetd supports telnet subcodes that pass the window size and value of TERM from the client. While the window size (called NAWS or Negotiate About Window Size) is quite useful in that it is dynamic, the TERM value is useless because the client will often set a value that is totally useless. For example, a grpahics-based Linux box sets TERM=linux and passes this to the host.
The value of TERM *must* match the actual emulator used, *and* must have a valid entry in the terminfo database. To see if the TERM value has an entry, use untic as in:
untic $TERM
If there is no entry, then the TERM value is unuseable for tools like vi, sam, swinstall, cstm, mstm, etc. So with all these complications and major sysadmin headaches, always use the eval $(ttytype -s) entry in all profiles. Note that ttytype is smart enough to provide the proper codes for csh as your login shell so add:
eval ttytype -s
to your /etc/csh.login profile.
One obscure caveat: The new machines (machines with a GSP handling the console) have a "trash ttytype" feature. The GSP has a setting in the CA command that allows you to set HPTERM or VT100. Since the GSP has no terminal sensitive codes at all (no fancy menus, 100% command line oriented), the wisdom about this setting is dubious. But the GSP codewriters asked the ttytype and tset codewriters to change their code just for the console. No matter what terminal emulator you are using, ttytype and tset totally ignore your terminal and force TERM to be equal to the GSP setting. There is no choice in this case but to hardcode the correct emulator for TERM, but only if it is a console connection.
Many new HP-UX users (including the GSP codewriters) are unfamiliar with HP smart terminals such as the 700/9x, hpterm and Reflection for HP. However, once you use an HP terminal with tools like vi, Glance, sam, and SD tools such as swinstall, you won't want to go back. The fully labeled (and functional) softkeys make navigation in sam, swinstall and glance very easy.
Bill Hassell, sysadmin
