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



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.



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.