Midrange News for the IBM i Community

Posted by: Chris Proctor
Programmer Analyst
Columbia Sports Company
Portland, OR
Garbage at the end of a long CL parm
has no ratings.
Published: 04 Mar 2016
Revised: 10 Mar 2016 - 2753 days ago
Last viewed on: 22 Sep 2023 (4437 views) 

Using IBM i? Need to create Excel, CSV, HTML, JSON, PDF, SPOOL reports? Learn more about the fastest and least expensive tool for the job: SQL iQuery.

Garbage at the end of a long CL parm Published by: Chris Proctor on 04 Mar 2016 view comments(4)

Happy Friday everyone. I know there's been this discussion in the past, and I know IBM does a terrible job of insuring that parms are blank beyond, I think it is, 32 characters? I have a CL program where I am passing an email address parm that is 128 in length and I'm curious, what is the best way to handle it to insure that I don't have garbage in the parm after the actual email address?

I'm just curious how some of you handle this. Any ideas would be greatly appreciated!

Return to midrangenews.com home page.
Sort Ascend | Descend


(Sign in to Post a Comment)
Posted by: chrisp
Premium member *
Portland, OR
Comment on: Garbage at the end of a long CL parm
Posted: 7 years 6 months 20 days 16 hours 14 minutes ago

Just did some searching on the web and found some possible solutions. Just in case any of you are interested, here's what I found:

Some solutions:

  • Solution 1: For SBMJOB, do not use the CMD() parameter to pass a CALL command if the PARMs contain *CHAR variables greater than 32 bytes in size that need trailing blanks. Construct the RQSDTA() string instead.
  • Solution 2: Store all numerics being used as parameters as 15,5 packed.
  • Solution 3: Store all parameters embedded in a character datastructure and pass a single parameter, the datastructure.
  • Solution 4: Use another object, such as a file or a data area, to contain the parameters.
  • Solution 5: And my favorite. Write your own command and use that, instead of CALL, on your SBMJOB commands.
Posted by: Ringer
Premium member *
Comment on: Garbage at the end of a long CL parm
Posted: 7 years 6 months 20 days 14 hours 12 minutes ago

I pad the parm with blanks and add an 'x' at the very end, in your case in position 129 or greater. 

Parms are passed by address. Your program gets that address and uses 128 characters. It doesn't care or know that we passed more characters at the end of the string. And since we padded with blanks, OS400 (IBM i?) won't put junk after position 32. 

Chris Ringer


Posted by: bobcozzi
Site Admin ****
Comment on: Garbage at the end of a long CL parm
Posted: 7 years 6 months 20 days 9 hours 56 minutes ago
Edited: Thu, 10 Mar, 2016 at 09:18:03 (2753 days ago)

I write my own commands. The only time your issue is an issue is when you are calling the CL program from Command Entry. It does not apply for program-to-program calls. The Idea to use RQSDTA is probably not accurate. The CMD parameter simply permits you to enter a command, then it shifts that command string to the RQSDTA. So... perhaps they've modified it in the last 25 years and I missed that update.

Numerics are always passed as Packed(15,5) from a CALL placed on the command line to a program. However, again, variables specified in programs and passed are passed as is--without mapping them to 15,5.


Posted by: DaleB
Premium member *
Reading, PA
Comment on: Garbage at the end of a long CL parm
Posted: 7 years 6 months 16 days 20 hours 22 minutes ago

I'm with Bob. Write your own commands. I didn't used to; used to pad with blanks and stuff, but the *CMD definitions are too easy not to use. Plus you gain the ability to pass numerics as the descired size, use integer parameters, date parameters, and so on.