Ringing Lines -- The Sneak Thief of Power
by Stuart Baker
Ringing Lines? But I don't have any phones on my OS/32 system. What is Baker talking about now! Well, I am talking about an insidious problem that could be robbing your system of precious computer power without your even being aware of it! At this very moment your asynchronous lines could be bombarding your system with interrupts, and if you have a 3280, you don't even have a wait light to give you any hint of trouble!
The ringing lines I am referring to are the standard asynchronous communications lines provided by your 2/8 Line CommMux or your systems MPC board. Your system is most susceptible to this problem if you have long cables that are not connected to a terminal or, in some cases, are connected to a terminal that is switched off. This is not a trivial problem, one SDECM line ringing at 38,400 bps can use up 20% of a 3280's resources!
What causes this rather unexpected phenomenon? Induction. You might liken it to the Atlantis space shuttle experiment with its 12 mile tether, but instead of 12 miles of cable and the earth's magnetic field, you have 100 feet with a transmit and receive wire running next to each other. When a character is sent down the transmit line, it produces voltage fluctuations that in turn induce a signal into the receive line. When your port is not assigned to a program like SDECM or MTM, the BIOC or CTD driver respond with a bell for every character received. The intent of the bell is to alert a user that the character they just typed was not processed. But, when the received character is generated by induction, the bell code simply produces more voltage fluctuations causing induction to generate yet another receive character.
How can you determine if you are having ringing problems? That question is not easy to answer. If your unused ports are not under the control of a program, the ringing is very hard to detect. If you are a systems sleuth, the BIOC driver has an entry point named BIO.BLCT (BIOc BelL CounT) that counts the total number of times it has sounded off with a bell. This is a halfword in the BIOC driver, not in the DCB. The count reflects the total number of bells sent for all terminals. If this halfword becomes negative (>32767) BIOC stops sending the bell code. If you check this location and find it incrementing quickly, you definitely have one or more ringing terminals, the trick is to find out which one is the culprit.
A much easier approach to locating a ringing line is to add all of your ports into the latest (R05-18) version of SDECM. SDECM keeps track of the number of reads and writes issued for each line. The counts are displayed in response to a STatus command. Additionally, you may set a threshold for the I/O count. Once set, SDECM warns you when any terminal reaches the count by posting a message on the system console.
Is there anything you can do if you determine your system has ringing lines, or if you are just cautious and want to insure you never have this trouble? Yes, fortunately the solution is simple.
Ron Stordahl has solved the problem. Ron has over 300 terminals on his 3280 MPS. Many of his terminals run at 38,400 bps with lines as long as 300 feet. This combination is enough the make the designers of the RS232 standard faint dead away, but Ron is getting away with it. Since Ron has so many lines on his system, he is sure to get a terminal turned off or disconnected on a daily bases. These ringing lines were costing him a lot of computer resources. So, one day he sat down with an oscilloscope and proceeded to solve the ringing line dilemma. After much study Ron came up with the following solution. In the back shell of the 15 Pin plug connect a 510 ohm, 1/8 watt resistor between Pin 11 (Receive Data) and Pin 15 (Ground). This resistor dissipates the induced voltage to ground before it is detected by the UART, without causing interference with characters transmitted by the terminal. It has been tested with cable lengths up to 300 feet using terminals running at 38,400 bps. So, if you are having problems with ringing lines, it's nice to know that a handful of resistors and a little work may recover enough computer resources that you won't need to upgrade your CPU. Now that I have saved you all of that money, it's time to consider putting those unused ports to use communicating with other computers. If you need help, you know where to turn.
Well that about does it for this issue. I am looking forward to seeing old friends and meeting new people at Interchange 92. By the time you read this, your plans should be made and you should be getting ready to depart. I know we are going to have a good turnout. See you at the Fairmont Hotel in New Orleans. Come visit us at Booth 15.
LIMS 244 Update
An addendum to my last article on the LIMS 244 Driver. After that article was written, a problem was discovered in the 244 and BIOC drivers distributed with the LIMS system. This problem prevents these drivers from working with modems. A defective SCR was included that prevents the DTR control from working properly. Never fear, SBS came to the rescue. Perkin-Elmer now has a revised driver library that contains a corrected version of the 244 and BIOC drivers. If you plan on using either of these drivers with modems or for processor to processor communications, insure that the inclusion date on your 244 driver (INITLIDD) in your USERDLIB.LIB file is at least July 17, 1992. You can use the DIR command of OBJECT32 to view the inclusion date. Contact Perkin-Elmer if you need an update to your driver library.
This SBSW.COM page has been optimized for printing.