Trimming prototype/interface variables only works with certain lengths

[sps]

I have a program with a Main prototype (and matching pi) containing two char parameters. In my program, I'm ascertaining the "actual" lengths of the input parameters using %len and %trim, like so:

%len(%trim(var1));

I'm testing this by calling it from green screen and passing it params of length 7, for example. Thing is, if the prototype/pi specify these parameters to be of shorter-ish lengths (i.e. char(32)), then it works great: If I I see the length of the input parameter as 7, as expected.

If, however, the prototype specifies something longer like char(50) or char(64), then I get unexpected values. Maybe the length of the param itself un-trimmed (i.e. 50, 64), or sometimes other values like 40 (!?)

Any ideas or explanations for this discrepancy?

[Scott Klement]

Yes, this has always been the case from day 1. The CALL command when used from the command-line ALWAYS defines character fields as CHAR(32) and ALWAYS defines numeric fields as PACKED(15, 5)

Nothing new about this. Its been this way since the AS/400 was originally introduced in 1988.

If you provide a character string that is longer than 32, it will define it to the exact length of the string. For example if you do PARM('XXXXXXX') with 41 X's, then it will define it as CHAR(41).

The solution is to create a *CMD object to call your program so you can define the lengths and data types of the parameters.

[jonboy49]

Scott is correct - but these days there is another option which is to use the ability to define the data type and length of parms on a call. Like so:

CALL PGM(XYZ) PARM(('ABC' (*CHAR 100)))

In this case, the system will pass a 100-character field blank-padded as expected.

[sps]

Ah, thank you both--that makes sense. I appreciate the education!

[sps]

As a follow-up:

I understand that CALL will send a char(32), so if my prototype expects a char(32) (or shorter) and I send a parm that is 7 characters long, then the trim works as expected because my program's receiving a char(32), comprised of my 7 char string and 25 blanks at the end.

If, however, I set my prototype to expect something longer--say, char(50)--but still only provide a string value that is 7 characters long, by default my CALL will still be sending a char(32) (7 chars + 25 blanks), but then some junk values (not necessarily blanks) will be in in the remaining 18 spaces. And that's why the trim won't work, because the blanks are no longer at the right edge.

Am I discerning this properly? The solution to my problem is clear, but I always like to confirm my "under the hood" understanding as best as I can. Many thanks again for the help!

[Scott Klement]

If, however, I set my prototype to expect something longer--say, char(50)--but still only provide a string value that is 7 characters long, by default my CALL will still be sending a char(32) (7 chars + 25 blanks), but then some junk values (not necessarily blanks) will be in in the remaining 18 spaces. And that's why the trim won't work, because the blanks are no longer at the right edge.

A variable that is declared as an entry parameter does not have its own memory assigned to it. Instead, it is given the same memory as the caller.

So if the caller declares the variable as CHAR(32) (Which is what the command-line will do.) but you have coded CHAR(50) in your program, it is trying to use 50 bytes of memory at a space that only has 32 bytes reserved. The remaining 18 bytes will be "whatever happens to be in memory after the 32". It might be blank, or it might be hex zeroes, or it might be another variable that is unrelated.

It is very bad to interact with memory that doesn't belong to your variable. Make sure you don't do this.

If your program is coded with CHAR(50), then make sure the caller always passes at least 50 bytes (if not more). If your program is coded with CHAR(500000) then make sure the caller is coded with at least 500000 bytes (if not more.) Use a *CMD interface instead of calling with the CALL command to control the size of the variable. Or always call from a program and pass a variable instead, where the variable has been declared large enough.

Am I discerning this properly? The solution to my problem is clear, but I always like to confirm my "under the hood" understanding as best as I can. Many thanks again for the help!

hope that helped.

[sps]

hope that helped.

It did. Many thanks!