RE: Parameters

jacosta wrote:
>Did anyone ever run into problems when sending 
>parameters from an RPG program to a CL program 
>using a PLIST? In my PLIST I have two numeric fields 
>(P10PRD 2,0 and P10YR 4,0). I keep getting a Decimal-Data Error.

Jim Langston replied:
>There is some issue with passing variables to CLs that I 
>don't quite remember the specifics of.

Aaron Bartell added:
>I have learned that it is never a good idea to pass numerics 
>to or from a CL program.  But I always forget why it doesn't work.  

William Corbett chimed in:
>This is a hashed and rehashed problem here  I fought with this for a while,
>then wondered - Why?  Yea, yea, yea.  CL wants numerics to be 15 5, 
>but who cares?  I seldom want my numerics to be 15  5.
>As for myself, I quit fighting with it about years ago.  I never have this
>problem...I haven't passed a "numeric" to an RPG in years.

John Carr said:
>I imagine you define the variable in the CL program and then 
>defined it as Zoned decimal in the RPG.

Denis Robitaille added:
>So one solution is to make sure that the variables are defined as packed in
the RPG program.

Finally, Buck had his say:

Here's the quick synopsis for those who've heard my speech:
1) There is never a problem if the type and size match between the caller
and the callee.  
2) Literals take on default type and size attributes so if you use literals,
see statement 1.

The long version:
a) The only problem with passing parameters is when the caller passes
LITERALS as opposed to VARIABLES on both ends unless you have mis-matched
the caller's definition and the callee's definition of the length and type
of the variable.

b) Why, oh why do people continue to post "answers" when they "don't
remember why" their "solution" works?  This only adds to the confusion of
the original poster.

c) John and Denis have the right answer here, but beginners may not
understand the implementation.  Let me try again.

In CL, all numeric variables are of type Packed.  In RPG numeric variables
declared in data structures take on the type declared there; Binary, Packed,
Zoned, Signed integer, Unsigned integer, Float.  Numeric variables declared
elsewhere take on the default type of Packed.

If you get a decimal data error, make sure your RPG variables are not
declared Zoned in a data structure because that is a type-mismatch.

d) For LITERALS, the various syntax checkers can determine character/numeric
by seeing if there is a character in there.  It cannot detect if the callee
wants a packed number or a character.  Length poses a problem too.  Does 100
really mean 100.000 or 0000000100?  The syntax checker therefore uses
default values for type (Zoned, Packed, etc.) and size.  For character
strings, the default is CHAR 32.  For numeric data, it is PACK 15,5.

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
Aptis; Albany, NY
"Nothing is so firmly believed as
 that which we least know" -- Michel Montaigne
Visit the Midrange archives at http://www.midrange.com
+---
| 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
+---