tip about a problem you can run into with readline() - and a workaround

[John Esak]

Hi,

We just had two instances where readline() didn't work properly. Ken says he
has seen this behavior on some systems only, and I know for a fact that it
doesn't happen on most of the systems on which I work. The problem occurred
today on a 2008 server running 5.6.6.

There are a couple variations of the symptom.  Either you get the dreaded
Windows Exception Error, or you simply get a failed readline() of a
correctly opened file. In other words you open a file, get a good handle and
the first readline() you try fails.... either nicely or badly. :-)

Here is the code and the workaround.

then: declare h_o(8,.0), h_rl(5,.0)
then: h_o=open("\temp\dir\filename",line)

The file you open can be in a variable instead of a literal, same problem.
To avoid the problem all you have to do is *specify* the number of
characters to fill into your destination variable, in this case the declared
variable line. Like this:

then readline(h_o,line,"2048")

The docs say this parameter is optional, but to be sure to avoid this
problem, always fill it.

Make the value large like "2048".  It just has to be larger then the number
of characters you might ever expect to see on any line including the newline
at the end.  If you specify a number too small, like say "80"... and there
are 126 characters along one of the lines in the file, you would fill the
variable with 80 characters and your pointer would be waiting there at
position 81 for the next thing to do.  This is usually not what you want
with the readline() command, you usually want the entire line up to the
newline... leaving the file pointer at the beginning of the next line to do
it all again should you want the next row of characters.

So anyway, that's it. Caused a lot of hassle not knowing why we were blowing
up.  I've sent this to ken and support, so hopefully, a more succinct
warning will be put into the docs.

I, myself, have always put a large number as the 3rd parameter in
readline()... was just lazy this time because I knew all the lines would be
fairly short. I've always put a "2048" to avoid the scenario described in
the above paragraph. So if you see the "2048" in all of my accounting and
even the training chapter on readline() in the Survivor Tutuorials, you'll
know why it's there now.

However, now that we know you can actually experience a breakdown if you
don't have such a large number, why invite trouble.  Rmember, you might not
be seeing anything wrong on your own development system.  But what if your
program gets used elsewhere like happened to me last night and today  where
it does blow up.

I don't think it is O/S related.  In other words it may not have been the
fact that it happened on a 2008 Server system this time... it may be
something in the environment, the version of the kernel, what other stuff is
running at the time, who knows?  So, be safe, use this tip.

Take care,

John Esak


John Esak
21st Century Appraisals, Inc
1801 Oberlin Rd, Middletown, PA 17057
717-985-0200 x 1141
john.esak at 21appr.com