Article 4749 of vmsnet.internals: "Ferguson@uvii.mag.aramark.com" writes >I have a 5 year old program that has recently begin failing. It goes >through >the lock database and identifies RMS record locks and reports them, and >for >specific files of interest reads the locked record and shows the user >(e.g. >tells them who is locking which customer). >Recently it has begun to hang on certain VAX systems (it runs on about >18 VAX >and 2 Alphas as a user-invoked utility). It hangs in a RWMBX state. >The program uses $CMEXEC to call $GETLKIW, and uses (in user mode) RMS >directly for reading the files. There's a $GETJPIW in there for getting >username and such from processes it reports. It does not spawn or create >other >processes, and does no inter-process communication on its own (other >than >implied in $GETJPIW). It creates no mailboxes explicitly, and while >hung a >SHOW PROC/CHAN in SDA shows no MBA devices (and shows nothing busy). >They will unhang eventually, usually after hours. They can be killed >with >STOP/ID. The problem is intermitent, but completely reproducable when >it >happens (i.e. it seems related to system load or some resource). >While hung there is plenty of buffered io and byte count. R5 does not >appear >to point to a UCB (at least it won't format as one). >DEC thinks I'm doing a mailbox create somewhere and have forgotten (ok, >years >go by and we all get senile, but I do not think so). I'm hoping someone >has >other suggestions where to look. What else can cause a RWMBX, >specificially >surrounding these kinds of service calls? And with no MBx shown in SDA >and R5 >not pointing at a UCB, how can I find what is stalling it? >Oh... VMS 6.1 on a 3100-95 and 3100-90, both fairly busy but otherwise >stable >systems. Program is in DEC C (and though I see no connection, this >started >about 6 months after converting from VAX C). And very rare, like only 3 >days >out of the last 3 months. Do you have an opcom and Audit_server process or are these sattelites without an opcom process. If you do have opcom and audit_server do they look OK. The security auditing code writes to mba2 (opcoms mailbox) even if you do not have an opcom process. Check the pc by doing an an/sy and then set process to a process in rwmbx then ex/i @pc-20;20 look at the addresses. If P0 then your code, if System, then check the label by doing a read/exec then the @pc-20;20 again. If you have listings then check the maps, if not call DEC again and tell them which system loadable image and offset it is in and have them do it. Jim Mehlhop The PARSEC Group mehlhop@parsec.com 888-4parsec