Path: utzoo!attcan!uunet!decwrl!sdd.hp.com!zaphod.mps.ohio-state.edu!samsung!umich!yale!cmcl2!panix!alexis
From: alexis@panix.uucp (Alexis Rosen)
Newsgroups: comp.databases
Subject: Re: rlock() in SCO foxbase+.
Keywords: foxbase, rlock
Message-ID: <1990Oct2.074159.6149@panix.uucp>
Date: 2 Oct 90 07:41:59 GMT
References: <553@safn2.UUCP> <79@mq.COM> <1990Sep25.234729.5299@mccc.uucp>
Organization: PANIX - Public Access Unix Systems of NY
Lines: 95

I posted an article about six days ago which must not have made it out. Since
lots of other things got lost too, I'll just repost it. Here's the latest from
this thread:

In article <1990Sep25.234729.5299@mccc.uucp> shevett@mccc.edu (Dave Shevett) writes:
>In article <79@mq.COM> alan@mq.COM (Alan H. Mintz) writes:
>=In article <553@safn2.UUCP>, rey@safn2.UUCP (rey) writes:
>=> Set up is SCO Unix 3.2.2 on Compaq 386. SCO Foxbase+.
>=> 
>=> Could some one please explain rlock() in foxbase+. I am converting 
>=> Dbase single user programs.
>=>
>=> I think the answer is a). When I rlock() then call another
>=> 	procedure I cannot append. But that doesn't seem correct design.
>=
>=APPENDs require flock() (which cannot be performed on a file that is rloc()d
>=by another user. Note that you can flock() a file in which YOU have rlocked
>=a record - the flock() simply supercedes the rlock().
>
>Careful here.  The 'append' function standalone requires a flock().
>However, I think 'rey' is running inside a procedure, therefore is 
>probably doing APPEND BLANK.  In this case, the normal sequence is:
>
>Build your screen using memory variables, and READ it.
>append blank
>if rlock()
>	replace etc etc etc etc
>	unlock
>else
>	do error with "Can't lock that sucker"
>endif

Hm. All of these are wrong. The Flock method will work, but it's lazy and
inefficient programming. Here's the original message, which clarifies the
situation. BTW, I believe this features has been around since the baseline
Fox 2.0 release. Also, that 'third type' of lock is the Header Lock, which
is inaccessable to you from foxbase. Append Blank uses that lock.

Any of you guys gonna be in Toledo next week?...

---------------------------------------------------------------------
From alexis Tue Oct  2 03:29:27 EDT 1990


I know it can be confusing, but I'd suggest that you RTFM, two times. briefly:

The *PROGRAM* (which is to say, the pid in unix) owns locks. However, you can't
use rlock to append. It's a really stupid way to do things, but the only way
to append in multi-user is:
1) Obvious but slow- Flock() the file, and if you get the lock, append and
   release.
2) Fast and ugly- just do append blank. If you can't make the record, it'll
   generate an error. Catch the error in your error-handling routine (you do
   have one, right?)  This becomes enormously easier if you encapsulate the
   Append routine. Here's mine, for Fox/Mac, which should work identically:

* DelayAppnd(secs)
* Try up to 'secs' seconds to append a blank record.
* Relies on the error-handling routine to set appenderr to .F. if the
* append fails.  Returns .T. if append succeeded, .F. if not
 
Param secs		&& number of seconds to wait
Priv appenderr		&& semaphore flipped by Error-handler if append fails
Priv t			&& ending time
Priv junk
 
t = Val(Sys(2))+secs
Do While (Val(Sys(2)) <= t)
	appenderr = .F.		&& no error condition yet this pass in loop
	Append Blank		&& give it a shot
	If appenderr		&& if append failed, the error-handler set this
		junk = Inkey(1)	&& wait a second so we don't thrash the DBMS
	Else
		appenderr = !Rlock()	&& We don't get a lock on a record
					&& just by creating it
		Exit
	Endif
Enddo		&& loop for 'secs' seconds or until we achieve a lock
Return !appenderr

-----
Remeber to look for the specific error number for a "failed to append" in
your error-trapping routine.

Also, don't forget to release any lock you create. Generally speaking you
shouldn't hold on to locks for more than a fraction of a second- no reason.

Unlike dBase IV and FoxPro, you can only have ONE lock at a time- I think.
There's some small possibility that the unix version is different.


Hope this helps,
---
Alexis Rosen
cmcl2!panix!alexis