We were able to bring RACF to its knees: our LOGON procedure included a RAC LISTUSER to see which application the VM in question was allowed to use, and react upon the result. We also had an SVM to start and stop groups of services machines: with the start of large groups, RACF got overwhelmed.... Maybe you've got something similar? (we solved the problem by keeping the user groups in a CMS file, rebuilt every night from a RAC LISTUSER *)
2008/6/13 Colin Allinson <[EMAIL PROTECTED]>: > > I have a strange one and I am looking for ideas to check out. > > We have a RACF database shared between 4 VM systems (Database DASD set as > shared on all 4). > > 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. > > > Colin Allinson > > Amadeus Data Processing GmbH > -- Kris Buelens, IBM Belgium, VM customer support
