CTD -- A Hands On Report
by Stuart Baker
This article describes my hands on experience with the CTD driver. I have been putting this discussion off for some time, hoping that the R08-03.1 update would resolve the problems I reported during the OS/32 BETA test. I finally found time to look at the CTD update. CTD has improved, but regrettably there are still problems. Here is my evaluation of the CTD driver.
From an MTM user's point of view, CTD looks and feels remarkable similar to BIOC. The most noticeable difference is that CTD displays control characters using the standard ^X convention. This is a very nice addition. Since CTD displays control characters when you use the BIOC alter command, you no longer have to search for hidden control characters. I also use this characteristic as a quick check to determine if I am using CTD or BIOC. All I have to do is type Esc at the MTM prompt, if I receive a ^[ in response I know I am using CTD.
In playing with CTD I have noticed several problems. When you enter data that contains tabs, you can go back into the line and add and delete characters with no problem. You can even delete a tab character and everything works fine. But, if you try to insert a tab, CTD does not perform the function correctly. All of the remaining data on the line should shift to the right by one tab stop, but it does not. The next character typed fills out the remainder of the line, but a character is missing where you inserted the tab character. CTD functions as though the tab was processed in overtype not insert mode.
The next problem shows up when you terminate a read and you are not positioned at the end of the line. When you enter a CR, and you are not positioned at the end of the line, CTD should perform a zoom (Ctrl-Z) to end of line before processing the CR. Instead, only a CR/LF sequence is output. This is very disconcerting when you are altering a line longer that your terminal width, and you hit CR. The cursor simply moves down by one line, leaving you positioned in the middle of the line you were altering. CTD should also perform a zoom to end of line before outputting the CR/LF for a cancel (Ctrl-X) line function. If you are at the beginning of a long line and decide to cancel it, CTD leaves you positioned in the middle of the previous data. This last problem also existed in BIOC prior to my Ctrl-W Ctrl-X updates mentioned in my last article.
While the above problems are irritating, they can generally be avoided. If this was the extent of CTD's problems, the situation would not be to bad. But, CTD contains some very serious problems. What are CTD's more serious problems? Number one, if I use CTD as a primary dial-in line on SDECM, my system will hang in an infinite loop at least once a day. No crash code, the wait light just goes out. The loop is in the pure code of the CTD driver. CTD appears to be having problems handling the Line Frequency Clock ISR intercept in the autobaud adjust routine. Any driver that will shut down my system is unusable! If I use BIOC as my primary dial-in line, everything works great. For testing purposes, I can use CTD on SDECM as the second terminal and avoid hanging in an infinite loop.
Of a slightly less serious nature (compared to crashing the system), CTD looses data. Data loss is not as serious as crashing the system, but still renders the driver unusable. I have not seen any data loss while using CTD interactively with MTM. In general, CTD also works properly for lightly loaded file transfers such as XMODEM or KERMIT. I only occasionally see errors while running XMODEM32. Under medium load, the data loss increases. If I use PASSPORT to display a continuous stream of data at 19,200 bps, many characters are lost. This becomes obvious when looking at the tabulated data that results from a Display Files command.
Where CTD really falls apart is under heavy loading. First let me define heavy loading. Picture a continuous stream of incoming data. Typeahead is turned on. Data is processed by issuing transparent no echo Reads. The Reads are interrupted by a Halt I/O and a Write. All Reads, including the Halted ones, are processed using the length of transfer to obtain the number of characters received. The Read, Halt, Write, Read sequence makes heavy use of the typeahead buffer. This complex procedure is required to simulate full duplex data flow over a half duplex driver. This all works fine with BIOC. When the same code is used with the CTD driver everything falls apart. Many characters are lost, and eventually the communications link is terminated with an unrecoverable error. Essentially CTD is unusable with products such as PASSPORT.
One more problem I have with CTD is the implementation of transparent mode. When a transparent Read is issued in BIOC, a flag is set that causes all received data to be placed into the typeahead buffer. No characters are acted upon by the driver. Characters like XON, XOFF, Ctrl-N and Ctrl-O are passed through as data on the next transparent Read request. CTD acts upon XON, XOFF, Ctrl-N and Ctrl-O even with the transparent mode set! In order to disable the special functions assigned to these characters, you must download new control character tables. Not only is this a lot of extra coding, but if a modem disconnect terminates a program, CTD will be left in an unusable state. It would be much nicer for all concerned if CTD would respond to transparent mode in the same manner that the BIOC driver does.
All of the problems mentioned in this article were reported on June 5, 1989 during the OS/32 R08-03 BETA test. I was informed that all reported problems would be fixed by the R08-03.1 update. Many of the problems I reported were resolved, the ones mentioned in this article were not. I sincerely hope that the R08-03.2 update will fix these remaining problems because I can't use CTD in production until they are corrected.
Well that about does it for this issue. I am looking forward to the time when CTD will truly handle all of the functions that BIOC performs. Here is hoping that all of the problems are resolved soon. On a happier note, Stuart Baker Software is looking forward to seeing everyone at Interchange 90. Come see us at Booth #2 at Compatibility 90.
This SBSW.COM page has been optimized for printing.