Your final statement "Like 33?" is telling. Can you supply an exact example of how the parameter is created and used on the CALL statement? If the CALL happens at a command line or the parameter is a CL literal value or any of a number of possibilities, you'll run into possible problems. By default, every *CHAR parameter passed from CL has a minimum 32 character length. Up to 32 is always padded with blanks even if you only pass a single character. Over 32, the parameter has a default declared length of whatever the length of the literal is. If you issue the following: ===> call pgm(ABC) parm('12345678901234567890') and receive it into a character variable declared as longer than 32 positions, there will be no padding at the rightmost end. Whatever was in memory after position 32 becomes part of the value of the received argument. Positions 21 through 32 should be blank, but the rest? Who knows? (Actually, you CAN make some predictions, but that's irrelevant.) If you supply some precise examples of the CALL, corrections can be given.

---

If you need more you can use arrays (up to 9999 times 256 bytes) or data structures (up to 32K ?)

---

Depends on how the program is called. There is no problem if it is called from another program using variables for the parameters (using the correct definitions, of course). The padding happens when it is called using literals, mostly when used from the command line.

---

Do you have a specific example of what you are describing? What you are describing has never happened to me or to anyone else I know. And also runs contrary to any discussion of parameter passing I have seen in any of the HLL manuals.

---

I used to work on a project were every I/O was handled by a specific program. So in order to read/write something, a program needed to call this routine with the record buffer (was always bigger than 32 bytes). In case it would give garbage as you stated, this project shouldn't have worked... however it did !

---

This is not entirely accurate, either. Calling a program with a character parameter (in a CL lets say) greater that 32 character could very likely end up with garbage in the trailing character, even in the parameter on the receiving program is declared the same size, type, etc. It's happened to me, and other, many times before.

---

This is not entirely accurate, the 32 character limitation, only applies when you use the CALL command on a command line to pass parameters to a program. When a HLL program calls another program, a pointer to the string is passed to the sub-program. If the string declared in the main program is declared shorter than the string in the sub-program, then the extra characters in the sub-program may actually overrun some other storage from the main program. Any modifcation to the string by the sub-program could yield "unpredicatable results". On the other hand, the sub-program declares the string as shorter than what is passed, the subprogram will not have any problems but it won't be able to address all the positions in the string. While strings may be limited to 256 in RPG/400, Data structures are not and can be passed as a parameter.

---

The main thing to watch out for with long character fields is that right-padding with spaces is not done consistently if the field is over 32 in length. If your content does not fill the field, garbage characters may end up padding the field on the right. In your example, the contents of PARM2 will probably end up in PARM1 following the last non-blank character. If you need a field with a length greater than 32, you must ensure that all characters are filled in. I usually handle this by making the field one character longer than needed, and place some character such as "." in the final character.

---

PARM1 at 70 is more than acceptable. I constantly use 100 byte parms. The limitation is the max length of RPG, of course it depends on your version that you are using. RPG/400 max length is 256 for character fields. We are running V3R2

---