On Friday, 06/13/2008 at 10:44 EDT, Colin Allinson <[EMAIL PROTECTED]> wrote: > Today we were having occasional timeouts from RACF on one of the systems and I > could see that RACFVM was doing a steady 17.6 IO per second on this system. > > There is no activity on RACF on the other 3 systems and there are no DASD > reserves in place anywhere. > > I cannot see any reason for the activity (nothing in the console) and it
> resumes even after I recycle RACF. > > I have looked for a looping user and cannot see anything chewing up load nor > any stream of RACF failures on the Op console. > > It was causing the occasional timeout earlier when the systems were busy but > now it does not seem to be doing any harm. > > Does anyone have any other ideas where to look for what is causing this IO. Where is the I/O going? SMF log? Database? In general, RACF does nothing by himself. #CP TRACE EXT RUN on the suspect RACFVM server will tell you if its run amok or if something is driving the horses. The external interrupts can come from CP on the *RPI interface on from guests like LDAPSRV, FTPSERVE, and REXECD (issuing RACROUTEs). QUERY IUCV RACFVM will give you the path ids. If you've got QIUCV, I think it will tell you where the external interrupt buffer is in the RACFVM server. My version does this: QIUCV EXEC 1.2 (C) IBM Corporation, 1989, 2008 User RACFVM has 4 out of a possible 300 connections. - External interrupt buffer is located at 00E84D08 - Control interrupt buffer not defined - 1208 messages received, 1209 sent, 0 failed But you can also go to each user listed in QUERY IUCV and do a TRACE IUCV on those users. Alan Altmark z/VM Development IBM Endicott
