On Sun, Jun 07, 2026 at 08:54:32PM +1000, Attila Fogarasi wrote: > EVENTS is O(1) but with higher initial setup cost, while WAIT is O(n). > Breakeven is circa 2 ECBs, so for most scenarios EVENTS is faster, often > much faster. Of course there are other solutions that offer even greater > performance for specific scenarios, at an implementation cost.
O(1) is important, but I don't see useless O(1) overhead as reasonable. The application CPU related to requesting a system service or access method request includes the CPU used by making the request plus any CPU used to deal with resolving the request completion. I'm concerned with the CPU used by the EVENTS ECB= call which is required one for one for every application request. EVENTS ECB= requires a privilege boundry crossing and significant validity checking. This is valuable CPU which could be used to run the application. What is the EVENTS ECB= function? If the ECB is already posted EVENTS adds it to the EVENTS table of completed ECBs, if not it sets the ECB to a value consisting of an address ored with x'80000001' which is specific to EVENTS. When POST sees this value it causes POST to add the ECB to the EVENTS completion table. I don't see why the application program couldn't set this value in the ECB using CS. The application doesn't need the privilege boundary crossing nor the validity checking. The application would need to check for the ECB already being posted and if not use CS to set the above "magic" EVENTS value into the ECB. No SVC nor any validity checking is needed other than what the hardware is going to do for normal instructions anyway (protect key checks). For the "already posted" case the application has two choices. It can issue the EVENTS ECB= to get EVENTS to add this complete ECB to the EVENTS table. Or it can just process the completion on it's own with the possibility that it might be processing completions out of order with the ones already in the EVENTS table. I would expect that if the applications checks the ECB shortly after making the request the ECB would usually not yet be posted and the application's CS would complete setting the ECB up for EVENTS to deal with. So even if the application decided to use EVENTS ECB= for posted ECBs, this might not happen all often. So, how long does an EVENTS ECB= call take and how does it compare with a single CS instruction? other notes: 1. The CPU used when the application has nothing else to do except wait is useless CPU from the application point of view while the CPU used by EVENTS ECB= is CPU the application can use right now. Also assuming a O(1) wait function like EVENTS, the overhead of waiting goes down as the the application CPU usage goes up. The limit being an application which never waits (100% CPU). 2. This message thread caused me to investigate EVENTS internals for the first time. In addition to reading the IBM documentation again several times I looked at the MVS 3.8 source for EVENTS in modules IEAVEVT0 (EVENTS) and IEAVSY50 (WAIT POST TCB SWITCHING). I realize that this isn't the current source, however the interface has to be compatible and my guess is that IBM hasn't been making major changes in this area. 3. I've used WAIT both for single ECBs and ECBLIST with many ECBs many times. I'm also the author of UCLA/IPC (authorized code) which has an O(1) notify scheme NOTIFY=CS which adds problem program application completion elements to a list in application storage and allows the application to wait on one ECB and wake up on any request completion. Additional completions can be added while the application using IPC is running. This has no required SVCs issued for the 100% application case other than the IPC request calls. In the 100% application case, EVENTS will still require an EVENTS LAST= call to clear out the EVENTS table. Again this involves privilege crossing and validity checking overhead, however this isn't necessary for every request unlike EVENTS ECB= so it may not be that significant. 4. I've previously read about POST exits and thought that an authorized service similar to UCLA/IPC NOTIFY=CS could be implemented for use by non-authorized applications. This was before investigating EVENTS internals (earlier reading the IBM manuals on EVENTS never seemed clear to me on when calling EVENTS ECB= was required) I see now that EVENTS should be similar in performance to something using an authorized POST exit interfaced with a non-authorized application, especially if the EVENTS ECB= calls can be skipped. 5. Watch out for the communications ECB. It's not in application key however WAIT/POST/EVENTS all will allow the application to wait on it (but not post it). So the CS instead of EVENTS ECB= will not work for the communications ECB. ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
