Re: MCH1210 - Receiver value too small to hold result.

Hi Rob,

I haven't manually null-terminated a string for the IFS APIs in 16 years.

In V3R7, IBM added a feature to RPG called options(*string) -- it's a keyword that you place on the prototype, and it tells RPG to automatically add a x'00' (null) to the parameter when you pass it.

So, this options(*string) feature is what null-terminates the string -- not the VARYING keyword. What VARYING does is prevent RPG from padding the string up to it's maximum length with blanks.

The blanks are the problem. By IFS rules, a path named 'foo ' (with a blank at the end) is a separate pathname from one named 'foo' (with no blanks at the end.) Both are legitimate pathnames, and they are different from one another.

So when you have a variable that's 5000 long, and you assign 'foo' to it, RPG puts the letters f,o,o in the first 3 positions of the string, and fills the remaining 4997 positions with blanks. When you pass that to opendir(), it's trying to open a directory that has 4997 blanks in the name... which, most likely, won't exist, and you'll get back errno=ENOENT.

Your code of thedir = %trim(thedir) + x'00' would cause the name to be null-terminated twice. You'd have 'foo', followed immediately by the x'00' you added by hand, followed by 4996 blanks, followed by the x'00' added by RPG. Since the opendir() API is looking for the _first_ x'00', it'd find the one you added by hand, and ignore the blanks (because it stops reading the pathname when it finds the first x'00'). Like I said before, it seems a bit kludgy, doesn't it?

With VARYING and %trimr() the blanks aren't there. So 'foo' is passed followed immediately by RPG's x'00'.


On 11/21/2012 6:11 AM, rob@xxxxxxxxx wrote:

Are you sure I do not have to null terminate the string? Or is this a
stupid question because if I make it varying, it automatically null
terminates it? I thought I had to use some other attribute to
automatically null terminate the variable.