Message control system6658484Abstract A method for controlling messages in a software system. The method activates a report-handling module when a subroutine has a message to send. The subroutine passes an identification to the report-handling module. The subroutine then passes a message and message level to the report handling module. The report-handling module then determines the message level to be reported for that subroutine, the process from which that subroutine is sending messages and the message level to be reported for that process. If the message level of the message compares correctly to the message level of the subroutine and the process, the message is reported. Claims What is claimed is: Description BACKGROUND OF THE INVENTION
Message Type Priority
Exception 1
Error 2
Warning 3
Information 4
Debug 5
The above table is for either processes or subroutines. The process level table (PL) lists the various processes and their message level. The subroutine level table (SRL) lists the various subroutines and their respective message priority levels. Once the report handler 10 has acquired the process identification (PID) and the subroutine identification (SRID) it queries these two tables for the process message level (PL) and the subroutine message level (SRL). The system developer could set these tables up manually during set up of the system. However, an executable file could be used to set up the tables with indices providing the correlation between the messages and the data. This would save the developer time and save execution time by not searching the table sequentially. The options for table set up are left up to the system designer and the above examples are merely considerations. Returning to FIG. 1, the procedure then moves to step 18 in which these levels are compared to the incoming message level received by the report handler from the subroutine. Note that the message only contains the message information, the report handler must extract the context in which the message was sent. The report handler then compares the level of the incoming message (ML) to the process message level (PL) and the subroutine message level (SRL). If the incoming message level is of a lower level than either the process message level or the subroutine message level, the message is reported at step 20. If the message level is not a lower than either of the two message levels, no report is sent and the report handler process ends. Note that the comparison of less than is dependent upon the manner in which the message priorities are laid out. If the ordering of severity were reversed, the message would be reported if it were of a higher level, rather than a lower level. The above example is merely for demonstrative purposes only and is in no way intended to limit the specifics of the how the comparison is performed. In this manner, then, only messages that are above a certain predetermined priority level are reported. This allows the system designer or troubleshooter to differentiate problem sources, between processes, subroutines or subroutines under different processes. This allows the user performing the analysis to more closely track and isolate problems in the system. One example of a situation in which it is difficult to isolate problems is in an instance of mutual exclusion, where two processes are prohibited by the system design from operating at the same time. If these two processes are using the same subroutine, it is impossible to tell which of these processes is actually running in current systems. The only message received is that the subroutine is running or has errors, with no idea of whether that subroutine had problems in one process and not in another, in current systems. An example of such a situation is shown in FIG. 2. In this example, there are two processes, process A and process B. Both use a subroutine (SR). Between the two processes, B has the higher operational priority, so it is programmed to take over the processor when it is running. However, there is a critical region of the subroutine in which all operational priorities are suspended until the critical region is completed. With these parameters established, the sequence of events is shown in FIG. 2. At step 22, process A starts the common subroutine SR. Process A enters the critical regions of the subroutine at step 24. During performance of the critical region, a semaphore is set that prevents any other processes, including those with higher operation priority, from taking the processor. At step 26, process B has tried to take the processor, but since A has set the semaphore, B is sent back to the semaphore queue. However, at step 28, A exits the critical region of the subroutine, but is still in the subroutine itself. Since B has higher operational priority, A is suspended from the subroutine and sent to the semaphore queue as soon as it releases the semaphore and B starts to operate. Note that this happens regardless of B's relationship to the critical region of the subroutine, with respect to process A. B can now only be preempted from the processor is a third process with a higher operational priority enters the subroutine and B is not in the critical region. Once B completes the subroutine at step 30, after it releases the semaphore. At step 32, then, A finally completes the subroutine. The above example is merely a context in which a message control system that differentiates the priorities of messages between processes and subroutines would be helpful. For example, assume process B was set to a higher level than process A. In this example, the messaging system would report information from process B and only exceptions or errors from process A. The subroutine will probably be set to have a higher level as well. During the sequence of events described in FIG. 2, then, the system designer or trouble shooter would be able to track the preemption of the processor by B, and would only be told if there were problems with the subroutine running under process A. In this method, the message level is not statically bound to the message. The same message can be used in different contexts without requiring creation of new messages. For example, if two drivers were being analyzed, one could have a timeout set as a warning or information, using the messaging scheme described in the table above. In the other driver, a timeout would be reported as an error. The same message, timeout, would be reported in one instance and not in the other. This saves message space and allows interoperability between message and severity. Thus, although there has been described to this point a particular embodiment for a method and structure for a message control system, it is not intended that such specific references be considered as limitations upon the scope of this invention except in-so-far as set forth in the following claims.
|
Same subclass Same class Consider this |
||||||||||