rreport gagging on lockfile

[John Esak]

Boy, it's so frustrating.  It certainly sounds like you are running two (or
more) synchronous reports.... I'm wondering if the first occurrence of the
report (the -fp on the command line) is conflicting with the one called from
SYSTEM... but you say this has worked for forever... so I am at a loss for
any more insights.  
 
But, you do give one clue... that is that removing the lockfile allowed
things to progress smoothly. I'm assuming that *while* the error was on the
screen... you went and removed the lockfile... then you hit enter on the
error message.  If that's true than the problem is from one of the running
SYSTEM calls... and then with the lockfile gone, the *next* occurrence of
the SYSTEM call.  Is it in a loop or is it dropping record to record?  I'm
guessing it's in a loop because you are running -sr 1. So you hang on record
1, run through a loop that repeatedly calls the SYSTEM "report...." 
 
Again, I can suggest something that might have helped someone else a week or
so ago. Try running that SYSTEM "report .." as a function.  That way you can
test it's exit value.  So, you could increment a counter for each iteration
of the SYSTEM "report" and determine on which iteration it does not finish
properly. If it finishes properly that means it removed the byte flip on the
lockfile.  When you get a return value that says the SYSTEM "report" did not
exit successfully, that will be the time it *lleft* the lockfile in a bad
state.  Maybe it's the second iteration, maybe the first, maybe the 19th.
The information is valuable in diagnosing this thing, and it alleviates a
little bit the idea of putting a "debug on" just before the SYSTEM "report"
and checking everything yourself each time.
 
   then: aa(8,.0)="999"
   then:  aa=SYSTEM("/appl/fp/dreport filename -fp proc -sr 1 -u")
 
If aa returns "0", the SYSTEM command functioned properly.  If not, you're
probably left with a lockfile... so the next dreport will fail.
 
You could also just put a check after the SYSTEM "report" for the actual bit
in the lockfile that represents *report doing a lock.  This is much more
complicated, in opening the file, filling a buffer, testing the right
offset, etc.  I'd try the simple exit sttatus first.
 
Good luck,
 
John
 


  _____  

From: Tyler [mailto:tyler.style at gmail.com] 
Sent: Wednesday, February 03, 2010 6:27 PM
To: john at valar.com
Cc: filepro-list at lists.celestial.com
Subject: Re: rreport gagging on lockfile


Well, spoke too soon.  The problem recurred just now.  Here is the error
message:



*** A filePro Error Has Occurred ***

On File: /hd1/hd1/appl/filepro/log_operations/lockfile

Request Output with Processing Function Running On This File

File not available.
Somebody else is modifying the file;  try again later.



Deleting the lockfile allowed things to go forward smoothly.  Does this
provide anyone with any fresh insights?

Tyler


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.celestial.com/pipermail/filepro-list/attachments/20100203/34876592/attachment-0001.html