)NTERTÓTULOS COMO FØRMULA PARA ROMPER LA UNIFORMIDAD EN EL TEXTO EN EL SEGUNDO NIVEL DE
RRANQUE CON ANÏCDOTAS EJEMPLO
Once each record has been appropriately time stamped, it is easy to access historical informa tion in the database. To support a real-time oper ation, changes in the data displayed have to be communicated from the kernel to the user inter face. To accomplish that transfer, we defined a special time value called "current." Reading the database with the time key of current causes the data responses to be returned in two phases. In the first phase, the most recent data is read from the on-line database. In the second phase, the
Digital TecbnicalJournal
SERVER CLIENT
WAITING FOR SOMETHING TO DO.
REQUEST FOR X, IN TRANSIT.
I WANT TO DO X, AND THE SERVER CAN DO IT, SO . . . SEND A REQUEST! GO ON DOING WHATEVER CAN BE DONE. (SOONER OR LATER, WE DO ALL THAT CAN BE ACCOMPLISHED WITHOUT X HAVING BEEN DO
�
E.)READ REQUEST. DO X, WHICH MAY INVOLVE ISSUING REQUESTS OF OTHER SERVERS. SEND RESPONSE.
WAIT.
WAITING FOR SOMETHING TO DO. READ RESPONSE. j
CONTINUE WITH PROCESSING WHERE WE LEFT OFF. '
Figure 4 RequestjResponse Interaction
kernel will return a response whenever a new or changed value to the data is written to the on line database. A response received in this second phase is called "news." News can be generated by the collection of more up-to-date information or by other managers modifying the database. Data Evaluation
An important design choice was in what section of NMCC should the collected data be evaluated. This choice was imponant because data evalua tion is a compute-intensive operation. There were three basic choices.
1 . Data could be evaluated immediately after it was collected. This approach has two advantages:
a. Processing has to be done only once. That processing, however, would take place whether or not any user ever looked at the results. Thus the CPU time spent on com putation could be wasted.
b. The evaluated data would be reduced - and thus take less space - when stored in the database. However, a careful analysis found that in most cases the evaluated data was no smaller than the raw data. Fur thermore, in those cases where the data was reduced, information had been lost.
Digital TecbntcalJournal
No. 3 September 1986
i .
The approach also has I two disadvantages: c. Adding new ways of evaluating the data
would result in major changes to the software.
d. The compute-inten�ive evaluation could not be performed ort a separate machine. 2 . The data in the datab
�
e could be stored inraw form and evaluated in the kernel only when requested specifically by a user. While
avoiding the problems discussed in a. and b. above, this approach also suffers from the disadvantages in c. anq d.
3 . The data could be eval�ated in the user inter' face immediately befote presentation to the user.
We chose to use the third approach because adding new evaluation functions is easy, be cause evaluation is perfqrmed only when re quested by a manager, and because the com: pute-intensive evaluatio
�
could be moved to a separate machine, a network-management workstation.Kernel
The major functional sections of the kernel are depicted in Figure 5. The system is built in suc cessive layers around the bean of the kernel, a
1 3 3
The NMCCjDECnet Monitor Design KERNEL INFORMATION MANAGER (KIM) - - -- - - Figure 5
physical database that uses Digital's RdBJVMS software. This relational database system was chosen because it provides data integrity, its data model is similar to the NMCC data model, and it offered a simple method for handling sets of records.
The physical database is contained within a logical database (LDB) system. LDB provides transaction services and abstracts the operations on the database, thus masking from the rest of the system the detailed knowledge of how the data base is implemented. The interface to LDB is asynchronous, allowing the rest of the system to proceed with other actions while data is read from or written to the disk. Because the interface to the RdBJVMS software is synchronous, LDB is implemented as multiple server processes sepa rate from the kernel. Each server is synchronized with its database transaction.
1 34
- - --
NMCC Kernel
The logical database is contained within the kernel information manager (KIM) , to which all requests to read or modify data are made. The actions performed by KIM are atomic, mean ing they act as a single unit even though com posed of more primitive actions. KIM's clients are thus freed from needing detailed knowledge of the transactions. But KIM's most important task is providing a uniform way to request histor ical and real-time data. This uniformity greatly simplifies the design of all other parts of the code. The user interface and reports package do not need special code to perform historical or real-time functions. Instead, they only have to perform some simple data manipulations; KIM handles all the i ntricacies of detailed processing. Many functions are clustered around KIM, all of which use it to access their data.
Digital Tecbnical]ournal
Data is collected from the netwoPk by the net work management interface (NMI) , which polls the systems in the network periodically for data.
As defined in the DNA architectural specifica
tion, which is the formal basis for the DECoct software, each system in the network stores man agement information and accommodates remote access to it. u The protocol for accessing this
data is called NICE, which NMI uses to request ·
status, characteristic, and counter information. The components for which these types of infor mation can be collected include the system, the lines, the circuits, and any other remote node in the network.
Counters have a limited range . When they reach their maximum values, they latch, and any subsequent events will not be counted. There fore , if NMI detects any counters that have already or may soon latch, it can zero their values.
The kernel can poll multiple systems simulta neously. The list of systems to poll and the fre quency of polling for each kind of information for each component (twelve kinds in all, four components times three types) are all controlled by the network manager. This control data is stored in the on-line database.
The data collected by NMI is passed to KIM, which determines if the data is news. If so, KIM writes the news to LOB and notifies any user who has requested to be notified when that particular news arrives. Among the other facts that could be discovered from the data collected is that new systems, lines, or circuits have been added to the
TASK TASK TASK TASK
network. When discovercd,
l
they arc added to the on-line database.· If allowed to, the database would grow with out bounds with continuohs polling. The data base administration (DBA) software prevents this problem by periodically pUrging old data from I
the database. '
One unique attribute of the data collected from the DECnet network is its extensibility. Each new implementatiop or upgrade of the DECnet software can define new fields in the I records returned from the polling operation. That is accomplished by a data format (called NICE data blocks) , which is self describing and extensible. The kernel preserves this structure and also enhances it so thaf all data passed from one major function to another is carried in this form.
The log file writer (LFW) produces the history files that are read to produce reports. At fixed periods, LFW writes to a set of files the data col lected since the last histo
rt
file was written.The NMCC protocol serVer (NPS) is responsi ble for the kernel's end of the protocol link by which the UI program communicates with KIM. In effect, NPS, the NMC� protocol, and the NMCC protocol client (called NPC in the user I interface) allow remote access to the data main- tained by KIM. Multiple protocol links can be supported by the kernel , thus allowing multiple users to access the data.
The need for the asynchronous operation of all I these functions posed a major design problem for the NMCC development team. Without our going
TASK TASK
. . .
TASK• ' ... _ _ -"<... ..._/
...
-;:; _ _:::..../. I ... ... ... ... ... / - --,... - ... _
0 - - - -- - - --
/
DECnet lfO'
\ I
J DECnet 1/0 RESOURCE SCHEDULER
. RESOURCE RESOURCE .
.__ . ... VAX/VMS OPERATING SYSTEM - - - TASK TO TASK MESSAGE PASSING RESOURCE - · - · DEC net LOGICAL LINK .TO OTHER PROCESSES
Figure 6 Kernel Resource Scheduler
}---.
'Digital Technical Journal 1 3 5
No. 3 September 1986
The NMCCjDECnet Monitor Design
into excessive detail , the kernel is structured as multiple, cooperating tasks running asyn chronously (e .g. , a function could be one or even one hundred tasks, as is the case with NMI) . The tasks share resources to which they at times need exclusive access. The tasks must communi cate with each other, and they must be sched uled. The software that performs these chores is called the resource scheduling services (RSS) . The design of RSS is based on the processjmoni tor structure proposed by C .A.R. Hoare. 3 The relationship between the tasks, RSS, and the mes sage-passing services that allow communications between the tasks is described in Figure . 6 . The main advantage of this approach is that the devel opers writing the tasks did not have to deal with the details of interrupts, synchronization, or scheduling.