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

1) I don't think you can do that on a const variable.  
2) As mentioned before, this method get a bit messy when there are a lot
of parms and you need to use them to pass to another procedure.


-----Original Message-----
From: rpg400-l-bounces@xxxxxxxxxxxx
[mailto:rpg400-l-bounces@xxxxxxxxxxxx] On Behalf Of Kurt Anderson
Sent: Thursday, August 31, 2006 10:58 AM
To: RPG programming on the AS400 / iSeries
Subject: RE: Allocate field with options(*nopass :*omit). 

Lim,

Here's an example.  I haven't tested it.
The Variable value will start off pointing at the value of DefaulVal.
If a parameter is passed, change the pointer to point at the parameter
passed.

I'm not sure if you can make Variable a constant and have this still
work (and able to point at a Const procedure parameter).  That's
somethin you'll have to play with.

     D ptr             S               *   Inz( %addr( DefaultVal ) )
     D DefaultVal      S                   Inz( 'Default' ) Like(
Variable )
     D Variable        S            320a   Based( ptr )

     D Proc            PR
     D  ProcParm1                   320a   Options( *NoPass )
     
      /Free

       If %parms = 1;
         ptr = %addr( ProcParm1 );
       EndIf;

      /End-Free  


Kurt Anderson
Application Developer
Highsmith Inc

-----Original Message-----
From: rpg400-l-bounces@xxxxxxxxxxxx
[mailto:rpg400-l-bounces@xxxxxxxxxxxx] On Behalf Of Lim Hock-Chai
Sent: Thursday, August 31, 2006 10:35 AM
To: RPG programming on the AS400 / iSeries
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.