rreport gagging on lockfile

[John Esak]

1. Okay, be more specific. You say you are using the lockinfo script.  So,
you can see exactly which record is being locked by exactly which binary.
What does it show?  Record 1 by dclerk, or record 1 by dreport.... exactly
what does lockinfo show.... by any chance are you locking record 0?  Not
something you could do specificially, but filePro does this from time to
time.
 
2. It's always easier when people say this has worked for years.  So, it
must be something new added to the soup.  Have you removed an index, grown a
field and not changed the size an index pointing to it.  Gone past some
imposed time barrier?  Used up too many licenses? Exceeded some quota in
some parameter?  Added groups or changed permissions?  Run a fixmog (fix
permissions)?  Has a binary failed like dclerk and you've replaced it with a
different copy?   Has the -u flag any immpact on your scenario?  I'm
assuming a lot because you haven't specifically shown how you are doing
things?  Is this happening from a system call?
 
I agree that the code would not seem to be importatn since it has worked...
before, so again, it seems like the environment has changed somehow.  Maybe
if we saw the whole setup, relevant code and all we could give more
suggestions.  Oh, I just thought of one... is it possible you are looking up
to a particular record, say record 1... and that record is not there
anymore?
 
I don't know, I'm shooting in the dark without the specifics.
 
John


  _____  

From: filepro-list-bounces+john=valar.com at lists.celestial.com
[mailto:filepro-list-bounces+john=valar.com at lists.celestial.com] On Behalf
Of Tyler
Sent: Monday, February 01, 2010 3:18 PM
To: filepro-list at lists.celestial.com
Subject: re: rreport gagging on lockfile


On Mon, Feb 1, 2010 at 1:13 PM, Rkreiss at verizon.net] <rkreiss at verizon.net>
wrote:


Is your processing using one record?  Is so, could that record be locked?

Richard Kreiss



Yes, it's using one record, but that is definitely not the problem - we've
been doing it this way for years.  

And as I stated in my original email, the file/record isn't actually locked
if you look at the lockfile itself or use the lockinfo script - filePro just
seems to think it is regardless.  

Also, if that was the case then after deleting the lockfile and re-running
the processing we should be getting the same lock error message; we are not.

Tyler




 



-----Original Message-----
From: Tyler <tyler.style at gmail.com>
Sent: Monday, February 01, 2010 1:47 PM
To: filepro-list at lists.celestial.com
Subject: rreport gagging on lockfile

We suddenly started having a problem a week ago with a piece of logging
software that has run perfectly for years.  Every time a script or
processing ran that used it, it would bomb out with a message that the file
was locked by output processing.

After some hemming and hawing, it was determined that the lockfile status
wasn't being read correctly. rreport was hung on the lockfile message, and
trying to access it via rclerk kicked you immediately with the same
message.  However, the lockfile script showed that the file wasn't actually
locked.

We manually deleted the lockfile and re-ran a report that had been
previously gagging so that filepro (v5.0.1.14 on SCO Openserver 6) could
recreate it.  Suddenly everything is fine.

Anyone have any ideas on why this would have happened, and how we might
avoid it in the future?  Thanks for any input!

Tyler





-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.celestial.com/pipermail/filepro-list/attachments/20100201/5800cda8/attachment.html