JPH0461379B2 - - Google Patents

Description

[Detailed Description of the Invention] [Summary] In a computer system, an event management list is provided to manage the correspondence between notification events and receipts, and
a monitoring request processing unit that registers the contents of a monitoring request; a notification request processing unit that processes requests related to event reception; a notification request processing unit that processes requests related to event notification;
By providing a monitoring cancellation processing unit that processes requests for cancellation of monitoring requests, it is possible to create a unified system that allows event notifications to flexibly notify the event receiving side without explicitly being aware of the event receiving side. This enables notification and reception of events.

[Industrial application field]

The present invention relates to an event notification/reception processing method in a computer system, and more particularly to an event notification/reception processing method in a computer system that enables unified event notification/reception independent of event type or event content.

When notifying an event that occurs asynchronously in a computer system to a processing unit that performs some processing on that event, a notification system that has independence between the notifying side and the receiving side and is versatile enough to be independent of the type and content of the event. It is hoped that you will be able to receive it.

[Conventional technology]

FIG. 7 shows an example of the conventional method.

In computer systems, it is sometimes necessary to detect an event during the execution of a program and to notify the event to a location other than the flow of processing.
In the conventional method, the notification side of an event is fully aware of the party who receives and processes the event (hereinafter referred to as the recipient), notifies them in a close relationship, and uses the notification as an opportunity for the recipient to start processing. It is taken. Therefore, as shown in FIG. 7, notification means corresponding to each purpose existed within the system.

[Problem that the invention seeks to solve]

The conventional method described above has the following problems.

(i) If you want to notify multiple recipients of an event,
The notice must be repeated for each. For example, as shown in FIG. 7, when program A detects event D and attempts to notify program B and program C, which are located separately, using notification method E, first program B is notified using notification method E. Notify using E. Next, program C must be notified in the same way using notification method E.

(ii) When attempting to notify an event, it is necessary to confirm in advance that the other party exists. In the example of FIG. 7, program A needs to confirm that program B and program C exist before notifying each of them.

(iii) Since the event notification side and the receiving side are statically linked, the area increase of the receiving side cannot be dynamically changed. That is, the receiving side cannot monitor, request or cancel a receipt request, and always relies on notifications from the notifying side. If the recipient changes, the notifying party must also make changes accordingly. For example, in FIG. 7, if a new program F wants to receive event D, the notification source program A must add processing to notify program F of event D as well.

(iv) If a new event that requires notification arises, a means of notification must be developed for that purpose. Therefore, productivity is not improved and costs are increased. For example, in FIG. 7, if a function is added to program A and it becomes necessary to notify program F of a new event G that is completely different from the previous event E, a new notification method H must be developed.

The present invention aims to solve the above-mentioned problems, and aims to provide a means that increases the independence between the notifying side and the receiving side, and enables unified notification that does not depend on the type of event or the content of the event.

[Means for solving problems]

FIG. 1 shows an example of the basic configuration of the present invention.

In FIG. 1, 10 is a processing device consisting of a CPU and memory, etc., 11 is a receiving entity that receives notifications, 12 is a notification entity that notifies events, 13 is an event management unit that manages events, and 14 is a request for monitoring events. 15 is a monitoring cancellation processing unit that processes a request for cancellation of a monitoring request; 16 is a reception request processing unit that processes a request related to receiving an event; 17 is a notification request processing unit that processes a request related to event notification; 18 is an event storage processing unit that stores event information;
19 is an event management list, 20 is an event queue that stores events that have occurred, 21 is an event block that stores event information, 22 is an event storage file, 23 is a display, 24 is a general file, and 25 is OPNEVENT for making monitoring requests. (Open event) macro, 26 is RCVEVENT (receive event) macro that requests reception, 27 requests release of monitoring.
CLSEVENT (close event) macro, 28
represents the NTFEVENT macro that requests notification.

In the present invention, event information occurring in the system is
An event management list 19 is provided to manage each monitoring request unit. The event management list 19 includes a recipient entity information column that stores identification information of the recipient entity 11, a monitoring event information column that stores event information to be monitored and received,
It has storage areas for a condition column for storing reception conditions, a reception waiting information column for storing reception waiting information, and an occurrence event information column for storing event information for which a notification request has been made.

The monitoring request processing unit 14 receives requests from the receiving entity 11.
In response to an event monitoring request made by the OPNEVENT macro 25, recipient entity information, monitoring event information, and, if necessary, receiving condition information are registered in the event management book 19. This condition is such that, for example, when an event to be received occurs under various users, only events that occur under a certain user are to be received.

When the RCVEVENT macro 26 is generated from the receiving entity 11, the receiving request processing unit 16 is activated. The receipt request processing unit 16 searches the event management list 19, and if an event for which receipt is requested has occurred, it notifies the receiving entity 11 of the event, and if the event has not occurred, it notifies the receiving entity 11 of the event. , performs a process of setting reception waiting information in the event management list 19.

