readline() strangeness on 4.8.10D4

[GCC Consulting]

> -----Original Message-----
> From: filepro-list-bounces+gccconsulting=comcast.net at lists.celestial.com
>
[mailto:filepro-list-bounces+gccconsulting=comcast.net at lists.celestial.com]
On
> Behalf Of Roger Cornelius
> Sent: Wednesday, December 17, 2008 3:00 PM
> To: Kenneth Brody
> Cc: filepro-list at lists.celestial.com
> Subject: Re: readline() strangeness on 4.8.10D4
> 
> On 12/16/2008 23:29, Kenneth Brody wrote:
> > Quoting Roger Cornelius (Tue, 16 Dec 2008 17:30:43 -0500):
> >
> >> Filepro 4.8.10D4 on SCO OSR507
> >>
> >> I'm seeing strange behaviour from readline(), which I haven't had a
need
> >> to use before now.  Or maybe it's len() or call processing or the
> >> debugger that's the problem.
> >>
> >> - I'm using a called table via "call noauto"
> >> - In auto processing I have field kz(12,*)
> >> - In called table I have field kz(64,*)
> > [...]
> > ... readline() works, but len(kz) and the debugger show 12 characters
...
> > [...]
> >
> > Sounds like an issue with len() and the debugger, as readline() is
> > returning the proper 64 characters.
> >
> > [...]
> >> And also:
> >>
> >> - readline() doesn't like it when it's arguments are variables with
long
> >>   names.  At least I get a syntax error when I try to save the table.
> >>   writeline() seems to work fine with long name variables.
> >>
> >> Since we're on an old fp version, can I assume these issues have
already
> >> been reported and fixed?  If so, in what version?
> >
> > As noted in the 4.8.12 readme:
> >
> > All
> >     READ()/READLINE() now accept long-named variables as the second
> >     parameter.
> >
> >> Am I going to have problems reusing vars which exist in auto processing
> >> even though I'm using "call noauto"?
> >
> > Define "problems".
> >
> > By using CALL NOAUTO, you are telling filePro that the CALLed table is
> > to not share the dummy fields which may be defined in auto processing.
> > In this case, the CALLed table's "kz" field is local to that table, and
> > not the one already defined in auto, which would have happened with a
> > "normal" CALL.  The same holds true for all other dummy fields.
> 
> By "problems", I mean could vars used in both auto and called processing
> stomp on each other even though I'm using "call noauto"?  This, given
> the fact that the debug mode "F" command, from the called table, shows
> the length and value of the field as defined in auto processing and not
> called processing.  If there's a bug that allows debug mode to see the
> auto processing version of the var, what's to say the bug doesn't also
> allow other areas of processing to see the auto version of the var?
> 
> To put it another way, if we know the "auto processing vars not visible
> in call noauto processing" concept is broken in debug mode, how can we
> know if it's not also broken in other areas?
> 
> Does that make sense?
> --
> Roger Cornelius            rac at custom-mobility.com

I'm getting in here a bit late.  But, once the auto processing table has
run, any variables set there are set.  Defining variables either in the
current table (input.prc) or in a called table will be in conflict what is
defined in the auto processing table.

In fact, when does a syntax check on a table, it will tell you if the
variable has already been defined in the auto processing table.

Is there any logical reason for using the same variable kz in both tables?


Richard Kreiss
GCC Consulting
rkreiss at gccconsulting.net