TELNET Connect Error: [10061] Connection refused.

This is an active refusal message, meaning that you are at least touching some remote machine. There are two possibilities for seeing this message. The first is that telnet is not turned on in the host.

A second possibility for a refused connection is because a firewall has rejected your attempts to log in to the system based on your IP address. If so, this problem has to be resolved by you speaking to your networking management.

TELNET Connect Error: [10051] Network is unreachable.
TELNET Connect Error: [10065] No route to host.

The most common reasons for messages such as these are:

• A critical piece of the network is down.
• The host computer has failed and is temporarily off-line.
• You've typed in the wrong IP address or host name.

Correcting the last error is easy. The others will unfortunately require some detective work on your part. You're simply not talking to your intended target. Ping'ing the remote target should always be your first debugging step. If you can't ping the remote IP address (or host name), you won't be able to telnet to it either.

Although it may sound odd, not all host operating systems support XON/XOFF (Option 33) flow control. No version of Telnet on the HP3000 less than MPE/iX 7.0 has supported XON/XOFF flow control. However, patches are available from HP for 6.0 and 6.5 that will correct all three problems mentioned above.

The patches correct these problems:

• Persistent ghost sessions due to abnormal telnet termination.
• Frequent timeouts when long-distance (continental scale) telnetting.
• Display of passwords when in Advanced Telnet mode.
• Double-echoing of typed text when in Advanced mode.
• The absence of XON/XOFF flow control.
• Eliminates suppression of LF in CRLF pair.

Some UNIX programs employ a technique that is essentially absent on the HP3000: a keystroke that is transmitted from the terminal to the host is absorbed by the host-based program, interpreted, and then a different sequence of characters is transmitted back to the terminal.

Vi is one such program. If you find that vi isn't working well with QCTerm, it is quite likely because you have "advanced telnet" turned on. Advanced telnet presumes that the same character you transmit to the host will be the character that will be echoed back to you. In vi's case, that's often not true and thus you must use the full-duplex transmission path associated with "standard telnet," where a typed character is transmitted to the host, absorbed, interpreted, and a new sequence of characters is transmitted back to you.

Failed to load control "MSCOMM". Your version of mscomm32.ocx  
may be outdated.  Make sure you are using the version of the  
control that was provided with your application.
[372: qcalc.form_load, QCTerm]    

This problem will occur only in Windows 95, 98, NT and 2000. You won't see it in Windows 98SE (Second Edition), Me, XP or Vista. The problem occurs because of a poor design decision that Microsoft made several years ago when they changed from the 16-bit to then-new 32-bit operating system. They've corrected the problem in the newest versions of Windows, but if you are running one of these older operating systems, you may possibly see the error.

What the error means is that you have at least one outdated version of an OCX in your Windows/System folder. We've written a OCX correction program that will insure that the latest versions of all of the OCX'es that QCTerm uses will be put into your Windows/System folder. To perform this OCX update, download this small, self-extracting file:

ocxfixsetup.exe

and unzip it to the c:\ root, as it is primed to do. Once you've done this, run the newly unzipped file at:

c:\aics\ocxfixer.exe     

Nothing visible will happen when you run the program, but it will update all of the necessary system OCX'es. Wait 10 seconds for the program to do what it needs to do and then run QCTerm. If everything works as it should, purge the OCXFIXER program. You won't have any further need of it.

The OCXFIXER program will update only those OCX'es that are older than the OCX versions that we've supplied. It will never cause you to revert to an older version of any OCX.

Component 'Threed32.ocx' or one of its dependencies 
not correctly registered. A file is missing or invalid.     

OCX'es were designed to be self-registering DLL's (dynamically linked libraries), but they don't always seem to work. After you have run the OCXFIXER program mentioned above, you may also need to "register" the OCX manually. It is a very simple process, but you'll want to do it in two steps: the first step is to unregister the previous OCX and the second to register the new version.

At the "RUN" command on your "START" menu, first type:

regsvr32 /u threed32.ocx

substituting of course the proper name for your OCX. This step unregisters the OCX in question. Once done, type:

regsvr32 threed32.ocx

to properly register the new OCX now found in your Windows/System (or WinNT/System32) folder. That should be all you need to do.

Please note: if you are running NT or Windows2000, you must be logged in under an admin-privileged login for the registration process to properly take effect.

Yes. Both direct connect and modem serial connections, up to a speed of 256,000 baud.

There are two methods available to you in QCTerm. The first is that you may type the ATD string directly on the terminal's screen, in this fashion:

ATD T 1 505 555 1212

The second method is that you may register the phone number of the remote host in QCTerm's autodialing phone book. The phone book is found in the Connection/Connection Settings... pulldown menu, under the "Serial" settings.

Surprisingly perhaps, modem-based communications can be a bit more confusing than that associated with a LAN. Because of that, allow me to explain a bit about modems. A modem is a miniature computer. Moreover, it generally has exactly the same data communications characteristics as the serial ports on a host computer. Because of this, you can unplug a wire from a host's serial port and connect it directly to a modem. Even if the modem isn't connected to a phone line, you can still maintain a conversation with the computer in the modem.

When you "think" you're talking to the host computer over a phone line, you're really talking to your local modem, which nowadays is most often internal to your PC. Your modem is relaying your typed characters to a remote modem through the phone line. It is the remote modem that is plugged into one of the remote host's serial port.

