|
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?
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2025 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.