Robert S. Hansel kindly responded with a number of questions; I'll answer the few that I can. The rest I'll see if the customer can try.
>What is the name of the CADB2 product's class and what is the POSIT that it is using? It seemed to be named CADB2 and was POSIT 130. >Is the CDT class RACLISTed? If yes, is it possible they defined the CADB2 class CDT class profile on a system other than the one where you encountered the problem and neglected to execute a SETR RACLIST(CDT) REFRESH on all systems sharing the RACF database? Yesterday the customer ran LISTCDT and POSIT 130 is not in use! CADB2 shows as using POSIT 0441. Which isn't even 130 hex L Customer also tried defining a new class as 130, then changing it to NOGENERIC, which is what triggered the message before; no message. So whatever was happening was transient, or fixed by something else (perhaps the REFRESH you suggest above). I fear this will remain a mystery. However, I think the "define it and swap GENERIC/NOGENERIC" is still perhaps a worthwhile test to see if a POSIT is truly free, in the absence of other tools (or if the symptoms fit "not unique" but the tools insist it is, as seems to have been the case here). Before someone says it: if three of us hadn't seen this happen (me, the customer, and one of the kind folks from Vanguard), I wouldn't believe it. But we all said "AHA!" and swapped POSIT numbers and went onward with the problem at hand. In retrospect, I think we all wish we'd taken the time then to figure out just what was really going on. C'est la vie. .phsiii ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
