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



-----Original Message-----
From: rpg400-l-bounces@xxxxxxxxxxxx
[mailto:rpg400-l-bounces@xxxxxxxxxxxx] On Behalf Of Larry Ducie
Sent: Thursday, November 01, 2007 7:39 AM
To: rpg400-l@xxxxxxxxxxxx
Subject: Re: Is const really that much better than value?



Also, could anybody take this thread further and explain HOW
the use of varying and/or options(*varsize) affect the
efficiencies in passing large string data. I can see the
value (no pun intended) in using both of these and I use
options(*varsize) frequently in conjunction with opdesc and
CEEDOD calls. But what I'd like to know is "exactly" why
varying is better than non-varying . I can obviously see
there will be efficiencies because only the data defined by
the length is copied to temporaries but I'd like to know a
little more about the mechanics of, say, passing a varying
character string by value.

It's pretty simple really, the key thing to realize is that in both cases not only are you passing the
data in the variable but you're passing the current length of the variable also.

With, *VARSIZE, you have to pass the length explicitly in another parameter.

With VARYING, the length is implicitly defined as the first two bytes of the variable.

Now consider a procedure that takes a 2500a CONST VARYING parm.

You pass a 100a VARYING variable to it, which at run time only contains 50 characters.

Inside the procedure is a 2500a VARYING work field.

if you have an eval WRKFLD = PARM1, at run time, the procedure knows PARM1 only has 50 chars, so the
procedure only accesses the first 50 characters.

if you're dealing with *VARSIZE instead, the code in the procedure instead has to look like
eval WRKFLD = %subst(PARM1:1:PARM2)

where PARM2 contains the length of PARM1.

Works the same way if you pass a literal, except a temporary variable is created during compile to
hold the data. But the temporary variable need not be 2500a, instead it only needs to be big enough
to hold the literal.

AFAIK, passing a VARYING by value is always going to result in a temporary variable (onto the stack?)
of the same max length as the procedure parameter.

If you're dealing with large strings,
1) Use VARYING
2) pass by CONST reference

Passing by value makes sense for small fields, 1-16 bytes, larger than that and CONST is a better
choice.

Here's a related thread from last year (that you participated in BTW ;-)
http://archive.midrange.com/rpg400-l/200605/msg00162.html

HTH,
Charles



This e-mail transmission contains information that is intended to be confidential and privileged. If you receive this e-mail and you are not a named addressee you are hereby notified that you are not authorized to read, print, retain, copy or disseminate this communication without the consent of the sender and that doing so is prohibited and may be unlawful. Please reply to the message immediately by informing the sender that the message was misdirected. After replying, please delete and otherwise erase it and any attachments from your computer system. Your assistance in correcting this error is appreciated.


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.