scottklement.com

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?

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.

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.

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

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!