Thanks, I will look into it when I get into the office.
I don't think the Hobbit code actually accesses any directories itself
and I have mine installed on a minidisk. But I will have to check it
when Hobbit is installed in an SFS allocation.
/Tom Kern
/301-903-2211
Kris Buelens wrote:
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]
<mailto:[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