To communicate with your PC's modem, you must be in REMOTE mode, being sure that BLOCK MODE, LINE MODIFY and MODIFY ALL are off. Moreover, you must have previously set the Connection Settings... screen to "Serial", selecting the proper COM port for your PC's modem, with 8 data bits, no parity, 1 stop bit.

Even if you have all of this correct, you still may not be able to talk to your local modem. Modems have a directionality associated with them. They can be set up to either be in a dial-out mode or an auto-answer, incoming (silent) mode. You can, however, cause your modem to reset to the dial-out mode by typing either

ATZ or AT&F

The ATZ and AT&F commands cause the modem to reset itself back to the factory defaults, which is the dial-out configuration. They also cause the modem to revert to a communicative mode with you. As a result, when you type either of these commands, you almost always see an

OK

on the screen. At that point, you are assured that you have communications with your modem. You may then type the dial string, ATD T ...

If you don't get an OK, you're probably on the wrong COM port. Go to Connection Settings... and try again.

It should be noted, a single COM port can only support one session at a time into your host. If you wish to have multiple QCTerm sessions running simultaneously, you must have one modem and one phone line for each of those conversations.

QCTerm isn't Reflection. The arbitrary key sequences (those that weren't defined by HP itself for the HP700/92 terminals) are different in QCTerm than they are in Reflection. These differences are explained in detail in QCTerm's on-line manual. Let me recommend that you read the manual, if you don't mind. Not only is it a piece of literature for the ages, reading it will make the use of QCTerm easier.

We're tried to bring some order to the keystrokes, making them more intuitive and easier to remember. Moreover, QCTerm's key sequences are more in line with other common PC programs.

They do. It's just that they've been given double duty. The traditional use of the control keys on a terminal is to send a control character to the host computer. Many host operating systems make use of such control key sequences as Cntl+A, Cntl+C, Cntl+Y, etc. Many host-based applications programs further extend this usage considerably, using essentially all of the control keys.

However, there is a second "standard" usage for these same keys. Unfortunately, this second usage is incompatible with the first. The other " and indeed more common usage nowadays " among PC-based programs are defintions such as Cntl+X, Cntl+C, Cntl+V, Cntl+P, etc. These now-common PC sequences are inherited from the Macintosh. Unfortunately, the Macs have a key called "Command" that doesn't exist on a PC's keyboard. Thus, the Control key has been appropriated to imitate that use.

Because one key cannot mean two different things at the same time, we've put a mode switch into QCTerm. The default usage is as the Macintosh-imitating key (i.e., local processing of the control keys). The alternate use (control keys are passed to the host, uninterpreted) can be invoked by typing either a CNTL or ALT key sequence.

If you wish to use QCTerm as a traditional terminal emulator, type one of the two sequences defined below. Once entered, QCTerm switches to Transparent Control Code mode. This "transparent" mode is indicated by having the text written in to communications control panel at the bottom of QCTerm's screen become bright blue.

To switch back to the newer PC mode, use one of the two sequences shown below. Once done, the communications control panel returns to black lettering.

CTRL+T = Switch to Transparent Control Code mode
CTRL+Shift+F12 = Switch back to Local Process mode

ALT+T T = Switch to Transparent Control Code mode
ALT+T L = Switch back to Local Process mode

Please see the on-line manual for more details.

While these three questions may not be exactly the same question, the answer is probably "no" for all three, even though the reasons differ a bit. Although that answer may initially sound depressing, the far more likely condition is that these operating systems will come to us, rather than we having to go to them.

We estimate that in commercial environments, Windows machines comprise better than 98% of all of the desktop PCs currently in use. Macintoshes make up virtually all of the remainder of these machines, with Windows CE devices being at best only 5% of the Macintosh population and Linux desktops presently being no more than 1/100th of the Windows CE population.

Windows CE is the least likely operating system to see a QCTerm port. Windows CE was designed to operate on a very small screen, much smaller than the minimum 24 row, 80 column screen that a full HP terminal emulator requires, makes accurate terminal emulation quite difficult, if not impossible. Most applications developed for an HP terminal environment would not simply run properly on such a small screen.

Linux and the Mac "ports" are more likely. Nonetheless, we believe that neither the Macintosh nor Linux are going to succeed over the long term unless they have means of running the great bulk of software written for Windows. In that regard, the Macintosh is much further along than Linux. Several Windows emulators exist for the Mac, and as processor speeds increase, the penalty for running an emulator on top of the native operating system will inherently decrease. You can buy these emulators now and amortize their cost over the several Windows-based programs that you run.

Linux too has a Windows emulator project in development called WINE (Windows emulator), but its progress is uncertain at this time.

In either case, it seems more likely that we won't have to actively take QCTerm to these operating systems; rather it seems more probable that they will come to us.

Yes. While there is no cost associated with the use of QCTerm, full and unlimited phone-in support may be purchased for US$1500 per annum. Under this support agreement, one person is designated as the contact person through which all QCTerm-related questions are funnelled. Additional people may be added to this support list for $100 per person per annum. Please contact us at either support@aics-research.com or call (575) 524-9800 for more information.

The answer is yes. You have our word on it.