<!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.&nbsp; 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.&nbsp; </FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=296085301-04022010><FONT size=2 
face=Arial></FONT></SPAN>&nbsp;</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.&nbsp; 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.&nbsp; Is it in a loop or is it dropping record to record?&nbsp; 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>&nbsp;</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.&nbsp; That 
way you can test it's exit value.&nbsp; 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.&nbsp; 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.&nbsp; 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>&nbsp;</DIV>
<DIV dir=ltr align=left><SPAN class=296085301-04022010><FONT size=2 
face=Arial>&nbsp;&nbsp; then: aa(8,.0)="999"</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=296085301-04022010><FONT size=2 
face=Arial>&nbsp;&nbsp; then:&nbsp; 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>&nbsp;</DIV>
<DIV dir=ltr align=left><SPAN class=296085301-04022010><FONT size=2 
face=Arial>If aa returns "0", the SYSTEM command functioned properly.&nbsp; 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>&nbsp;</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.&nbsp; This is 
much more complicated, in opening the file, filling a buffer, testing the right 
offset, etc.&nbsp; 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>&nbsp;</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>&nbsp;</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>&nbsp;</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.&nbsp; The problem recurred just now.&nbsp; 
  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;&nbsp; try again 
  later.<BR><BR><BR><BR>Deleting the lockfile allowed things to go forward 
  smoothly.&nbsp; Does this provide anyone with any fresh 
  insights?<BR><BR>Tyler<BR></BLOCKQUOTE></BODY></HTML>