× 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: "Ray, Adam" <aray@xxxxxxx>
  • Date: Thu, 22 Mar 2001 11:49:17 -0600

Thanks Scott. I used solution number 2, only because I am clueless as to how
to do number 1. I would love to learn though.


        -----Original Message-----
        From:   Scott Klement [SMTP:klemscot@klements.com]
        Sent:   Thursday, March 22, 2001 11:06 AM
        To:     'MIDRANGE-L@midrange.com'
        Subject:        Re: where did those zeros come from?



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

Follow-Ups:

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.