Bruce:

Thanks, but the _PH_ file is cleaned up every night using the CLEAR.ACCOUNT command (we use a number of 3rd party applications that create _PH_ items throughout the day). When I check out the locks I see it doesn't work as expected...

2 Dev (0)-> LIST.LOCKS
2 Dev (0)-> BPTEST LOCK 60 THEN CRT "Lock 60 set..." ELSE CRT "Cannot access Lock 60..."

Compiling Unibasic: SAVEDLISTS\BpTest_374558121 in mode 'p'.
compilation finished
Lock 60 set...
2 Dev (0)-> LIST.LOCKS
UNO UNBR UID UNAME TTY FILENAME RECORD_ID M TIME DATE 2 3248 197615 wphasket pts/2 semaphore 60 X 10:24:10 Apr 02 2 Dev (0)-> BPTEST LOCK 60 THEN CRT "Lock 60 set..." ELSE CRT "Cannot access Lock 60..."

Compiling Unibasic: SAVEDLISTS\BpTest_374842961 in mode 'p'.
compilation finished
Lock 60 set...
2 Dev (0)->

So, why didn't the program tell me it couldn't access lock 60 the second time I ran it? It seems the semaphone is very fussy about how it's set and who can unset it. It also didn't tell me it was set when I tested it in a BASIC program.

So, this isn't looking like a viable solution after all.  :-(

Bill

------------------------------------------------------------------------
[email protected] said the following on 4/2/2010 10:24 AM:
Is there anyway to use the COMO file (_PH_)? If a Phantom ends or crashes the last line is something like " PHANTOM process <PID> has completed."
What happens when UDT is recycled?  That has never happened to me. :-)


Bruce M Neylon
Health Care Management Group _______________________________________________
U2-Users mailing list
[email protected]
http://listserver.u2ug.org/mailman/listinfo/u2-users
_______________________________________________
U2-Users mailing list
[email protected]
http://listserver.u2ug.org/mailman/listinfo/u2-users

Reply via email to