|
midrange.com
By default, when using SBMJOB, QCMDEXC, running a command from the command
line, or similar, the operating system only allocates 32 bytes to each
parameter.
In your "&P02", when the data inside the variable exceeds 32 bytes, it
will allocate as much memory as you have data -- but it does not count
trailing blanks as data!
When your program in the submitted job reads that parm, it assumes that 90
bytes have been passed to it -- but since the system may have allocated
fewer than 90 bytes, the remaining portion of your variable will be
whatever junk happened to be in the next area of memory.
So whats the solution?
1) Instead of submitting a "CALL" command, make an actual CL command
and submit that. This allows the system to know the size of
each parameter.
2) Make sure that you always pass at least 90 bytes of data. An easy way
to do this is something like this:
DCL VAR(&P02FIX) TYPE(*CHAR) LEN(91)
CHGVAR VAR(&P02FIX) VALUE(&P02 *CAT 'X')
SBMJOB CMD(CALL PGM(*LIBL/PRR50130) PARM(&P01 &P02FIX +
&P03 &P04 &P05)) JOB(PRR50130XX) JOBQ(QPGMR2)
the submitted program (PRR50130) should still define the
parameter as LEN(90). The idea is that by putting an 'X' in
the 91st byte, we force the system to allocate 91 bytes to that
parameter. PRR50130 is only using the first 90 bytes of that
91, so the X won't interfere with anything.
Note that these techniques are NOT necessary when passing from program to
program directly. (such as a CL program calling an RPG program, or
another CL program) because in that case the program allocates memory
for the variables, rather than the command interpreter.
Make sense?
On Thu, 22 Mar 2001, Ray, Adam wrote:
> Hello all.
>
> I am submitting a job from a CL program passing some parameters. When the
> RPG program receives the parameters they contain some zeros that weren't
> there before I submitted the job. I thought this list might be able to help
> me out, as it has done in the past. Here come the details.
>
> The following is my CL program. The parameters are filled from an input
> screen.
>
> DCL VAR(&P01) TYPE(*CHAR) LEN(30)
> DCL VAR(&P02) TYPE(*CHAR) LEN(90)
> DCL VAR(&P03) TYPE(*CHAR) LEN(9)
> DCL VAR(&P04) TYPE(*CHAR) LEN(8)
> DCL VAR(&P05) TYPE(*CHAR) LEN(8)
> ...
> DMPCLPGM
> SBMJOB CMD(CALL PGM(*LIBL/PRR50130) PARM(&P01 &P02 +
> &P03 &P04 &P05)) JOB(PRR50130XX) JOBQ(QPGMR2)
>
> As you can see, I do a dump CL program right before the submit job. Here are
> the values of the parameters in the dump.
>
> &P01 *CHAR 30 '020090
> ' F0F2F0F0F9F040404040404040404040404040404040404040
> +26 ' '
> 4040404040
> &P02 *CHAR 90 '
> ' 40404040404040404040404040404040404040404040404040
> +26 ' '
> 40404040404040404040404040404040404040404040404040
> +51 ' '
> 40404040404040404040404040404040404040404040404040
> +76 ' '
> 404040404040404040404040404040
> &P03 *CHAR 9 ' '
> 404040404040404040
> &P04 *CHAR 8 '00000000'
> F0F0F0F0F0F0F0F0
> &P05 *CHAR 8 '00000000'
> F0F0F0F0F0F0F0F0
>
> Here is the entry parameter list in the RPG program.
>
> C *ENTRY PLIST
> C PARM p01 30
> C PARM p02 90
> C PARM p03 9
> C PARM p04 8
> C PARM p05 8
>
> The very first thing I do in the RPG program (*INZSR) is a dump. The dump
> shows the following in the above parameters.
>
> P01 CHAR(30) '020090 '
>
> VALUE IN HEX
> 'F0F2F0F0F9F0404040404040404040404040404040404040404040404040'X
>
> P02 CHAR(90) '
> 00000000 '
> 81 ' '
>
> VALUE IN HEX
> '404040404040404040404040404040404040404040404040404040404040404040404040404
> 04040'X
> 41
> '4040404040404040404040404040404040404040404040404040F0F0F0F0F0F0F0F04040404
> 04040'X
> 81 '40404040404040404040'X
>
> P03 CHAR(9) ' '
> '404040404040404040'X
> P04 CHAR(8) '00000000'
> 'F0F0F0F0F0F0F0F0'X
> P05 CHAR(8) '00000000'
> 'F0F0F0F0F0F0F0F0'X
>
> My question is where did those 8 zeros come from in variable P02? They
> aren't there immediately before the submit, but they are there immediately
> after the submit. Why? I am testing the variable for *BLANKS within the RPG
> program and it isn't doing what it's supposed to because those zeros are
> there.
>
> Thanks in advance.
> - Adam
>
>
+---
| This is the Midrange System Mailing List!
| To submit a new message, send your mail to MIDRANGE-L@midrange.com.
| To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com.
| To unsubscribe from this list send email to MIDRANGE-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com
+---
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.
