þa‹Rþw5þ m Y<þhý oþ nSystem-wideResponse to "SCRIPT FILES & DEVICE DRIVERS" document dated 10/7/89 --------------------------------------------------------- Will Strang and John Snow - 12/8/89 In evaluating the proposed scripting language and device driver architecture, we have looked at how they would support several unusual communications devices and configurations which illustrate federal specific applications. One device is the Secure Telephone Unit-III (STU-III), which is a combined telephone, modem, intelligent auto-dialer, and encryption device. The STU-III command language is modeled on the Hayes modem command language, but it has a number of major deviations, both in syntax and in concept, which make it fundementally incompatible. A second device is the TNC-2 packet radio controller and all of it's look-alikes, including the Hadron PRC-6064 tempest (well, designed for tempest, actually) packet radio interface. These devices have an extensive host command language and perform all network functions internally, allowing the computer to conceptually treat the radio connection much like a switched telephone connection. A third configuration uses the old, slow TTY type links that are still common in military installations. These links support speeds like 45.5, 75, 150, and 300 baud. We have developed scripts for the STU-III, in both the the GRiD and Banyan proposed script languages, to explore their usability. Some of the points made below cover GRiDMail+ and FieldLink, because configuration and dialing information is input through these modules. We assume that your device driver architecture is for DOS workstations, not Banyan servers. Thus, the only extensible modem support provided on the server will be through the script language. For this reason, we are concentrating on the script language in these comments, more than the device driver architecture. We are requesting a number of features in this document. We recognize that resources are limited and we won't get all we ask for. We expect to discuss relative priority and difficulty of features with you before implementation plans are made. Comments on the proposed Script Language ---------------------------------------- Where did the command syntax for this script language come from? If GRiD invented it internally, why not use all or some subset of an existing script language? I am not generally against the systax you have used; I am mainly concious of the training and support advantage inherent in using an existing language. On the workstation, rather than put the script interpreter inside of Fieldlink, where all users will have it taking up additional RAM, we think it may be better to implement it as an modem driver, so only the minority of users who need it will have it taking up RAM. Please define more completely and precisely what each section of a script is supposed to do, what state it should expect to find the modem in, what state it should leave the modem in, and exactly what will cause it to be executed. The general outlines are clear, but to actually develop scripts we need to know under exactly what circumstances each section is and is not executed, exactly what each section is supposed to do, and exactly what state each section should leave the serial port and modem in. For instance, is initialization executed once only at the very beginning, or before each dial or answer, or whenever a script section fails, or at some other times? Is the answer section supposed to immediately "answer the telephone" and connect to an incoming call on the modem, or is it supposed to wait to detect an incoming call, then connect? If it waits for an incoming call, how will FieldLink break out of the waiting state when it needs to? If it doesn't wait for a call, then how does the modem get set up to auto-answer? Some communications devices do not allow neat separation of the "DIAL" and "CONNECT" steps. In particular, the STU-III and TNC-2 do not allow these steps to be separated. In this case, we will have to put the entire "DIAL/CONNECT" process into either "DIAL" or "CONNECT" and make the other step do nothing. Which step should we make do nothing, and which step should we put the "DIAL/CONNECT" process into? Instead of telephone numbers, the TNC-2 uses node names and lists of node names in its "DIAL/CONNECT" process. These names can include alpha and numeric characters and be from 1 to 9 characters long. To best support this, GRiDMail+ should support alphanumeric strings (including spaces and punctuation) at least 80 characters long in the "telephone number" field. Scripts need to have memory of some sort, both within each section and between sections. This should be provided with some sort of string or numeric variables, preferably both. String variables should be settable from the RESULT used in IF commands, so the script can remember input from the modem, Value Added Network, or other smart interface it is handling, and input from the user, as discussed three paragraphs below. Numeric variables are needed to support loop cycle counting, as discussed two paragraphs below. String variables should be usable everywhere that quoted string constants are, and there should be commands or operators for concatenating string constants and variable values and assigning them to another string variable. There should be commands or operators for adding and subtracting numeric constants and variable values and assigning them to another numeric variable. The RWIND command as presently designed has a serious problem, which is that there is no way to do loop cycle counting. If the section is rewound to the beginning, there is no way to initialize and increment a cycle counter. RWIND would be used mainly to implement loops, and most loops need to stop after some number of cycles have occured. Look at how loops work in most computer languages -- FOR loops in C, DO loops in FORTRAN, FOR NEXT loops in BASIC. For example, loop counting is needed to break out of retry loops after some maximum number of retries have occured. RWIND is actually not a usable mechanism if one needs to implement more than 1 retry loop in a section. Backward JUMP would be a much nicer mechanism for supporting loops. An explicit looping construct would be nicer yet, but that seems like overkill, so we just ask for backward JUMPs. We would like the capability to take user input in the script, such as to prompt for a security level for the STU-III, or a node name from a available node list uploaded from a TNC-2. The input should be put into a script specified string or numeric variable, with input to numeric variables restricted to numbers. We would like to be able to use subscripts in accessing the RESULT buffer, so we could test, for example, the first five characters, or the third and fourth characters, or whatever. Subscripting would be most useful in testing portions of the RESULT buffer, or copying a portion of the RESULT buffer to a string variable. We would also like to be able to use subscripts in accessing and setting string variables, though this is not as important. What is the mechanism for getting FieldNet configuration information into the script, such as the Phone Number? The Banyan scripting language proposal used string variables which the script would find pre-defined when it started running, which seems like a good approach. Besides Phone Number, there are Speed, Com Port, Modem, and Phone Type. We need to be able to set the DTR and RTS control signals high and low, separately. Please define whether DTR and RTS will be high or low when a script's initialization is first executed. Preferably, they should be low. We need to be able to change the baud rate of the serial link in the middle of a script, to handle modems with multiple DTE interface baud rates. We need to be able to send a break and we would like to be able to WAIT FOR an incoming break. Section keywords should not have a ";" in front of them. They are not comments, and this is an inconsistant use of ";" as a comment character. They should just start with "#". SKIP duplicates what JUMP and LABEL already do. SKIP is also easy to mess up by adding or removing lines, so it should be left out of the script language. We need to be able to WAIT FOR both text strings and control signal events in the same WAIT FOR statement. We need to be able to WAIT FOR the RI (Ring Indicate) control signal, in addition to DCD, CTS, and DSR. We need to be able to WAIT FOR both high and low control signal states. The present design appears to support only WAITing FOR the high control signal state. We would like to be able to combine multiple control signal states in one string in a WAIT FOR. For instance, we would like to be able to wait until BOTH CTS and DCD are high. This is a convenience, not a requirement. A WAIT FOR a control signal state should return immediately if the control signal is already in the desired state, as opposed to waiting until it changes to the desired state. We assume that you intended it to work the right way, but just to be sure, we put it in this list. We need a simple way to way to find out which item in a WAIT FOR list was received, or whether the WAIT FOR timed out. A good way would be a numeric variable that was automatically set to the sequence number of the received item within the WAIT FOR list, and was set to zero if the WAIT FOR timed out. When a WAIT FOR times out without receiving one of the strings or events listed, we need a way to test whether it received any characters at all. We would like to be able to test whether it received any control signal events at all, though this is not required. We need to be able to WAIT FOR and WAIT DELAY in tenth of a second increments, such as .1, 1.3, etc. We need to know at exactly what points in which commands the RESULT buffer is cleared. We need to be able to clear the RESULT buffer under script control, and to be able to control whether the RESULT buffer is cleared when a WAIT FOR is executed. Actually, the RESULT buffer should probably be cleared only when the script says to, for the most precise and predictable control. Since ABORT is also used to exit a script section with a successful result, EXIT would be a less confusing name for the command. The word ABORT implies a failure. Some sort of statement grouping for IF statements, like BEGIN...END or {...}, would make complex scripts more readable. Where does the limit of 64 on string length in the REPLY command arise from? While this is not a difficult length limit, there seems little reason why strings of arbitrary length could not be handled. We need to be able to display multiple messages on the screen at once, and to control when messages are cleared from the screen. Ideally, the MESSAGE command should stack messages from the bottom of a window upward, and all messages would be cleared by a MESSAGE command with no string. We need to be able to specify arbitrary baud rates with a half baud increment and 1X external clocking in the GRiDMail+ and Fadmin baud rate selection fields, as is supported in version 3.1.5 and later of GRiDManager. This ties in with the discussion of baud rate setting below under serial driver. We need selectable outgoing hardware flow control support between the serial port and modem. If incoming flow control makes sense, we suggest implementing it. Use CTS for outgoing flow control. Use RTS for incoming flow control. This flow control should also operate during data transfer, after the script has completed. Flow control is needed for best operation with error correcting modems. We would like to be able to define conditions for detecting "lost connection" during a call, when the script is no longer in control. Specifically, the script should to be able to tell FieldLink what control signal events signal loss of the connection. This would make lost connection detection much faster than waiting until FieldLink retries out on a packet. Comments on the proposed Modem Driver Interface ----------------------------------------------- In addition to the 5 services (routines) defined for modem drivers (open, close, write, read, status), a modem driver needs to provide FieldNet with all the same services that a modem script does: initialize, dial, connect, answer, and hang up. How does FieldNet ask the modem driver to perform these services? An installed modem driver needs to know what Speed, Com Port, Modem, Phone Number, and Phone Type (touch tone vs pulse) were selected in GRiDMail+. How does FieldLink provide this information to the modem driver? We need to support a wider range of baud rates, and in fact to support arbitrary baud rates, with a half baud increment to allow 45.5, 134.5, etc. We also need to be able to specify 1X external clocking. See discussion below under serial driver. The modem driver needs an error code to return when it decides that the modem or link has lost its connnection. The m_status routine should have an "int *error" parameter added, so it can return this "lost connection" error code. Comments on the proposed Serial Driver Interface ------------------------------------------------ Standard FieldLink should support COM3 and COM4 serial ports, exactly as it supports COM1 and COM2 serial ports now. COM3 and COM4 should have port_num values of 3 and 4, respectively, in s_open. We would like to be able to support more than one serial port per serial device driver, and to allow the user to choose among the available ports. For instance, we would like to have one device driver support both the A and B ports on the 1537's 85C30 serial port. To do this, we need some way for the user to select among the port options a device driver provides. The selection made can be passed into the device driver via the port_num parameter, but we would like a way to set the text in the GRiDMail+ port selection menu from the device driver. For instance, there could be a call in the device driver which returns a pointer to a null terminated text string of port choices, separated by "|". In the built in device driver, this call would return a pointer to a string containing "COM1|COM2|COM3|COM4". The port_num parameter would then be set to the position of the value chosen within the string. The diagram at the front of the design document lists five interrupts, 60H through 64H. Only two uses for interrupts are mentioned, those being the modem and serial drivers, and the interrupts are used only to request a list of entry points from a driver. What are the other 3 interrupts to be used for? Software interrupts are a limited resource on PCs, especially for our power users who load up on TSRs and device drivers. Five interrupts seems like a lot to use for FieldLink, especially five in a row. Could you reduce this number and/or allow each of the interrupt numbers to be set independently of the others, so they don't have to be all in a row? It seems to me that the entry point request functions for the modem and serial drivers could be folded into one interrupt. We need to support a wider range of baud rates, and in fact support arbitrary baud rates, with a half baud increment to allow 45.5, 134.5, etc. We also need to be able to specify 1X external clocking. The divisor specification approach used in the InteGRiD serial drivers supports half baud increments, but is a bit obscure and clumsy. A better approach would be for an unsigned word 2 times the baud rate to be passed in, to avoid passing fractions. This would allow specifying up to 32767 baud. Among the common baud rates, this includes 19200 but excludes 38400, which is acceptable to us. A value of zero could specify 1X external clocking, also called "isochronous". The "setopt" and "getopt" routines use an "options" parameter which is not large enough to support this mechanism. Either the parameter structure in these routines should be enlarged, which is preferable, or separate routines for setting and getting the speed should be added. We suggest that you look at the OsSetStatus call in InteGRiD for an example of a more general device driver options setting interface. The FieldNet mechanism need not be fully as general as OsSetStatus, but we favor a variable length "options" parameter, passed by pointer.