Guest.Visitor
01-01-1995, 02:00 AM
On Wednesday, May 07, 1997, 10:21 AM, Jim Fleming wrote: I'm trying to submit a report job from within a CL program and I get a Decimal Data Error in the 'called' program. Here is the CL source for submitting the job: PGM PARM(&PG &JB &FR &TO) /* SUBMIT MONTHLY REPORT DCL VAR(&PG) TYPE(*CHAR) LEN(10) /* PGM NAME */ DCL VAR(&JB) TYPE(*CHAR) LEN(10) /* JOB NAME */ DCL VAR(&FR) TYPE(*DEC) LEN(8) /* STR DATE */ DCL VAR(&TO) TYPE(*DEC) LEN(8) /* END DATE */ /*== the following statement causes decimal data error ==*/ SBMJOB CMD(CALL PGM(&PG) PARM(&FR &TO)) JOB(&JB) /*== the following call statement works without error ==*/ CALL PGM(&PG) PARM(&FR &TO) ENDPGM The 'called' CL program overides some print file settings and then calls an RPG program to print the report. The DUMP received on the RPG program shows that the sign bit has been dropped from the DATE parameters passed to it. For example, if the packed STR DATE should be '19970507F'X, the DUMP shows '019970507'X. I know I can convert the packed numeric to character and then convert it back to numeric in my RPG program. I also know I can use a data area to hold my parms. I'll pick one of those solutions if I can't solve the above problem. Thanks... Your problem is caused by the fact that when the submit is interpreted, all parameters are subtituted for their value when the call is placed on the jobq (&n becomes 19970102 for example). Then when the call is process the system execute a command like CALL ABC PARM(1234). The parameter being a number, it is interpreted as a constant and treated as a 15 digit 5 decimal number. That's why you lose the sign. The way to work around this prlblem that i use is to define a command which call the CL. then i submit the command instead of the call.