IMPORT/CLOSE issues?

[Fairlight]

Found a weird problem with a client's code today.  They're going through
multiple records with selection sets and importing data into records in
another table.  The filename is in common here, but it's kind of
irrelevant.

What was happening was that they'd get through parsing the first file,
and it would finish, move to the second, and get caught in an infinite
loop on import.  Each file import was done while standing on a new record.
Relevant code fragments:

loop:::
::gosub getline:
:aa eq "":goto loop:
:aa co "Billing Address^A":goto loop:
[more along this vein...skipping lines until they get what they need.]
:aa co "DCN^A":DCN=mid(aa,"5","11"):
:aa co "DCN^A":PROVIDER=mid(aa,"5","3");goto loop:
:aa co "Error Message^A":debug on:
:aa co "Error Message^A":ERROR=mid(aa,"16","400"):
:aa co "Error Message^A":gosub newrec;end:

The newrec routine just does a free lookup on another table and stores a
record.  Worked fine all along.

The getline routine was this:

getline::import ascii ref=(FILENAME) r=\n f=\n:
:not ref:return:
::aa(400,*)=ref(1):
::return:

Now...this is where I figured it was a bit whacked.  There are two possible
solutions to this logically: 

1) IMPORT should be opening each time, since it's being called, and the
data returned should never be anything other than the first line of the
file.  This was not the case, as I've been assured that this method has
worked for years, and the whole file -was- being parsed.

2) That said, IMPORT -must- be being ignored after the first
incarnation--even once processing has ended, we've moved onto a new record,
and FILENAME as a variable has had its contents altered.  This would give
us all lines in the file, but when the next record and import is attempted,
it's still being ignored, as the "ref" alias is still open.  Basically,
it keeps giving you either the last line or an empty string (I don't know
which since I was told the files all ended in blank lines) at EOF from the
first file.  IMPORT even ignores the fact that the data source upon which
it is working has changed.

My solution given deduction #2 was to add a "CLOSE ref" at the appropriate
spot after writing the new record and before the end, and pray that it
would notice the alias was not attached to anything any longer.  We did
that, and things did indeed work correctly henceforth.

Now -my- question (having already determined what the problem was and
having fixed it) is this:

1) Why does IMPORT not re-execute -every- time it is called?

2) Why does IMPORT at least not re-execute if the data source has changed
since its last invocation on the same alias?

3) Has it -always- worked this way?  Is this even the intended behaviour?
Prior to seeing this code, I believed you had to step through a file with
different subscripts to get each successive line.  I had no idea you could
re-import and just keep pulling line 1 time after time and have it be the
next successive line in the file.

Intentional or bug?

My own $0.02:  This is totally unconventional behaviour as regards file I/O
in pretty much any language, gives you no sane way to detect EOF unless
there's something in the file you know will be the last item you need to
look for (there thankfully is in this case), and is entirely contrary to
what one would expect from the code as written.  I mean, what happens if
you do a lookup on the same label as one that previously succeeded?  It
doesn't just ignore LOOKUP because there's a lookup open on that label, to
the best of my recollection.  (Does it?)  IMPORT apparently does.  This
makes zero sense -especially- if the data source changed.

UNLESS it's intended behaviour and has always been that way on purpose
for some obscure reason.  Wouldn't be the first time.  In which case I'd
question the sanity of the design spec.  Personally, I'd have used raw file
I/O functions, but I didn't write the code.

Point is, IMPORT is definitely behaving in a way I would never have
anticipated.  The fix is logical given the behaviour exhibited--but the
behaviour exhibited is something I'd never have thought would work.  I'd
have put money on always getting line one of the same file if it worked
like I expected it to.  I'd have lost, apparently.  :)

Chalk one up for my "always close an alias wherever you can and it does no
harm not to" philosophy.  In this case, it's the difference between working
and not working.

Not really a rant or even a good grouse.  Just kind of a surised, "Why is
it doing it -that- way?" sort of question, along with the solution for
anyone attempting to use it this way.

mark->
-- 
Fairlight->   ||| "Thank you, logic boy. Did I       | Fairlight Consulting
  __/\__      ||| mention this is a rant? Sense      |
 <__<>__>     ||| really has no place in it." --     | http://www.fairlite.com
    \/        ||| Buffy                              | info at fairlite.com