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