RE: Allocate field with options(*nopass :*omit)

   I don't think CEEDOD adds much (if any) overhead since it is an in-line
   built-in.
    
   The CONST keyword's primary purpose is to allow you to tell the procedure
   that "this" parameter must not be modified. THis allows the compiler to
   assume things and optimize things.
    
   CONST also causes (typically) the value being passed to be padded. It
   typically does this ONLY when the value being passed is shorter than that
   parameter definition.
    
   OPTIONS(*VARSIZE) turns off the compiler syntax checking for a character
   parameter. Normally the value passed on a character parameter must be at
   least as long as the parameter definition, but not shorter.
   OPTIONS(*VARSIZE) turns off that restiction and assumes _you_ will know
   how much data was sent to the parameter. THere are a number of ways to do
   this, including passing another parameter with the length.
    
   -Bob

     -------- Original Message --------
     Subject: RE: Allocate field with options(*nopass :*omit)
     From: "Lim Hock-Chai" <Lim.Hock-Chai@xxxxxxxxxxxxxxx>
     Date: Thu, August 31, 2006 11:32 am
     To: "RPG programming on the AS400 / iSeries" <rpg400-l@xxxxxxxxxxxx>

     When uses "const options(*varsize)", the procedure usually need to call
     CEEDOD to determine the actual length of the variable.  
     If Jon's is correct on the theory of calling CEEDOD could be slower than
     just copy the data to a temporary variable, then why not just not
     specify (*varsize).  Hence the question of what is the point of "const
     options(*varsize)".

     -----Original Message-----
     From: rpg400-l-bounces+lim.hock-chai=usamobility.com@xxxxxxxxxxxx
     [mailto:rpg400-l-bounces+lim.hock-chai=usamobility.com@xxxxxxxxxxxx] On
     Behalf Of Peter Levy
     Sent: Thursday, August 31, 2006 11:10 AM
     To: RPG programming on the AS400 / iSeries
     Subject: Re: Allocate field with options(*nopass :*omit)

     There's always a good reason to use options(*varsize) with "const"
     parameters. If you have something that is 32727a and you pass 'TEST'
     then the system will copy it to a temporary storage area that is 32727
     bytes long. That takes time too. My favorite solution to this connundrum
     is to do what IBM does on their API's, require a length parameter to be
     passed as well.

     ----- Original Message -----
     From: Lim Hock-Chai
     To: RPG programming on the AS400 / iSeries
     Sent: Thursday, August 31, 2006 11:35 AM
     Subject: RE: Allocate field with options(*nopass :*omit)

     If CEEDOD is a slow polk then is there a point of using
     options(*varsize) on const?

     I'm not understanding "defining the variable to be used by the subproc
     as based".  Can you give example?

     -----Original Message-----
     From: rpg400-l-bounces@xxxxxxxxxxxx
     [mailto:rpg400-l-bounces@xxxxxxxxxxxx] On Behalf Of Jon Paris
     Sent: Thursday, August 31, 2006 10:19 AM
     To: rpg400-l@xxxxxxxxxxxx
     Subject: RE: Allocate field with options(*nopass :*omit)

     Lim,

     I haven't time to test it, but I wouldn't mind betting that the single
     call to CEEDOD will by itself take way longer than simply copying the
     parm value as was originally suggested.  You're adding a lot of
     complexity to the code in the hope of improving performance, but in
     reality I suspect you are having exactly the opposite effect.

     If you don't like the idea of copying, go with the suggestion earlier of
     defining the variable to be used by the subproc as based (with it's
     pointer pre-initialized to the address of the default value) and simply
     flip the pointer to the address of the parm if one is supplied.  In
     terms of raw speed I would expect that to be the fastest version.

     Jon Paris
     Partner400

     www.Partner400.com

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

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