12.7.5 Issuing a JP1 event when a response status changes
By setting JP1/IM to issue a JP1 event (3F11) when the response status of a JP1 event changes, you can achieve the following control. Hereafter, the JP1 event issued when a response status changes is referred to as a status event.
-
Keeping a history of response operations
When a number of operators perform response operations, you can utilize the issued status events to see who changed the response status, when it was changed, and to what status.
You can also obtain a historic record of operator responses for auditing purposes by outputting the event information (including status events) displayed in the Event Console window as a CSV snapshot.
- Organization of this subsection
(1) Notes
-
When JP1/IM is set to issue JP1 events for response status changes, one status event (3F11) is issued for one JP1 event that has been resolved. When the operator changes the response status of a number of JP1 events in a single operation, either in the Severe Events page of the Event Console window or by the jcochstat command, a status event (3F11) will be issued for every one of those JP1 events. Bear this in mind when using status event issue.
-
A status event (3F11) is triggered when a JP1 user changes the response status of a JP1 event in JP1/IM, and the status event is then registered in JP1/Base. If another JP1 user changes the response status of the same JP1 event before the preceding status event (3F11) is registered, the pre-response status stored in the new status event (3F11) may not be the actual status.
For example, if user A changes an Unprocessed JP1 event to Processing, and user B changes it to Processed at roughly the same time (slightly later than user A), the product will behave as follows.
Figure 12‒20: Product behavior when a response status is changed by multiple users ![[Figure]](GRAPHICS/CS071300.GIF)
The actual status transition follows the order in which the change requests are received (in this case, Unprocessed -> Processing -> Processed), but the pre-response status stored in the triggered status events (3F11) is the response status that applied when each user issued the change request (in this case, Unprocessed).