Home > IT Answers > AS/400 > CL Parameter Problem
Dcantwell
465 pts.
 CL Parameter Problem
AS/400, AS400 Hex Invalid data, CL Parameters, iSeries, net.data
Hello All, I have a Net.Data macro that calls a CL program to do some processing. We have two iSeries: Dev and Prod Using the same code on Dev as is on Prod, the production CL program is getting the parameter values a different way. When you put the programs into debug, Here's what one of the parameters look like: Parameter - 20 char Value coming in - 'AGRI OTHER' DEV Hex value: C1C7D9C940D6E3C8C5D940404040404040404040 Prod Hex value: C1C7D9C940D6E3C8C5D900000000000000000000 So, aparently our production box is treating zeros differently. Any Ideas?

Software/Hardware used:
V5R4M0, iSeries
ASKED: January 22, 2010  3:54 PM
UPDATED: July 15, 2010  2:46 PM
RELATED QUESTIONS
Answer Wiki:
The difference isn't zeros, but the trailing blanks and nulls. Your DEV box is putting trailing blanks (hex 40) after the 'AGRI OTHER' value, while the PROD box is putting trailing null (hex 00) values. I can't say why they are being treated differently, but you may want to try passing the value as <pre>"AGRI OTHER " vs "AGRI OTHER"</pre>. By including the trailing blanks within the quotes you should see the trailing blanks on both machines.
Last Wiki Answer Submitted:  January 25, 2010  1:36 pm  by  ElTerrifico   605 pts.
All Answer Wiki Contributors:  ElTerrifico   605 pts.
To see all answers submitted to the Answer Wiki: View Answer History.


RSS - Discussions Help
Discuss This Question:
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _

 

Well, that is actually how it’s being passed. That’s the confusing part. I don’t actually trim any of the trailing blanks as I’m passing it to the CL program.

Inside of the CL program i use TCAT and BCAT to strip off the blanks as needed…

Thanks for the suggestion though!

Dcantwell
 465 pts.
 

Sorry I didn’t explain that originally! That’s my fault.

Dcantwell
 465 pts.
 

I don’t know why it was working on one box and not the other, but I did fix the problem.

Using your idea, I made sure the spaces were filled in using a “PADDING” function in my front end language.

Thanks for your help!

Dave

Dcantwell
 465 pts.
 

You’re welcome. Glad I was able to help. It is odd though that it works on one machine and not the other. Wish I could help you figure that out. My only thought there would be to check release and ptf levels.

ElTerrifico
 605 pts.
 

also check the server configurations — perhaps there is a different “default” setting between the Dev and Prod boxes as to pad or not (or what to pad with – blank or null)

BigKat
 7,185 pts.
 

I had a similar issue passing a parameter that was longer than the data it contained. It was fine in the passing program but in the called program the trailing blanks turned into nulls. It was the last parm in the list. So, I added an extra parm at the end of the list in the calling program. I just added ‘ ‘ (a blank) . It worked perfectly. There is something about the last parameter that can be a problem.

Qbjgqbjg
 40 pts.
 

I don’t know specifics around how the .NET macro passes it’s parameters, but the IBM i manual at this link (page 233 of document, 243 of pdf) might offer some insight:

http://publib.boulder.ibm.com/infocenter/iseries/v6r1m0/topic/rbam6/rbam6.pdf

NullFields
 880 pts.