Re: Handling *Entry parms from command (using MAX(8)) in a subproc

Dan,

First of all, an eror in your code:
>        Sel_Mbrs( x ) = pMbrs_a( x ) ;
won't work, as Sel_Mbrs is not defined as an array; those are subfields of the 
Sel_Mbrs_ds.

I would prototype the call to the subprocedure with CONST, as you do not change 
the values of the parms.

Perhaps that would take some care of the garbage. Some parameters may have 
garbage after the last filled in entry of the parm itself. And apperently, not 
one parameter is required (MIN(1)).

Can you not change it into an ELEM type parm? Then you can use pointer arithmic 
to process each entry group of the parm (Some rough untested code, by heart):

PARM INPUT TYPE(ELEM1)  MIN(1) MAX(8)

ELEM1: ELEM MEMBER  *NAME LEN(10)
             ELEM  TYPE *CHAR LEN(10)
             ELEM  LIB *NAME LEN(10)
             ELEM  OMIT *CHAR LEN(10)

D Index                         S                5I 0    INZ(0)

D Entries                      DS                        BASED(MyPtr)
D       First                                      5I 0
D       Second                                  5I 0    DIM(8)

D Data_Ds                      DS                     BASED(AnotherPtr) 
D     Data                                       42       DIM(8)
D        Elem1                                   5I 0    OVERLAY(Data:1) 
D        Elem2                                  10      OVERLAY(Data:*NEXT) 
D        Elem3                                  10      OVERLAY(Data:*NEXT) 
D        Elem4                                  10      OVERLAY(Data:*NEXT) 
D        Elem5                                  10      OVERLAY(Data:*NEXT) 

C         *ENTRY PLIST 
C                      PARM                    PARM_IN                354 

C                      EVAL             MyPtr = %addr(PARM_IN)

C                      FOR               Index = 1 to First
C                      EVAL             AnotherPtr  = MyPtr + Second(Index)

C                      ENDFOR

Regards,
Carel Teijgeler

*********** REPLY SEPARATOR  ***********

On 13-12-05 at 13:46 Dan wrote:

>I have a new RPGLE application that gets its parameters from a command. 
>The command is defined as:
>
>  Parm       Members     Type( *char )  Len( 10 )  Max( 8 )
>  Parm       MembrTypes  Type( *char )  Len( 10 )  Max( 8 )
>  Parm       Libraries   Type( *char )  Len( 10 )  Max( 8 )
>  Parm       OmitMTypes  Type( *char )  Len( 10 )  Max( 8 )
>
>By virtue of the MAX (Maximum values allowed) parameter, set at eight, the
>value issued to the CPP is a structure, starting with a 2-byte binary
>number-of-values, followed by the values themselves.  The nature of the
>beast is that it is a variable-length structure, and "unreliable results" 
>follow the last entry.
>
>In the initial development of the RPG program, I was able to process the
>*Entry parms in the mainline.  Essentially, this process takes the parameter
>values and plants them in display file variables for display.  I defined a
>data structure for each parm, i.e.:
>   d pMbrs_ds     ds     82
>   d  pMbrs_c             5i 0
>   d  pMbrs_a            10a   Dim( 8 ) Overlay( pMbrs_ds : 3)
>
>and processed as:
>      For  x = 1 to pMbrs_c
>        Sel_Mbrs( x ) = pMbrs_a( x )
>      Endfor
>
>(Sel_Mbrs is an array which overlays the eight display fields.)
>
>In the main procedure, this works fine.  However...
>
>I would like to move this to a subproc.  I have only included a snippet of
>the logic, and there is more I need to do with these parameter values that
>I would really REALLY like to encapsulate in a subproc.  Unfortunately, I
>haven't found the right incantation for passing *Entry parms to a subproc.
>I already tried putting the *Entry Plist in the subproc, but that isn't 
>allowed.
>
>What's interesting is that a dump shows the subproc getting the same values
>as when I had this in the main proc, but once I use the value, I get
>garbage.
<SNIP>
>In the DUMP output (called from the main proc after this subproc is called),
>I am looking at the section titled "Local variables for subprocedure :
>PROCESSPARMS".  The value for pMbrs is as I expected, but the value for
>pMbrs_ds is garbage.
>
>Is it an issue with *Entry parms?  Or command parameters of variable
>lengths?  Or something I missed in TFM?