Copyright 1991-2016 by Kevin G. Barkes All rights reserved. This article may be duplicated or redistributed provided no alterations of any kind are made to this file. This edition of DCL Dialogue is sponsored by Networking Dynamics, developers and marketers of productivity software for OpenVMS systems. Contact our website www.networkingdynamics.com to download free demos of our software and see how you will save time, money and raise productivity! Be sure to mention DCL Dialogue! DCL DIALOGUE Originally published June 1991 Wired Again By Kevin G. Barkes This month we'll complete our somewhat abridged guide to terminal/modem configurations for VAXen. As I mentioned in May, a superb source of information on the subject is DEC's DSNlink service, which contains a number of comprehensive articles. Professional Press' VAX Forum on CompuServe also has a lot of great data online, as well as a crew of helpful sysops (system operators) who's heard just about every terminal configuration question there is and has answered them all. THE RIGHT STUFF Many communications problems can be blamed on the cabling used to connect the modem to the port. Some cables, particularly those sold for use on PC systems, lack all the lines necessary for reliable RS232-C modem communication. Most VAX sites use only three wires to connect a local terminal to a port. Pin 7, signal ground, is connected on both ends, and pins 2 (transmit data) and 3 (receive data) are crossed at each end in a partial null modem arrangement. This is DEC's recommended configuration for local terminals. For full modem communication, at least nine pins have to be connected "straight through"; that is, the pin number on one side of the cable has to be connected to the corresponding pin number on the other side. Those nine pins are: 1-protective ground; 2-transmit data; 3-receive data; 4-request to send; 5-clear to send; 6-data set ready; 7-signal ground; 8-data carrier detect; and 20-data terminal ready. Don't assume because your cable contains the requisite number of wires it has all the necessary connections. You'd be amazed at the shortcuts in-house cable makers take. I spent a day at a site trying to get a modem to work properly. The system manager insisted his cable wasn't at fault, since it contained not just nine, but all 25 lines required by the full RS232-C spec. I convinced him to pry the hood off one of the DB25 connectors. We discovered 22 of the wires were folded neatly together and secured with electrical tape. Only signal ground, transmit data and receive data were actually connected, and the latter two were "flopped". Learn how to test cable continuity with an ohmmeter, and check your cabling before you begin looking for more exotic problem sources. An ohmmeter enables you to do all sorts of wondrous things, like reverse-engineer the wiring on DEC's peculiar yet ubiquitous MMJ connectors. MODEM MUDDLE The default, out-of-the-box setup for most Hayes-compatible asynchronous modems is wrong for VMS communication. Modem configuration can be maddening, since every manufacturer seems to have a "superset" of the Hayes "AT" modem commands, some of which conflict with the behavior of the "real" AT commands. And then there are modem dip switches which can override AT command settings. Or not, depending upon factors as closely related as command precedence and lunar phases. Carefully read the instruction manual for your modem. Locate its configuration dip switches, if the unit has them. Make certain the switches are set in the following manner: --Carrier detect (DCD) is on only when the remote carrier is sensed, and is not forced high by the modem. The equivalent Hayes command for this setting is AT&C1. If the modem asserts DCD all the time, VMS won't be able to sense loss of carrier when the other end hangs up, and won't know to drop DTR to tell the local modem to hang up. A "stuck" DCD signal may also cause the VAX to grant the REMOTE attribute to the port and assume someone is attempting to log in. --Data Terminal Ready (DTR) is on only when the VAX asserts the signal at the terminal port. This is Hayes command AT&D2. The VAX drops DTR when it wants the modem to hang up. If the modem assumes DTR is always on, it won't look for the drop and may never hang up the phone when the other end hangs up. --Data Set Ready (DSR) is on only when the local modem connects with the remote modem. Hayes command AT&S1 enables this setting. Like a stuck high DCD signal, permanently asserted DSR may fool the VAX into thinking a login is being attempted. VMS depends on DCD, DSR and CTS (clear to send) to negotiate modem connections. When you issue a SET TERMINAL/MODEM command on a port, VMS tells the terminal controller to turn on the DTR and RTS (Ready To Send) signals at the port. This notifies the modem the port is ready for operation. When you successfully call in and connect with the modem (you did set it to auto-answer, right?) it turns on DSR, DCD, and CTS. Once VMS senses these three signals, it makes the port a remote terminal and waits for a login. You have 30 seconds to begin your login attempt. If no communications channel has been established within that time, VMS drops DTR and the modem responds by hanging up the phone. Under VMS v5, logins are disallowed unless the modem produces all three signals: DCD, DSR and CTS. If a login attempt is made on a port where these signals are unsupported, such as the serial ports on a VAXstation 3100, or a mis-wired modem is connected, an error message is displayed. The login is aborted and VMS tries to hang up the modem by dropping DTR. (See last month's column for /NOMODEM workarounds to this problem.) TO ECHO OR NOT TO ECHO To keep VMS from thinking modem response codes are login attempts, you should disable the codes via the modem switchpack or with the ATQ1 Hayes command. Unfortunately, this arrangement makes using the modem for outdialing decidedly user-hostile, since you have no way of knowing what the unit is doing. There are a number of ways around this problem, the easiest being to issue an ATQ0 (enable codes) command before you start your session and an ATQ1 (disable codes) when you finish. A better method, if your modem supports it, is to save ATQ0 as the default configuration, and have the modem reset itself automatically whenever DTR is dropped. Some modems are smart enough to know not to display "RING" and "CONNECT" response codes when the unit is answering instead of initiating a call. The Telebit T1000 9600-bps modem provided to me by Professional Press has this nifty little feature. QUICK REVIEW Here's our final checklist: CABLE: A tested and verified minimum nine-wire cable is in place. MODEM: Set the dip switches for proper DTR, DCD and DSR response, or issue the command AT&S1&D2&C1 to the modem. Use ATQ1 to disable response codes. If your modem supports stored configuration settings, use AT&Wn to retain them and AT&Yn to restore them on modem reset. (The "n" signifies the number of the profile in which to store the settings. Some modems have several; you'll most likely use 0 or 1.) If your modem will be used primarily for dialin, make certain its autoanswer feature is turned on. Use the command ATS0=n, where n is the number of rings to wait before answering. (Setting S0=0 disables autoanswer.) Issue the command: $ SET TERMINAL- /PERMANENT- /MODEM- /HANGUP- /AUTOBAUD Txyn: If your modem performs buffering, and you can "lock in" its terminal speed to a specific setting, it's best to do so to avoid autobaud mis-sensing. Replace the /AUTOBAUD qualifier with /NOAUTOBAUD and /SPEED=nnnn. For dialout lines the command is the same, except that you'd use /NOAUTOBAUD and /SPEED=nnnn prior to issuing your SET HOST/DTE command or running your communications program. Remember to issue an ATQ0 command to see modem response codes, and ATQ1 to suppress them when you're finished. Or, have your modem set to reinitialize to its dialin setting when DTR is dropped, if your unit supports the feature. Happy dialing! ************************************************* Kevin G. Barkes is an independent consultant who has 16 telephone lines connected to the eight assorted computer systems in his 10' x 12' home office. His telphone repairman thinks he's a bookie, and Bell Atlantic sends him stock instead of monthly phone bills. Kevin publishes KGB Report, lurks on comp.os.vms, and can be reached at kgbarkes@gmail.com.