invalid argument system runtime error on line with variable lookup

[Bruce Easton]

GCC Consulting wrote Thursday, October 25, 2007 10:59 PM:
> 
> > -----Original Message-----
> > From: 
> > filepro-list-bounces+gccconsulting=comcast.net at lists.celestial
> > .com 
> > [mailto:filepro-list-bounces+gccconsulting=comcast.net at lists.c
> > elestial.com] On Behalf Of Bruce Easton
> > Sent: Thursday, October 25, 2007 8:05 PM
> > To: filepro list
> > Subject: RE: invalid argument system runtime error on line 
> > with variable lookup
> > 
> > Mark wrote Thursday, October 25, 2007 7:24 PM:
> > > 
> > > At Thu, Oct 25, 2007 at 05:09:01PM -0400 or thereabouts, 
> > suspect Bruce 
> > > Easton was observed uttering:
> > > > 
> > > > My original post does show that I could have (only) trailing
> > > spaces from:
> > > > 
> > > > filen{"@"{qual
> > > > 
> > > > but I have also tried previously filen{"@"{qual{""
> > > > and that produced no difference (still an error on 5.0.07 Windows 
> > > > and still success on Unix 5.0.14).
> > > 
> > > Yeah, but if the "container" for it has s defined length, won't it 
> > > still pad out with spaces even if the expression uses a push-left 
> > > null?  That's only going to truncate if it's going into an uncast 
> > > dummy or variable, I thought.
> > > 
> > > Is it cast for a length or not?
> > > 
> > > mark->
> > 
> > Well, "filen" and "fileq" are declared as (40,*); qual is 
> > declared as (7,*) but (and I should have included the full 
> > way in which I used that expression) I would assume that for:
> > 
> > lookup readd = (filen{"@"{qual{"")  (as stated above) or, for:
> > lookup readd = (fileq{""), (where fileq is set equal to 
> > filen{"@"{qual) that all trailing spaces would be squished 
> > away from the expression - what I assume filepro sees as the 
> > filename, since the last thing inside the closing parenthesis is {"".
> > 
> > But testing, as I said shows that those two cases behave 
> > exactly the same (failure on 5.0.07 Win and success on Unix 
> > 5.0.14) even if I just use:
> > lookup readd = (filen{"@"{qual) or
> > lookup readd = (fileq)   <--my orig code that works under 
> > Unix 5.0.14, 
> > so clerk must not care about the trailing spaces in an 
> > expression filename.
> > 
> > [I've never used the "&" in the middle parts of the 
> > expression, but I guess some people have had success without 
> > squishing away spaces in the middle according to some of these posts.]
> > 
> > Bruce
> > 
> > Bruce Easton
> > STN, Inc.
> 
> Bruce,
> 
> Filen should be filen(32,*) as this is the max size of a file name.  Qual
> should be qual(7,*)
> 
> The readd = (filen{"@"{qual) or readd(filen&"@"&qual) should work.
> 
> Richard Kreiss

Richard,

qual is (7,*).  Yes, filen would be better at (32,*), but for my 
purposes, it makes little difference.  A user cannot enter info into 
filen - it is only used to provide input to fileq(40,*) which holds 
the filename, "@", and the qualifier, pushing everything over to 
the left.

More importantly,  I was able to test the code on Windows 
fp version 5.0.08 and the problem is *not* happening there, 
so I'm hoping that it works OK on the Windows fp versions 
above 5.0.08 as well.

Bruce

Bruce Easton
STN, Inc.