rreport gagging on lockfile

[John Esak]

No problem, sometimes insights turn into fixes... other times not.
 
About the syntax ...Yes, sorry, on my system, for whatever reason I "saw"
only one set of quotes after the -r... now I can tell there is an apostrophe
first and then the quotes.  My mail showed this to me with straight up and
down quote/apostrophe marks (i.e., not "smart" curly quotes). Jim Asman told
me his system showed him the apostrophe clearly curling to the left and then
the quotes.  Either way, I have my screen reader set to ignore most
punctuation, so it was up to me to try and "see" it... and like I say, even
at 30 times magnification, the apostrophe and quotes next to each other are
almost impossible to discern. It's either apostrophe quote or quote
apostrophe, and it would be anyone's guess.  Maybe I'll turn on the smart
quoting again.  I forget why I turned that stupid feature off in the first
place.
 
 
I vote with your colleague 
 
rm -f ${PFDIR}/filepro/filename/lockf*
 
at the head of your script and you will never see this problem again.  On to
more agonizing problems.
 
John
 
 
 
 
  _____  

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



On Wed, Feb 3, 2010 at 10:44 AM, John Esak <john at valar.com> wrote:


Omly have a minute... noticed this..



system "/appl/fp/rreport log_operations -fp log_it -sr 1 -r '"{m{"'"
 
^
this needs to be a < or an & if there is a space before the quotes.

No, it's just hard to see what's going on there.  There isn't a space needed
there - there's a single quote in front of the double quotes after -r and a
single quote between those doublequotes at the end, for generating a string
for the command line.  (eg) "-r '"{m{"'" ====> -r 'file=invhead2...etc' 



Lastly, did you happen to get a look at the size of the lockfile before I
suggested removing it?  If it was 64, then perhaps it was corrupted in some
strange way.  If it was the larger new size, than this goes back to the
mismatch betwee 5.6 and previous versions... but as you said there is no 5.6
on this system in question.  For the 64 bit lockfile to be corrupted... I
don't really know what I'm suggesting.  Meaning if it were corrupted in some
way, it wouldn't allow you access with anything, clerk, report, dxmaint, and
so on.  It sounds like you were having trouble with just this one routine.  

No, I didn't see the size.  My coworker says she noticed nothing odd about
it.  And it was indeed with just this one routine, but that's not surprising
- it's the only processing for the file at all anywhere. 


I kind of hate just having things fix thmeselves without ever knowing what
was wrong or what fixed it... so, if the problem rears its ugly head again,
bring it up.  We know what made the problem go away in this case, that is
not the same as what "fixed" it. :-(  Of course, if you really want a
headache free runtime of this routine, just put a hard-coded "rm" of the
lockf* files in the culprit directory and it seems you'll be fine.  Still, a
tiny nagging would bother me forever about having to do this. :-)

I agree 100%  That's why I still posted even after deleting the lockfile
worked out; I'd much rather fix the actual problem than band aid and forget
it!!!  My coworker wants to go the rm route, but I am trying to beat that
out of her head :) 


 
John
 
P.S. I didn't look through the whole launching stuff... ut it's good you got
it together, maybe it will become useful if the problem crops up again.


I'm certain that the code has no bearing on the problem - it has to be
environmental.  But it's there for those who care :)

Thanks for the insights, John.

Tyler


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