|
|
|
I apparently gave a presentation on the TPOCC Systems Test and Operations Language (TSTOL) to some Computer Sciences Corporation (CSC) software developers and, in return, I received a critique of TSTOL by Anna and Sheila. I don't remember the tone of their memo being exactly one of "constructive criticism" (!), but they were more knowledgeable about and experienced in control center operations than me and therefore brought up some important points that I had not yet addressed in TSTOL.
I believe I only knew Sheila by sight and I don't recall any further involvement of her in any of the TPOCC-based projects. Anna did work on several TPOCC-based projects and I was fortunate to get to work with her full-time for two years on developing X-SAR, a control center for a shuttle-borne radar instrument. (The project was based on TPOCC, ported to VAX/VMS.) First of all, Anna was a lot of fun to work with and I think her presence helped maintain a good mood among the whole project group, who were all working under very tight schedules.
Secondly, and more importantly, Anna, now retired, was one of those extremely rare people I've met who had a natural, hard-to-define ability to shepherd a team of developers together and bring a project to a successful conclusion. She wasn't a manager and had no managerial powers, but she nevertheless exerted a big influence on the progress of a project, not in a heavy-handed way and almost silently and invisibly. For example, on occasion, our project managers would frantically hand down a new, unexpected, imminent deadline from our customer for some deliverable. Anna intuitively knew what needed to be done, in what order, and by whom—and we would meet the sudden deadline, with extra effort, of course, but smoothly. CSC knew how valuable Anna was, as I had had previously heard stories of her being brought into save troubled projects. As I said, I count myself fortunate to have been able to work with her.
Bill Stratton gave me a copy of the memo from Anna Critchfield and Sheila Alpers regarding the TSTOL Question and Answer session I conducted for the SMEX and WIND/POLAR folks. Being responsible for the only Q&A session to generate a memo so far is undoubtedly a mark of distinction, in some respect or another!
The memo from Anna and Sheila summarized a number of concerns the SMEX and WIND/POLAR developers have with the TPOCC STOL implementation. While some of the configuration issues are not really in my bailiwick, I will attempt to answer the various points Anna and Sheila made in their memo.
"TSTOL needs to provide dialog mode capabilities, including parsing and setting defaults ... This is a very serious concern, because we must have SYSINT dialog capabilities."
A perusal of the GRO and UARS POCC System Users Guides revealed the following dialog-mode directives: FORMAT, GCMR, M, NCCMSG, PER, PRINT, REQMAST, and SYSINT. (The ICE "/"-command dialog seems to have been dropped in later POCC's.)
The FORMAT directive is used to build wildcard displays; the TPOCC operator can just as easily bring up a separate window and edit a UIL display definition file. The M directive is used to test various capabilities of the MSTOL parser; similar functionality can be achieved in other ways in TSTOL (I think I'll use the T directive).
The PRINT directive's dialog mode is not described in either of the Users Guides. The REQMAST directive requests master controller capabilities for the operator; the TPOCC system uses a different scheme for assigning operator privileges that obviates the need for a master controller.
The GCMR, NCCMSG, and PER directives are used to construct and send various types of communication and control messages. Dialog mode for these commands is sufficiently similar to the SYSINT dialog for them to be handled in the same fashion as SYSINT (described in the following paragraphs).
The discussion of dialog mode at the TSTOL meeting primarily revolved around the SYSINT dialog. The GRO and UARS Users Guides have this to say about SYSINT:
"Each prompt in the SYSINT dialogue corresponds to a one-liner directive. The prompt response syntax is the same as the corresponding one-liner syntax minus the directive keyword ... The dialogue is provided to ensure that all necessary parameters get set."
Contrary to popular belief, TSTOL does have a mechanism for handling this type of dialog - it's called a TSTOL procedure. A simple SYSINT dialog might be programmed as follows in TSTOL:
proc sysint
local arguments
do
ask 'PASS INIT/TERM? ' arguments
parse 'PASS ', arguments
break if (%status .eq. SUCCESS)
enddo
do
ask 'STATION? ' arguments
parse 'STATION ', arguments
break if (%status .eq. SUCCESS)
enddo
...
endproc
Within each DO loop, the ASK directive prompts the operator for input and reads the operator's response. The PARSE directive constructs a one-liner directive by appending the operator input to the appropriate keyword; the one-liner is then submitted to the parser for parsing and execution. If the one-liner is processed successfully, the BREAK directive exits the loop and execution continues on to the next prompt.
Voila! Instant dialog mode, with parsing and setting of defaults performed by the TSTOL parser - capabilities not provided by MSTOL. The procedure above can be easily expanded to handle the SKIP, ABORT, and END dialog controls (GOTO N will be somewhat harder). If desired, one-liners could be saved up and issued when the END directive is entered. In addition, TSTOL's string handling capabilities allow the construction of variable prompts at run-time.
A useful question to ask at this point is: why is the SYSINT dialog so important? SYSINT has always been a major area of concern, not only in Anna's and Sheila's memo, but also in each of the TPOCC reviews. If system initialization is so important (and it is), don't the operators deserve something better than a two-line window (prompt line and input line) into a dialog?
Bill Stratton has previously discussed the use of a forms entry system for TPOCC "dialogs", but I'm surprised that such a concept hasn't already found widespread use in the existing POCC's. A screen-oriented forms interface to a program (e.g., SYSINT) is relatively simple to implement and maintain using normal FORTRAN I/O capabilities (I've done many of these in the past); the availability of a forms management system makes the job even easier.
Would a forms entry interface to SYSINT be harder to program than the existing MSTOL dialog? Perhaps so, but the extra days or week a programmer takes to handcraft an attractive, functional operator interface pales in comparison to the years the operators will spend using that system (25 years in the case of ICE).
"To define a new directive in MSTOL, it is enough to update a directive definition table. TSTOL ... is a step back compared to MSTOL."
Somebody pass the Solarcaine, please! Adding a new directive to MSTOL is not quite that simple, but the point is well taken. Subsequent to the Question and Answer session, I added to TSTOL the capability of defining foreign commands using "internal" procedures. With this approach, similar to that used in extensible text editors (TPU under VMS, Emacs under Unix, and about 50 zillion editors under MS-DOS), a directive is defined in terms of other TSTOL directives. Foreign directive definitions are structured as follows:
directive name (arguments) is
... attributes ...
begin
... body ...
end
Name specifies the directive keyword and can incorporate abbreviated short forms. Procedure arguments can be specified using the argument count (MSTOL-style) or by listing the named arguments (TSTOL-style). Attributes currently include aliases (short forms), if the directive is built-in (generic TSTOL?), and allowed operations classes. Body specifies the procedural implementation of the directive and is not needed for built-in directives. Any TSTOL directive is allowed in the body of the procedure, including DO-loops, procedure calls, and foreign commands. For example, the PAGE directive might be defined as follows:
directive 'P#AGE' (pagename, update_rate, device) is
class ALL
begin
tell DISPLAY '[XQ] PAGE ', pagename, ;;
' INTERVAL=', %default (update_rate, 5), ;;
' DEVICE=', %default (device, 'crt')
end
The "#" in the keyword indicates a fixed-length abbreviation ("P" is a short form for PAGE); "*" can be used for variable-length abbreviations. The %default() function substitutes default values for unspecified arguments.
The TSTOL parser reads the directive definitions (from the startup procedure file, for instance) and stores the internal procedures in memory for fast access. When the operator enters a "foreign" keyword, the parser collects up the remaining arguments on the command line and passes them to the internal procedure defined for the keyword. A variety of lexical functions will be available for type-checking arguments and various other functions.
Using internal procedures to define new directives appears to offer all the functionality of the MSTOL directive definition capability. A mechanical method, similar to that found in the MAE Programmer's Guide, of converting a directive syntax diagram to a TSTOL directive definition can be designed. TSTOL offers the following advantages in defining new directives:
Performance-wise, it obviously takes longer to run an internal procedure than it does to execute a built-in directive. A test of the PAGE directive on an unloaded system, with the TELL output directed to the terminal, required 15 seconds to execute 500 built-in PAGE commands and 30 seconds to execute the same number of foreign PAGE commands. The operator probably won't notice the difference in speed.
Is the TSTOL parser now truly generic, configurable for different missions without any changes to the base program? In some cases, yes, but the differences at the lexical level between STOL's for different missions remains a stumbling block. These incompatibilities are particularly evident in the case of spacecraft commanding, e.g., the myriad formats of serial magnitude commands. Run-time configuration of the lexical analyzer was not possible in MSTOL and is not (yet) possible in TSTOL.
"The directive default setting for a one-liner or a dialog is not handled by TSTOL ... again a major drawback compared to MSTOL."
By defining a directive via an internal procedure, defaults can be assigned in a variety of ways. For example, the PAGE definition shown earlier illustrates the use of the %DEFAULT function. %DEFAULT returns its first argument if it exists and its second argument otherwise. Since the default value (the second argument) can be an arbitrary expression, TSTOL defaults are not limited (as in MSTOL) to hard-coded literals, but can even be retrieved from the database or picked up out of system variables.
"It was not clear ... exactly how operations classes ... are defined for each directive and whether TSTOL provides a mechanism for checking the operations class of the directive with that of the window where it originated."
TSTOL will support operations class definitions (via the CLASS attribute in directive definitions) and will verify the privileges of the operator before executing any directive. The protocol for communicating operator class changes between the display task and the TSTOL parser remains TBD.
"It will take more effort to implement TSTOL directives than what was needed to implement MSTOL directives. MSTOL provided more logic for checking directive syntax and default values. These functions are generic and must be standardized."
I believe these points are successfully addressed by the discussion above of directive definitions and defaults.
"[We need] an official mechanism to communicate to TSTOL developers our requests for additional capabilities (CCR style) and to communicate to the application developers a time frame when these new functions will be available."
I'll leave that to the task leaders.
"[We need a] TSTOL release schedule and a mechanism to integrate a new TSTOL with mission software."
The TPOCC release schedule was covered in the CDR. The TPOCC staff is currently working on the problem of configuration management.
"[We need a] TSTOL programmer's guide with examples."
A TPOCC programmer's guide, similar to the MAE programmer's guide, will be written. Assuming I understand the motivation for this request, I should point out that the interfaces (primarily network-based) between TPOCC tasks are much simpler than the interfaces between MAE tasks. The "how-to"'s of network programming and system variable access have been described in excruciating (or so I've been told) detail in a number of internal TPOCC memos. These memos, in conjunction with the network and file interface specifications from the CDR, should keep applications developers from feeling constrained by the lack of a TPOCC programmer's guide.
"[We need] a mechanism to test a new directive by an individual developer without updating the existing STOL interface. MSTOL provides such a capability."
So does TSTOL. Based on the questions asked at the meeting, I assume that the concern here has to do with testing a new directive's effect on an applications task. Since the TSTOL parser communicates with applications tasks via network connections, the TELL directive can be used to manually send arbitrary strings to an application, thereby simulating the actions of new directives.
Furthermore, the TSTOL parser is not even needed for this type of testing. talknet is a TPOCC utility that puts the user's terminal at one end (either client or server) of a network connection. Input from the user is forwarded to the other end of the connection and data received from the other end is displayed on the user's screen. talknet has been widely used on TPOCC to test network interfaces and it functions as an able stand-in for the TSTOL parser.
"[We must designate] a directive definition administrator for each mission who will be solely responsible for modifying the directive definition file."
More decisions for the task leaders.
MAE and MSTOL were a big step forward from previous POCC software environments. The TPOCC applications environment (TAE?) and TSTOL appear to be the next step forward. Holes in the TSTOL design will undoubtedly be uncovered as development progresses, so I look forward to future memos from the "MSTOL" folks.