Passing parameters RPG-CL-RPG

1410 pts.
Tags:
CLLE
Parameters
RPG ILE
I am trying to modify an intermediate CLLE program to submit itself to batch. The calling program (ILE RPG) passes a parameter as a character field with a number in it. The CL program receives it as a numeric field and then calls another RPG program and passes that parameter. The final RPG program receives the parameter as a numeric field. The first problem: I changed the CL program to submit itself to batch and passed the incoming parameters to it. The final RPG program gave me a decimal data error on that field. I changed the initial calling program to pass the parameter as numeric instead of character and the final RPG program gave me a decimal data error. I have looked at the parameter in all three programs in debug; both of the RPG programs show the correct number. The CL program shows the value as you would expect: F0F0F5F8 rather than 0058249. This is driving me crazy because I need to change it and can't without getting a decimal data error. Anybody got any ideas?

Software/Hardware used:
AS/400, ILE RPG (non-free form), CLLE

Answer Wiki

Thanks. We'll let you know when a new response is added.
Send me notifications when members answer or reply to this question.

REGISTER or login:

Forgot Password?
By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy

Discuss This Question: 3  Replies

 
There was an error processing your information. Please try again later.
Thanks. We'll let you know when a new response is added.
Send me notifications when members answer or reply to this question.

REGISTER or login:

Forgot Password?
By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy
  • TomLiotta
    The first problem: I changed the CL program to submit itself to batch and passed the incoming parameters to it. Most likely, you used the SBMJOB CMD() parameter to call the program. By doing that, you brought system elements into it that will apply basic CALL command parameter rules that apply to untyped values. There are a few general possibilities. First, use RQSDTA() instead of CMD(). If you look at the RQSDTA() default value, you should see that it is RQSDTA(*CMD). It might seem that that means that it will be the same value as you put in the CMD() parm; but it really means "the CMD() parm value after it has been processed by the command analyzer/prompter". If you want to have full control over the final request string, then build the string yourself exactly as you want it to be. It takes a bit more programming, but you can make it be exact. Second, you can change the incoming parm definitions to match what's going to arrive. You already know, for example, that your numeric parm value is going to arrive as packed. Declare that parm as a *DEC (15 5) because that's what it's going to be. That's always been the default definition of a numeric parm value. Third, create a *CMD to carry the definitions of the parm values. Submit that command instead of submitting a CALL command. Parameters of CALL have no useful data typing. The system handles all CALL parm values according to a very specific set of rules. It's very likely that those rules will not match the parameter definitions that you're using. I have looked at the parameter in all three programs in debug; both of the RPG programs show the correct number. I don't understand that part. If the RPG shows a correct value, then where is the decimal-data error showing up? Were you debugging the job that was submitted to batch? Tom
    125,585 pointsBadges:
    report
  • Vatchy
    I have looked at the parameter in all three programs in debug; both of the RPG programs show the correct number. Sorry, I wasn't clear on that. I saw the parameters through the three programs interactively. When submitting to batch, the parameter in the CL program looked the same as when interactive but it passed the F0F0F5F8 to the RPG rather than the correct value as it did when interactive. I'll try using RQSDTA instead of CMD and see what happens.
    1,410 pointsBadges:
    report
  • TomLiotta
    I’ll try using RQSDTA instead of CMD and see what happens. I suggest creating a test version of the program that submits itself to batch. Just define the parms and the code that generates the SBMJOB command. Have it dump its variables and end when it arrives in batch. Carefully review the Request message in the batch joblog to see what results. Once that test code works, it can be copied into the live programming. Generating the request data takes a little practice and understanding. The difficulties of it are probably what convinced IBM to add the CMD() parm to SBMJOB way back in the early releases of OS/400. Unfortunately, most developers now never learn the relationship between CMD() and RQSDTA(). They just assume that CMD() doesn't work very well. Tom
    125,585 pointsBadges:
    report

Forgot Password

No problem! Submit your e-mail address below. We'll send you an e-mail containing your password.

Your password has been sent to:

To follow this tag...

There was an error processing your information. Please try again later.

REGISTER or login:

Forgot Password?
By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy

Thanks! We'll email you when relevant content is added and updated.

Following