lockfile not getting cleared

[Don Coleman]

> -----Original Message-----
> From: filepro-list-bounces+dcoleman=dgcreact.com at lists.celestial.com
> [mailto:filepro-list-bounces+dcoleman=dgcreact.com at lists.celestial.com] On
> Behalf Of Nancy Palmquist
> Sent: Thursday, June 28, 2007 1:40 PM
> To: Boaz Bezborodko
> Cc: filepro-list at lists.celestial.com
> Subject: Re: lockfile not getting cleared
> 
> Boaz Bezborodko wrote:
> > I have a bunch of older programs that don't seem to be clearing the
> > lockfile when they exit.  The original programmer on these programs
> > (they may have been written in 3.0 or 4.1) avoided the problems by
> > running batch files that deleted the lockfile before running.  I would
> > like to remove these.  But if I do then FP gives an error that someone
> > is updating the file.  The thing is t even though no one is in there and
> > none of the files are open.
> >
> > How can I clean this up?
> >
> > Boaz
> >
> Boaz,
> 
> I expect you need to make sure that all the users exit the programs
> correctly, there are no filepro errors and they do not hit <BREAK> after
> they start reports, and the system does not disconnect users unexpectedly.
> 
> Lockfiles are the product of those issues.  The processing controls
> RECORD LOCKS, but the use of the files really controls LOCKFILES.  If
> you address those items and they still occur, it should be unusual.
> 
> I add BREAK OFF to processes to insure they must get to a certain place
> before they can leave.
> 
> I add the following stuff after any scan processing, input questions to
> give uses a valid exit.
> 
> then: input popup date "ENTER DATE TO SELECT: (mm/dd/yy) > " default @td
> if: @sk eq "BRKY"
> then: exit
> 
> The INPUT by default does not accept the break key and the environment
> variable for allowing this should be eliminated.
> 
> Usually this is related to the user exiting using the close on the
> window instead of properly leaving filepro.  I would think they would
> have complained about filepro errors.  But BREAK after starting a report
> was also a big offender.
> 
> Good luck.
> 
> Nancy
> PS.  I had one system where a user found out about CTRL \ (UNIX SYSTEM)
> and used it often.  We turned it off, when we finally tracked down what
> was causing it.  I always turn it off, on a live system nowadays.
> PFQUIT, I think is it.
> 
> 
> --
> Nancy Palmquist 		MOS & filePro Training Available
> Virtual Software Systems	Web Based Training and Consulting
> PHONE: (412) 835-9417		   Web site:  http://www.vss3.com
> _______________________________________________
> Filepro-list mailing list
> Filepro-list at lists.celestial.com
> http://mailman.celestial.com/mailman/listinfo/filepro-list

Not sure if this is a Windows version of filepro Boaz is discussing but does
anyone know if something can be set within the filepro startup script
environment that "turns off" or disables clicking on the "X" in the top
right corner of the Windows screen.  I know this is a Windows issue, not a
filePro issue but it would be a handy thing to know.  If a process really
does lock or loop the user could still use Task Manager to close the fP
application if needed.



Don Coleman
Donald G. Coleman, Consultant
402 Andrew Circle
Indiana, PA 15701
dcoleman at dgcreact.com
(724) 349-6302