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


  1.  Home
  2. RPG400-L
  3. December 2005

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

Opps, fort the @ in this line
   Sel_Mbrs( x ) = Mbrs.data_a( x ) ;

Should be
   Sel_Mbrs( x ) = @Mbrs.data_a( x ) ;


Charles Wilt
--
iSeries Systems Administrator / Developer
Mitsubishi Electric Automotive America
ph: 513-573-4343
fax: 513-398-1121
  

> -----Original Message-----
> From: rpg400-l-bounces@xxxxxxxxxxxx 
> [mailto:rpg400-l-bounces@xxxxxxxxxxxx] On Behalf Of Wilt, Charles
> Sent: Tuesday, December 13, 2005 3:38 PM
> To: RPG programming on the AS400 / iSeries
> Subject: RE: Handling *Entry parms from command (using 
> MAX(8)) in a subproc
> 
> Dan,
> 
> You really need a LIKEDS here
> 
>    d arry_ds      ds           qualified
>    d  count               5i 0 
>    d  data_a             10a   Dim( 8 )
> 
>    d mainline     pr           extpgm('MYRPGLEPGM')
>    d  pMbrs                    likeds(arry_ds)
>    d  pMbrTypes                likeds(arry_ds)
>    d  pLibraries               likeds(arry_ds)
>    d  pOmitMTypes              likeds(arry_ds)
> 
>    d ProcessParms pr
>    d  @Mbrs                    likeds(arry_ds)
>    d  @MbrTypes                likeds(arry_ds)
>    d  @Libraries               likeds(arry_ds)
>    d  @OmitMTypes              likeds(arry_ds)
> 
>    c             CallP     ProcessParms( pMbrs
>    c                                   : pMbrTypes
>    c                                   : pLibraries
>    c                                   : pOmitMTypes )
> 
>    c             Dump(a)
>    c             Eval      *inLR = *On
> 
> 
>    p ProcessParms b
>     *
>    d ProcessParms pi
>    d  @Mbrs                    likeds(arry_ds)
>    d  @MbrTypes                likeds(arry_ds)
>    d  @Libraries               likeds(arry_ds)
>    d  @OmitMTypes              likeds(arry_ds)
> 
>    d Sel_Mbrs     s      10a   Dim( 8 )
> 
>    d x            s       5i 0
> 
>     /free
>       For  x = 1 to @Mbrs.count      ;
>         Sel_Mbrs( x ) = Mbrs.data_a( x ) ;
>       Endfor                         ;
>     /end-free
> 
>    p ProcessParms    e
> 
> HTH,
> 
> Charles Wilt
> --
> iSeries Systems Administrator / Developer
> Mitsubishi Electric Automotive America
> ph: 513-573-4343
> fax: 513-398-1121
>   
> 
> > -----Original Message-----
> > From: rpg400-l-bounces@xxxxxxxxxxxx 
> > [mailto:rpg400-l-bounces@xxxxxxxxxxxx] On Behalf Of Dan
> > Sent: Tuesday, December 13, 2005 1:47 PM
> > To: RPG400-L@xxxxxxxxxxxx
> > Subject: Handling *Entry parms from command (using MAX(8)) in 
> > a subproc
> > 
> > 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.  Here is a brief snippet of that subproc, preceded 
> > by the prototype
> > and the CallP in the main proc, with more comments below.  
> > (Note: code is
> > "compressed" and not in proper columns.)
> > 
> >    d ProcessParms pr
> >    d   @Mbrs             82
> >    d   @MbrTypes         82
> >    d   @Libraries        82
> >    d   @OmitMTypes       82
> > 
> >    c             CallP     ProcessParms( pMbrs
> >    c                                   : pMbrTypes
> >    c                                   : pLibraries
> >    c                                   : pOmitMTypes )
> > 
> >    c             Dump(a)
> >    c             Eval      *inLR = *On
> > 
> >    c   *Entry    plist
> >    c             parm           pMbrs            82
> >    c             parm           pMbrTypes        82
> >    c             parm           pLibraries       82
> >    c             parm           pOmitMTypes      82
> > 
> >    p ProcessParms b
> >     *
> >    d ProcessParms pi
> >    d   pMbrs             82
> >    d   pMbrTypes         82
> >    d   pLibraries        82
> >    d   pOmitMTypes       82
> > 
> >    d pMbrs_ds     ds     82
> >    d  pMbrs_c             5i 0
> >    d  pMbrs_a            10a   Dim( 8 ) Overlay( pMbrs_ds : 3)
> > 
> > 
> >    d Sel_Mbrs_ds  ds     80    Inz
> >    d  Sel_Mbr1           10a   Overlay( Sel_Mbrs_ds : 1 )
> >    d  Sel_Mbr2           10a   Overlay( Sel_Mbrs_ds : *next )
> >    d  Sel_Mbr3           10a   Overlay( Sel_Mbrs_ds : *next )
> >    d  Sel_Mbr4           10a   Overlay( Sel_Mbrs_ds : *next )
> >    d  Sel_Mbr5           10a   Overlay( Sel_Mbrs_ds : *next )
> >    d  Sel_Mbr6           10a   Overlay( Sel_Mbrs_ds : *next )
> >    d  Sel_Mbr7           10a   Overlay( Sel_Mbrs_ds : *next )
> >    d  Sel_Mbr8           10a   Overlay( Sel_Mbrs_ds : *next )
> >    d Sel_Mbrs            10    Dim( 8 )  Overlay( Sel_Mbrs_ds : 1 )
> > 
> >    d x            s       5i 0
> > 
> >     /free
> >       pMbrs_ds       = pMbrs         ;
> >       pMbrTypes_ds   = pMbrTypes     ;
> >       pLibraries_ds  = pLibraries    ;
> >       pOmitMTypes_ds = pOmitMTypes   ;
> > 
> >       For  x = 1 to pMbrs_c          ;
> >         Sel_Mbrs( x ) = pMbrs_a( x ) ;
> >       Endfor                         ;
> >     /end-free
> > 
> >    p ProcessParms    e
> > 
> > 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?
> > 
> > TIA,
> > Dan
> > -- 
> > This is the RPG programming on the AS400 / iSeries (RPG400-L) 
> > mailing list
> > To post a message email: RPG400-L@xxxxxxxxxxxx
> > To subscribe, unsubscribe, or change list options,
> > visit: http://lists.midrange.com/mailman/listinfo/rpg400-l
> > or email: RPG400-L-request@xxxxxxxxxxxx
> > Before posting, please take a moment to review the archives
> > at http://archive.midrange.com/rpg400-l.
> > 
> > 
> 
> -- 
> This is the RPG programming on the AS400 / iSeries (RPG400-L) 
> mailing list
> To post a message email: RPG400-L@xxxxxxxxxxxx
> To subscribe, unsubscribe, or change list options,
> visit: http://lists.midrange.com/mailman/listinfo/rpg400-l
> or email: RPG400-L-request@xxxxxxxxxxxx
> Before posting, please take a moment to review the archives
> at http://archive.midrange.com/rpg400-l.
> 
>

As an Amazon Associate we earn from qualifying purchases.

This thread ...
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.