If there is an event that the notification entity 12 wants to notify, it specifies the event and sends the NTFEVENT macro 2.
Issue 8. As a result, the notification request processing unit 17
is activated, the notification request processing unit 17 searches the event management list 19 for the corresponding monitoring request contents, and if reception waiting information has already been set, notifies the event to the reception request source. In addition, if reception waiting information is not set, the event queue 20 pointed to from the event information column of the event management list 19
A process of queuing an event block 21 having event information is performed.

The monitoring cancellation processing unit 15
By issuing the CLSEVENT macro 27, the corresponding monitoring request contents are deleted from the event management list 19.

[Effect]

The receiving entity 11, which is the recipient of the event, makes a request to wait for the occurrence of the event later within the scope of the monitoring request made in advance. Therefore, the receiving entity 11 can flexibly wait for the occurrence of an event, monitor all events that have occurred after the monitoring request, and receive them when necessary.

On the other hand, the notification entity 12, which is the event notifier, uses a unified notification method that does not depend on the type or content of the event.
That is, the NTFEVENT macro 28 can notify of an event that has occurred or has been detected. On the side shown in FIG. 1, it is possible to instruct whether or not to save the notified event at this time, and if the event information is instructed to be saved, the event storage processing unit 1
8 is activated and event information is recorded in a predetermined event storage file 22. This event information is
It can later be read from the event storage file 22. Therefore, if it is necessary to receive events that occurred before the monitoring request, event information can be obtained from this event storage file 22.

If multiple recipients have submitted monitoring requests or requests to wait for receipt in the event management list 19, all recipients will be notified of the event. In this case, if there is only a monitoring request and no receipt request has been issued yet, the event information is stored in the event queue 20 on the memory, and when a receipt request comes later, the event information is handed over.

Therefore, for one event, multiple receiving entities 1
1 can independently display the data on the display 23 or store it in the file 24 as needed.

〔Example〕

FIG. 2 is an explanatory diagram of an embodiment of the present invention, FIG. 3 is an explanatory diagram of monitoring request processing according to an embodiment of the present invention, and FIG.
FIG. 5 is an explanatory diagram of a receipt request process according to an embodiment of the present invention, FIG. 5 is an explanatory diagram of a notification request process according to an embodiment of the present invention, and FIG. 6 is an explanatory diagram of a monitoring release process according to an embodiment of the present invention. It is a diagram.

In the example shown in Figure 2, recipient R1 has registered to monitor event A and event B;
R2 receives event C, recipient R3 receives event B and event C
registered to be monitored.

When the notifier N1 requests the event management unit 13 to notify the event A, the recipient R1 is notified of the event A by searching the event management list 19. When the notifier N2 requests the event management unit 13 to notify the event B, the recipient
R1 and recipient R3 are notified of event B. Similarly, when the notifier N3 requests the event management unit 13 to notify the event C, by searching the event management list 19,
Recipient R2 and recipient R3 are notified of event C.

In this way, in the present invention, instead of determining the recipient on the event notification side, the request from the receiving side is registered in the event management list 19, as shown in FIG. The event is determined by searching the event management list 19 to notify all necessary recipients of the event.

Next, one embodiment of the present invention will be described in more detail with reference to FIGS. 3 to 6. In the example below, to simplify the explanation, the recipient is R1,
The following description assumes that the monitoring event is A, the condition is user X, and the receiving request is Y. It is assumed that event A occurs in relation to user X's processing.

By the OPNEVENT macro 25 shown in Figure 1,
The monitoring request processing unit 14 performs processing as shown in FIG. 3, for example. That is, a new entry is secured in the event management list 19, and the recipient R1 is added as the monitoring request content.
, the information on the monitoring event A, and the information on the user X are registered.

Using the RCVEVENT macro 26 shown in FIG. 1, the receipt request processing unit 16 performs the processing shown in FIG. 4. In the following explanation, the numbers ~ refer to the fourth
This corresponds to the process numbers ~ shown in the figure.

When receiving a request to receive an event, the event management list 19
Find the entry for the corresponding recipient R1 in and check whether event A has already occurred. If the event is not queued in the occurrence event information column, it means that no event has occurred, and control is transferred to processing; if the event is queued, control is transferred to processing.

If event A has not yet occurred, information about the reception waiting request Y is entered in the reception waiting information column of the event management list 19, and the system enters a waiting state. Thereafter, when event A is notified, the waiting state is released and control is transferred to processing.

The event that has occurred is passed to recipient R1, and 1 is subtracted from the number of unrecipients written in the event block.

If there are recipients who have not yet received the event A, check whether the number of unrecipients written in the event block is not 0, and if it is not 0, the event information is Save it in memory as is.

If there is no other unrecipient who wants event A, the information about event A is erased from the memory and the process ends.

Using the NTFEVENT macro 28 shown in FIG. 1, the notification request processing unit 17 performs processing as shown in FIG. 5. In the following explanation, the numbers ~ refer to the 5th
This corresponds to the process numbers ~ shown in the figure.

Information about the event A that has been notified is written into the event block 21, which is an event information area on the memory.

