Memo magic is really distressing filepro user

[John Esak]

<top posted>
Funny thing... just last week, we were bitten by this precise thing. There
is a table that has been working just fine for years... (two at least). Last
month we were getting notices that some of our EDI was not right... Our send
files looked perfect... the ones they received were missing the last one,
two or three of the exported lines. (plain csv file). This was VERY bad and
I had no idea what was wrong until I looked at my code. I was doing the
export all record by recrod. At @done, I ftp'd the file just created out to
the customer. It has always worked.  When the problem cropped up, I added a
"CLOSE exportname" as the first line of the @done... and 'lo and behold all
the problems wetn away.

Now, this is not a bug either... since why should a close be issued when
things aren't still finished. HOWEVER, the funny, ironic thing about this...
is I had just (like 3 months ago complained to Ken... and I hope followed
with a memo to support) that after doing an export to a .csv file... (going
to be used as an Excel spreadsheet), when I got to @done I wanted to add
some "totals" to a last line in the file. Process kept aborting saying that
the export filename was not available. So, it had apparently been closed
befor @done.  Ken agreed that this file should not be "implicitly" closed
just because there are no more records to process... and should be available
in @done.

Sooooooo, why should I *need* that WRITE as the first line of @done to fix
my problem????????

It must be that the CLOSE gets issued but does not fully happen before my
SYSTEM ftp grabs the file and begins sending it. Of course, there's yonks of
time between the processing the last record on file and the @done (first
line of which is system call to ftp the file...)  isn't there. I think the
file either gets CLOSED or not based on how busy/active our system is, so
some times during very inactive periods, the ftp finishes connecting and
begins transmitting the file BEFORE the last lines are written to the
exportfile and it is closed. (It goes against the filename not being
available in @done though...)

In any case, the "CLOSE exportname" as the first line of the @done works...
so the process never sends any "short" files anymore.

John



> -----Original Message-----
> From: filepro-list-bounces+john=valar.com at lists.celestial.com
> [mailto:filepro-list-bounces+john=valar.com at lists.celestial.com]On
> Behalf Of Fairlight
> Sent: Friday, August 04, 2006 4:22 PM
> To: 'Fplist (E-mail)'
> Subject: Re: Memo magic is really distressing filepro user
>
>
> When asked his whereabouts on Fri, Aug 04, 2006 at 03:07:11PM -0400,
> GCC Consulting took the fifth, drank it, and then slurred:
> > I have found that ANY data entry, to the current record/file,
> done at @key
> > will not hold unless a write is executed just before the END.
>
> I'm just so paranoid about implicit behaviours that don't that I do
> explicit write/close everywhere I can.  It may or may not be
> redundant, but
> I at least know that I'm covered within my own code.
>
> Ran into a problem fairly recently with someone having issues with EXPORT,
> actually.  They had issues with data "dropout" where it wasn't all showing
> up in the file, with most of the end just vanishing for no
> apparent reason.
> (It became apparent to -me- that the fd was never getting flushed.)
>
> It was a case of having no CLOSE in place; fixing the problem involved
> inserting one CLOSE statement.  I don't even know if it's intentionally
> meant to be this way or if it's a bug, but the reality did not mesh with
> their expectations of auto-closing, as it became.  And if it's
> intentional,
> then it's a 180 spin from many other places where it's expected
> and "known"
> that it will auto-close.
>
> It honestly seems safer for people to just make sure one always calls
> it explicitly.  I'm like that with other languages, as well--it's not a
> specific criticism of filePro.  You don't technically need curly braces
> in most variable uses of rvalues in perl, either--but I always use them
> because it's a uniform coding style that means I'm dressed for any
> occasion.  For that matter, I don't even trust perl to auto-flush its fd's
> before an implicit close of an fd on program exit--and it's
> documented that
> it's trustable.  I just don't leave it to chance.
>
> Some feel it clutters code (both in fP and perl, and even in other
> languages) to have things there that aren't theoretically supposed to be
> necessary.  I feel it helps clarity and avoids unwanted and unintentional
> bugs when you standardise on the long form of doing something with the
> least amount of ambiguity possible.
>
> mark->
> _______________________________________________
> Filepro-list mailing list
> Filepro-list at lists.celestial.com
> http://mailman.celestial.com/mailman/listinfo/filepro-list