RE: Parameters

[martin.nageler@xxxxxxxxxxxxx]

hi buck,

thanks for your detailed explanations.

do you or (of course) anybody else know, why there' s a problem by passing
this long alpha-parm into batch. let's have a look at a little example: i
just took your pgm and changed the call pgm into a sbmjob:

code snap: cl/rpg


 PGM
 DCL        VAR(&CHAR) TYPE(*CHAR) LEN(256) VALUE('A')
 SBMJOB     CMD(CALL PGM(NATEST) PARM(&CHAR)) JOBQ(PGMRTEST)
 ENDPGM

H DEBUG
D XPARM            S            256A
C                 *ENTRY        PLIST
C                   PARM                             XPARM
C                   DUMP
C                   SETON
LR

snap of debug-output:

XPARM                 CHAR(256)            'A
o     NATESTf     PARMØ       E     A»       '
                                             81                 '
1          *HEX                *JOBRUN1   '
                                            161                '1   QILE
0*LIBCRTAUT1       V4R2M0  1  *NONE                               '
                                            241                '
11'
                      VALUE IN HEX
'C1404040404040404040404040404040404040404040404040404040404040404000019600000000'X


                        41
'06D5C1E3C5E2E3860000000004D7C1D9D48000000100090001C50000000001C18B00000000004040'X


                        81
'4040404040404040404040404040404040404040404040404040404040404040404000000028F100'X


                        121
'0A00004040000100005CC8C5E7404040404040404040404040404040405CD1D6C2D9E4D5F1404040'X


                        161
'F1404040D8C9D3C5404040404040F05CD3C9C2C3D9E3C1E4E3F140404000010001E5F4D9F2D4F040'X


                        201
'40F100015CD5D6D5C540404040404040404040404040404040404040404040404040404040404040'X


                        241
'4040404040404040404040404040F1F1'X


shouldn't this parm be filled with 1 'a' and 255 blanks, just like it is if
you call the pgm interactively??? what's that trailing rubbish in the field
xparm?

any hints?

martin



...

e) Despite the focus on numeric parameters, character parameters suffer
from
the exact same "limitations" of numeric.  If you simply convert your *DEC
to
*CHAR and pass that into your RPG program, if you mis-define the length in
the RPG program it too will fail.  The issue (as always) is that the
caller's definition must exactly match the callee's definition in type and
in size.  Here is an RPG IV program that demonstrates this:

 * Test parameter passing
 * call parm 'a'
h debug

d inpParm         s            256
d tstString       s            100

c     *entry        plist
c                   parm                    inpParm

 * what's beyond the default length of 32 bytes?
c                   eval      tstString = %subst(inpParm: 33:
c                                                %size(tstString))
c                   if        tstString <> *blanks
c     'Not blank'   dsply
c                   dump
c                   endif
c                   eval      *InLR = *On

Called from the command line, you'll likely see "garbage" in tstString,
left
over because the passed string is initialised to 32 blanks and then the "a"
is MOVELed into it.  The rest of the string (as seen from the RPG side) was
never initialised by the CL interpreter.  If you were to write a CL program
like this:

pgm
dcl &char *char 256 value('a')
call parm &char
endpgm

the RPG program will be correct because the caller initialises a 256 byte
string, MOVELs the "a" and then calls the RPG program.  Type and size
match.

Buck Calabro


+---
| This is the RPG/400 Mailing List!
| To submit a new message, send your mail to RPG400-L@midrange.com.
| To subscribe to this list send email to RPG400-L-SUB@midrange.com.
| To unsubscribe from this list send email to RPG400-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com
+---