<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META content="text/html; charset=us-ascii" http-equiv=Content-Type>
<META name=GENERATOR content="MSHTML 8.00.6001.18876"></HEAD>
<BODY>
<DIV dir=ltr align=left><SPAN class=296085301-04022010><FONT color=#0000ff
size=2 face=Arial>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. </FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=296085301-04022010><FONT size=2
face=Arial></FONT></SPAN> </DIV>
<DIV dir=ltr align=left><SPAN class=296085301-04022010><FONT size=2
face=Arial>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...."
</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=296085301-04022010><FONT size=2
face=Arial></FONT></SPAN> </DIV>
<DIV dir=ltr align=left><SPAN class=296085301-04022010><FONT size=2
face=Arial>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.</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=296085301-04022010><FONT size=2
face=Arial></FONT></SPAN> </DIV>
<DIV dir=ltr align=left><SPAN class=296085301-04022010><FONT size=2
face=Arial> then: aa(8,.0)="999"</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=296085301-04022010><FONT size=2
face=Arial> then: aa=SYSTEM("/appl/fp/dreport filename -fp
proc -sr 1 -u")</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=296085301-04022010><FONT size=2
face=Arial></FONT></SPAN> </DIV>
<DIV dir=ltr align=left><SPAN class=296085301-04022010><FONT size=2
face=Arial>If aa returns "0", the SYSTEM command functioned properly. If
not, you're probably left with a lockfile... so the next dreport will
fail.</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=296085301-04022010><FONT size=2
face=Arial></FONT></SPAN> </DIV>
<DIV dir=ltr align=left><SPAN class=296085301-04022010><FONT size=2
face=Arial>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.</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=296085301-04022010><FONT size=2
face=Arial></FONT></SPAN> </DIV>
<DIV dir=ltr align=left><SPAN class=296085301-04022010><FONT size=2
face=Arial>Good luck,</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=296085301-04022010><FONT size=2
face=Arial></FONT></SPAN> </DIV>
<DIV dir=ltr align=left><SPAN class=296085301-04022010><FONT size=2
face=Arial>John</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=296085301-04022010></SPAN> </DIV><BR>
<BLOCKQUOTE
style="BORDER-LEFT: #0000ff 2px solid; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; MARGIN-RIGHT: 0px">
<DIV dir=ltr lang=en-us class=OutlookMessageHeader align=left>
<HR tabIndex=-1>
<FONT size=2 face=Tahoma><B>From:</B> Tyler [mailto:tyler.style@gmail.com]
<BR><B>Sent:</B> Wednesday, February 03, 2010 6:27 PM<BR><B>To:</B>
john@valar.com<BR><B>Cc:</B>
filepro-list@lists.celestial.com<BR><B>Subject:</B> Re: rreport gagging on
lockfile<BR></FONT><BR></DIV>
<DIV></DIV>Well, spoke too soon. The problem recurred just now.
Here is the error message:<BR><BR><BR><BR>*** A filePro Error Has Occurred
***<BR><BR>On File:
/hd1/hd1/appl/filepro/log_operations/lockfile<BR><BR>Request Output with
Processing Function Running On This File<BR><BR>File not
available.<BR>Somebody else is modifying the file; try again
later.<BR><BR><BR><BR>Deleting the lockfile allowed things to go forward
smoothly. Does this provide anyone with any fresh
insights?<BR><BR>Tyler<BR></BLOCKQUOTE></BODY></HTML>