rreport gagging on lockfile
John Esak
john at valar.com
Wed Feb 3 09:44:13 PST 2010
Omly have a minute... noticed this..
or from a SYSTEM call in processing that looks pretty much the same
m="file=invhead2;processing=postFedex;"
m=m{"qualifier="{@QU{";script=none;user="{@ID{";"
m=m{"note=none;status=STARTED"
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.
But, maybe you just typed thsi in by hand and didn't cut and paste it from
the working stuff. Actually, I think a -r with something pushed right up
against it would give a syntax error, so this must just be a typo.
As for the -u stuff... If you run a [dr]report without the -u on the command
line, then no, a [dr]clerk should not be allowed access to that file. That
is specifically what the filePro lockfile is supposed to do. The -u tells
the report to ignore the filePro lockfile.
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.
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. :-)
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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.celestial.com/pipermail/filepro-list/attachments/20100203/f913f119/attachment.html
More information about the Filepro-list
mailing list