Garbage at the end of a long CL parm

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 - 2961 days ago
Last viewed on: 17 Apr 2024 (4744 views)

Main URL:

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!

Sort Ascend | Descend

COMMENTS

(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: 8 years 1 months 14 days 1 hours 56 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: 8 years 1 months 13 days 23 hours 53 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 ****

Chicagoland

www.cozTools.com/qryfile

Comment on: Garbage at the end of a long CL parm
Posted: 8 years 1 months 13 days 19 hours 38 minutes ago
Edited: Thu, 10 Mar, 2016 at 09:18:03 (2961 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: 8 years 1 months 10 days 6 hours 3 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.