× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.


  • Subject: Re: where did those zeros come from?
  • From: Scott Klement <klemscot@xxxxxxxxxxxx>
  • Date: Thu, 22 Mar 2001 11:06:20 -0600 (CST)



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 thread ...

Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

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.