invalid argument system runtime error on line with variable lookup

[Bruce Easton]

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.