On Monday, 06/16/2008 at 10:29 EDT, Colin Allinson <[EMAIL PROTECTED]> wrote:
> You are right, I could do that. The only thing makes me reluctant is that I > think that RACF is only responding to something else on the system that is > looping (or fast cycling) and the only problem is finding what it is. I am > reluctant to report a problem on RACF when even I don't believe RACF is at > fault. Double-check SETEVENT LIST to make sure it reflects your wishes. If that's unrevealing, here is my ACITRAP EXEC. ACITRAP START, ACITRAP STOP, ACITRAP PROCESS <trf> If you need to you can call into RACF Support and they will help you with this. It shows what calls CP is making to the ACI and dumps the ACIPARMS control block. This does not guarantee that that requests are going to the server, but you can see what CP is doing. Details on ACIPARMS is in the CP Programming Services. -----snip----- /* */ arg parm spid if parm = "STOP" then signal STOP if parm = "PROCESS" then signal PROCESS "CP TRSOURCE DROP ID ACIPARMS" "CP TRSOURCE ID ACIPARMS TYPE DATA LOC HCPRPIRA + 8 C0C0FFFF" "CP TRSOURCE ID ACIPARMS DL G1.100" "CP TRSAVE ID ACIPARMS TO *" "CP TRSOURCE ENABLE ID ACIPARMS" exit STOP: "CP TRSOURCE DISABLE ID ACIPARMS" "PIPE CP QUERY TRF *", "| TAKE LAST 1", "| spec w2", "| var spid" PROCESS: address command "ERASE ACIPARMS TRACE A" "TRACERED" spid+0 "CMS ACIPARMS TRACE A (FORMAT ALL" ---snip---- Alan Altmark z/VM Development IBM Endicott
