I n i t i a l i z e ;
I
I
database. DDM contains an internal cache of data that has been recently read from the database . This cache improves the monitor's performance by decreasing the flow of �ata between the UI program and the kernel . The UI process also runs
I
faster because a user reques� for data can often be satisfied by a short access to the cache rather than a longer one to the on-line database in the kernel . The c a c h e i s p u rged accord i n g to a l e a s t recently-used algorithm. I.n a read for current information, the kernel has remembered the I request so that it can notify the UI program of news. Thus the cache purging logic will ask RM to cancel that outstanding request when the data is no longer needed. DDM also provides a consis tent view of the data in the cache by locking its contents so that cache up
9
ates (read responses received by RM) do not change those contents while the action routines a're reading the cache. Among other benefits, this logical separation allows the display action routines to be quite simple .The control data manager (COM) provides the action routines with a syn
�
hronous interface to modify data in the databas�.Action Routines
The action routines control the Ul program and provide most of the functionality visible to the I user. The major action modules are the UI main, the parser, and the display, !modify, and miscella neous action routines . UI ' main is the highest level routine in the program. Figure 8 shows the pseudocode of this routine's algorithm. The Ul program waits for one of two actions to occur: either the user enters data bn the keyboard, or a I response to a currently outstanding request is received from the kernel .
c u r r e n t - d i s p l ay : = ' ' N e tw o r k Summa r y C u r r e n t Du r a t i o n 1 5 M i n u t e s ' ' ;
L o o p I
Wa i t F o r ( u s e r - i n p u t D R r e s p o n s e - a r r i ve d ) ; I f u s e r - i n p u t
T h e n
Ge t C omma n d ( c omma n d , c u r r e n t - d i s p l ay , new - d i s p l ay > ; P a r s e ( c omma n d , c u r r e n t - d i s p l ay , n e w - d i s p l ay > ;
c u r r e n t - d i s p l ay : = ne w - d i s p l ay ; D i s p l a y ( c u r r e n t - d i s p l ay > ;
U n t i l e x i t ; T e r m i n a t e ;
Figure 8 UI Main Pseudocode
Digital Technical journal 1 3 7
No. 3 September 1986
The NMCCj/JECnet Monitor Design
The parser first performs a syntactical analysis of the command entered by the user. It then dis patches to the correct action routine, which per forms the command. Table 1 lists the commands si.1pported by the UI program .
The parser is context sensitive, meaning that the current display on the user's terminal is used to resolve ambiguity wherever possib l e . For example, if the user is currently viewing a dis play for "Network System BOSTON" and issues the command SHOW LINE UNA-0 TRAFFIC, the parser will conclude that the line referred to in the command is part of a system called BOSTON. The parser accepts abbreviated commands and allows mosckeywords to be entered in any order. Since the main function of the UI program is to present information to the user, the display com mands are the most important.
Each display action routine presents a single display to the user. The parser determines which display is the current one. Since any display can be changed if new data arrives from the kernel , the correct display action routine is accessed on each main cycle of the UI program . The current display is defined by the three key items men tioned earlier: the component, the page, and the time of collection .
The display action routines select the informa tion to be displayed and then copy it to the pre sentation routines. The information displayed Table 1 Commands Supported by Lll Display Commands
SHOW display-id
N EXT PREVIOUS POP
PAN direction [distance]
FIND component-id
MAGNIFY scale-multiplier• COM PR ESS scale-multiplier•
Modification Commands
ADD component-id
DELETE component-id SET [component-id] item-list
MOVE component-id X coordinate Y coordinate •
Miscellaneous Commands
HELP topic
SPAWN DCL-command
REPORT report-command
CONN ECT kernel
EXIT
*Only applies to the Network Map
1 38
can come either directly from the database or from the evaluation routines, which eva luate data stored in the database. The information dis played can even come from different database records, the intent being to display information that provides a clear, related viewpoint.
The evaluation routines get their data from the cache in DDM. It's quite possible that the data may not yet be in the cache (if this is the first time the data has been requested) . In that case the evaluation routines have to either present no data or take some reasonable default. Eventually, the data will appear in the cache, at which time the response_arrived flag will be set and the updated data will be placed on the term inal screen .
This approach was taken because we did not want to block all actions while waiting for poten tially large amounts of data to be returned. More over, in a real-time display, we could not predict when news would arrive. In practice, this design choice has proven to be sound because the user remains in control . He can issue another com mand or change the current display at any time. We did find that early versions of the software, which sent no indication of progress to the user, tended to be confusing since the user was unsure if the software had completed its update of the display. Currently, the software indicates when it is "working, " (i . e . , updating the screen) . In future versions, clearer indications of progress may be added.
During the design we were concerned that evaluating all the information on a display would consume too much CPU time since it was possi ble that only one item might have changed. We considered a number of ways to run the evalua tion routines " i n reverse , " so that only those items that were changed by news data would be re-evaluated . However, we rejected al l those ways since they were too complex to implement. The problem was that a change in one piece of data would change items shown on many dis plays, only one of which was seen by the user.
An important goal of the UI program was to make as simple as possible the writing of a dis play action rou tine. These routines and the eval uation software that supports them are the largest body of code in the monitor.
Many evaluation routines are supported. Some are used to compute statistics from the data col lected from the counters. The method used is called normalization, which uses averaging and
Digital TecbnicalJournal
Figure 9 Photo of Computer Screen interpolation techniques to estimate statistics
over any time period. Other routines determine the current states of portions of the network, while still others determine the configuration of the network.
The modify action routines change the con tents in the on-line database. Invoked by the parser, these routines use the services of CDM and are synchronous with respect to the data base. They were made synchronous to avoid con fusing users whose commands were invalid. If an error message indicating that a command was invalid was displayed long after the user issued the command, he might have proceeded with another command and therefore might lose track of the cause for the error.
The remaining commands supported by the UI program perform such functions as providing help to the user, spawning a subprocess, invok ing the reports package, connecting to a different kernel in the network, and t he all-important EXIT command.
Digital TechnicalJournal
No. 3 September 1986