Based on the specification from the notification side, it is determined whether or not it is necessary to save the event A. If it is necessary to save it, the event information is stored in the event storage processing unit 18 shown in FIG. 1 in the event storage file 22. Request writing.

Next, the event management list 19 is searched to find a recipient who wants this event A. At this time, in addition to the event of the monitoring request, the condition contents of the monitoring request are also examined to extract the target.
If there is a recipient requesting monitoring of event A (in this case, recipient R1 exists), after performing the next process or process, the process is repeated from the process onwards, and the event is Continue searching the management list 19. When the search of the event management list 19 is completed, processing is executed.

If there is something for which event A has been requested to be monitored, 1 is added to the number of unrecipients of event A written in event block 21. Then, it is checked whether there is a waiting list in the waiting list information column of the event management list 19.

If there is a waiting list, the waiting list is released. As a result, the reception waiting state shown in FIG. 4 is released.

The reception waiting information column in the event management list 19 is cleared and the reception waiting information is deleted. Control is then returned to the process to find the next recipient.

If there is no waiting for receipt, a pointer to the event block 21 that stores information about the event A is set in the event information column of the event management list 19. Control is then returned to processing.

If there is no recipient who has requested monitoring of event A, the event is deleted from event block 21 in memory. If there is a recipient who has requested monitoring of event A, the event block 21 in memory is left as is and the process ends.

Using the CLSEVENT macro 27 shown in FIG. 1, the monitoring cancellation processing section 15 performs the processing shown in FIG. 6. In the following explanation, the numbers ~ refer to the 6th
This corresponds to the process numbers ~ shown in the figure.

When the cancellation of the monitoring request is accepted, event management record 1
Delete the contents of the monitoring request from 9.

When erasing by processing, it is checked from the occurrence event information column of the event management list 19 whether or not an event has occurred in response to this monitoring request. If an event is queued in this event information column, check whether there are any recipients who have not yet received this event by checking the number of unrecipients entered in the event block, and if not, delete this event block. Delete it from memory and end the process.

In the above explanation, an example of synchronizing reception waiting was explained, but there are synchronous types and asynchronous types of reception requests, and in the asynchronous type, when the reception request is issued, the event has not yet occurred. In this case, it is also possible to immediately return control to the source of the request for receipt, instead of entering the reception waiting state.

〔Effect of the invention〕

As explained above, according to the present invention, the receiving side of the event can freely monitor the occurring event or stop the monitoring, and can receive all the events that have occurred within the monitoring period. You will be able to do this. In addition, the event notification side does not need to be uniquely aware of the existence of the recipient or who the recipient or recipient group is at the time of notifying the event, and the notification is unified and does not depend on the type or content of the event. It can be performed. Therefore, it is possible to pass the occurrence event to a plurality of recipients with a single notification, which facilitates program development on the notification side and the recipient side, and improves productivity. Furthermore, since the notification/receipt processing is unified, maintainability is also improved.

[Brief explanation of drawings]

FIG. 1 is a basic configuration example of the present invention, FIG. 2 is an explanatory diagram of an embodiment of the present invention, FIG. 3 is an explanatory diagram of monitoring request processing according to an embodiment of the present invention, and FIG. 4 is an illustration of an embodiment of the present invention. FIG. 5 is an explanatory diagram of the notification request process according to an embodiment of the present invention. FIG. 6 is an explanatory diagram of the monitoring cancellation process according to an embodiment of the present invention. An example of the conventional method is shown below. In the figure, 10 is a processing device, 11 is a receiving entity, 12
is the notification subject, 13 is the event management unit, 14 is the monitoring request processing unit, 15 is the monitoring cancellation processing unit, 16 is the reception request processing unit, 17 is the notification request processing unit, 18 is the event storage processing unit, and 19 is the event management list. , 20 is the event queue,
21 is an event block, 22 is an event storage file,
23 is display, 24 is file, 25 is
OPNEVENT macro, 26 is RCVEVENT macro, 27 is CLSEVENT macro, 28 is
Represents the NTFEVENT macro.

Claims (1)

[Scope of Claims] 1. An event notification/reception processing method in a computer system that notifies and receives events between a plurality of processing units, which includes at least receiving entity information, monitoring event information, reception waiting information, and occurrence event information. An event management list 19 having areas for storing data in correspondence with each other;
A monitoring request processing unit 14 that registers monitoring request details in
In response to a request to receive an event after a monitoring request, the event management list 19 is searched, and if the corresponding event has occurred, the event is passed to the requester, and if the corresponding event has not occurred, the event is sent to the requestor. , a reception request processing unit 16 that performs a process of setting reception waiting information in the event management list 19; a notification request processing unit that performs processing to notify the receipt request source of the event if the event is received, and to queue the event to be notified in the occurrence event information column of the event management list 19 if the reception waiting information is not set; 17; and a monitoring cancellation processing unit 15 that performs a process of deleting the corresponding monitoring request contents from the event management list 19 in response to a cancellation request of an event monitoring request. Processing method.