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).
