|
Ray, We ran into this problem so long ago that we now always to a SBMJOB to a command not a CALL as a result of it. This keeps parameter length integrity. If memory serves me it has something to do with the fact that your alpha parameters are not 32 characters. I'm sure that someone will give you the gory details. So create a command defining your parameters and use your program as the command processing program. HTH "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 > > ------------------------------------------------------------------------ > > Part 1.2 Type: application/ms-tnef > Encoding: base64 +--- | 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.
midrange.com
