DTJ Number 3 September 1987 - Digital Technical Journals

New Productrequests and responses to be transmitted in asingle message across the logical link. The protocolhas proven to be very fast, yet not expensivein terms of CPU time. This fact has allowed us tosee a definite improvement in performancewhen the kernel and the UI program are run onseparate machines connected by an Ethernetcable.Layered on top of the protocol client is therequest manager (RM) . RM maintains a list of theoutstanding requests so that they can be matchedto their responses. RM can be viewed as a set ofservice routines used by the data managers. Theinterface can be either synchronous (RM"blocks" until the response is received) or asynchronous(RM notifies the main routine via anevent flag when a response is received) . Thecode to access the synchronous interface issimpler for the requesting person to program;this interface also behaves in a way that is moreintuitive to the user. On the other hand, the asynchronousinterface provides better performanceand must be used to implement real-timemonitoring.If the protocol link to the kernel should be disconnected(perhaps by a failure in the network) ,RM wi ll first wait and then attempt to reconnectto the kernel. These actions allow the UI programto run unattended as a permanent display.RM detects and eliminates duplicate readrequests, thus saving CPU time. It also cancelsold read requests when they are dropped fromthe cache because of "old age ." Finally, RMkeeps the pipeline flowing by receiving data atthe interrupt level and buffering that data forlater use.The display data manager (DDM) provides theaction routines with an interface to read from theIdatabase. DDM contains an internal cache of datathat has been recently read from the database .This cache improves the monitor's performanceby decreasing the flow of ata between the UIprogram and the kernel. The UI process also runsIfaster because a user reques for data can often besatisfied by a short access to the cache rather thana longer one to the on-line database in the kernel.The cache is purged accord ing to a leastrecently-usedalgorithm. I.n a read for currentinformation, the kernel has remembered theIrequest so that it can notify the UI program ofnews. Thus the cache purging logic will ask RMto cancel that outstanding request when the datais no longer needed. DDM also provides a consistentview of the data in the cache by locking itscontents so that cache up9ates (read responsesreceived by RM) do not change those contentswhile the action routines a ' re reading the cache.Among other benefits, this logical separationallows the display action routines to be quitesimple.The control data manager (COM) provides theaction routines with a synhronous interface tomodify data in the databas .Action RoutinesThe action routines control the Ul program andprovide most of the functionality visible to theIuser. The major action modules are the UI main,the parser, and the display, ! modify, and miscellaneousaction routines. UI' main is the highestlevelroutine in the program. Figure 8 shows thepseudocode of this routine's algorithm. The Ulprogram waits for one of two actions to occur:either the user enters data bn the keyboard, or aIresponse to a currently outstanding request isreceived from the kernel.IInitialize;current-display:=''N etw ork Summary Current Du rat ion 15 Minutes'' ;ILoopWa itFor(user-input DR response-arrived) ;If user-inputThenGe tCommand(command , current-display, new-display> ;Par se(command , current-display, new-disp lay> ;current-display:=new-display;Display(current-display> ;Unt il exi t ;Termin a te;Figure 8UI Main PseudocodeDigital Technical journal 13 7No. 3 September 1986