|
|
Submitting a job using numeric parameters |
|
Problem: RPG program calls CL program which submits a RPG program to batch.
When all this is ran interactively it works. However, in batch, the last RPG
program bombs on decimal data error on one of the numeric parameters. Cause: The CALL command, especially when processed via a SBMJOB, handles numerics better as 15,5 packed. Solution 1: Store all numerics being used as parameters as 15,5 packed. Solution 2: Store all parameters embedded in a character datastructure and pass a single parameter, the datastructure. Solution 3: Use another object, such as a file or a data area, to contain the parameters. Solution 4: And my favorite. Write your own command and use that, instead of CALL, on your SBMJOB commands. When you do a SBMJOB you have a parameter called CMD. Traditionally people put in here a CALL command and then call their program directly. However, when dealing with numeric parameters you can get into big trouble. Let's say you have a RPG program which calls another program. The first program has a screen which processes some information and passes it to the second program. And maybe this second program is rather intensive and you want that to run in batch. Then you may have the following in your first program:
C CALL 'MYPGM'
C PARM MYNBR 50
Then you create a source member of type CMD. And this may contain:
CMD PROMPT('Your description here')
PARM KWD(MYNBR) TYPE(*DEC) LEN(5) MIN(1) CHOICE('Valid +
number') PROMPT('Enter number here')
To compile this you do CRTCMD CMD(MYLIB/MYPGM) PGM(MYLIB/MYPGM)
To see how this looks you can they type in the following at a command line
MYPGM and hit
And your second program may have:
| |
|
For further discussions along this line:
| |
| How to easily create a CMD front end to avoid these CL parameter problems:
http://faq.midrange.com/data/cache/576.html
| |
Append to This Answer | |
| rob, david, buck.calabro |
| Previous: |
|
| Next: |
|
| ||||||||