I added a trace myself and I think I understand: when you have some SFS direcory accessed, and something changes in it (a file added/removed a Grant affecting you), the SFS server tells you once "something has changed", involving an EXT4000. The SFS client code will later pool the server to find out what was changed. Once the server sent you such such a message, other changes to that directory don't trigger another.
2007/11/9, Kris Buelens <[EMAIL PROTECTED]>: > > I'd say: test it, look at subroutine Extrn_event: and code a SAY when you > get a 4000 interrupt, than you can see how often it happens in your > environment. I know we can live with the number. You don't get an EXT 4000 > interrupt for each SFS call, far from that. From what I tested, I see that > one gets an EXT 4000 when you have an SFS dir accessed and someone issued a > GRANT AUTH for you for a file in that subdirectory (the SFS server has to > broadcast this to you). Maybe if you'd use Asynch CSL calls to SFS you'll > get much more. > > 2007/11/9, Thomas Kern <[EMAIL PROTECTED]>: > > > > Well, at least I did not make some silly error. > > > > When you use WAKEUP to trap the EXT interrupts, do you get alot of the > > EXT 4000 interrupts queued up when some exec that gets called as a TIMER > > event needs to query an SFS server via CSL calls? Hobbit client DISK > > function reports on CP allocations (PAGE, SPOOL, DRCT, TDISK) and > > optionally on SFS server allocations. > > > > /Tom Kern > > /301-903-2211 > > > > Kris Buelens wrote: > > > I've been reading and testing: > > > > > > * I get WAKEUP's RC 6 too, but when calling WAKEUP again, it > > > directly exist with RC 1. So, the SHUTTRAP signal triggers 2 > > > WAKEUP events: COSN & SMSG. Removing the CONS option doesn't do > > > > > anything. > > > * SHUTTRAP does not work like ADDRESS CMS, (so an eventual CP EXEC > > > wouldn't matter) > > > * Diverting the SMSG delivery method from VMCF to IUCV doesn't > > help > > > either. > > > * Using SHUTTRAP CP MSG * STOP doesn't change a thing. > > > > > > Bypasses: > > > When getting RC=6, test if another SMSG event is ready too: > > > 'WAKEUP +5 ( RDR SMSG FILE(HOBBIT TIMES *)' > > > if rc=6 then do /* RC 6 caused by SHUTTRAP? */ > > > saveRc=rc /* If yes, WAKEUP also has */ > > > 'WAKEUP +0 (SMSG' /* an SMSG event "stacked" */ > > > if rc=2 then rc=saveRc > > > end > > > Or, use the approach I ised in RxServer: I run WAKEUP with the EXT > > > option and test for external interrupt 2401 (see subrtn Extrn_event:); > > > SHUTTRAP can be loaded with the following: > > > 'PIPE COMMAND NUCXDROP SHUTTRAP' > > > 'NUCXLOAD SHUTTRAP (SYSTEM' > > > 'SHUTTRAP' > > > Disadavantage: when using EXT in a server that is conencted to an > > active > > > SFS, WAKEUP will get many EXT 4000 interrupts (your code can ignore > > > them, but the handling is extra overhead anyway). > > > > > > -- > Kris Buelens, > IBM Belgium, VM customer support -- Kris Buelens, IBM Belgium, VM customer support
