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



No.

Because without the VALUE keyword, the parameter is passed by reference.

Meaning the only thing passed is a 16 byte pointer.

That's why I can switch between
dcl-proc hash extproc('Qc3CalculateHash');
dcl-pi;
inputData char(160000);
dataLen int(10);
end-pi;


and
dcl-proc hash extproc('Qc3CalculateHash') ;
dcl-pi;
inputData pointer value;
dataLen int(10);
end-pi;


In both cases, only a 16byte pointer is passed to the callee.

The only difference is how the caller codes the call.

The reason to stick with %addr(VARCHAR:*DATA) is that presumably, the data
is already trimmed and the %len stored in the varchar is correct.

Otherwise, you'd either need to save the length of the data being put into
inputData, or do a %len(%trim(inputData)) to get it.

So the choice of which PR format to use really comes down to how inputData
got loaded in the first place.



Charles


On Fri, Mar 30, 2018 at 12:14 PM, Dan <dan27649@xxxxxxxxx> wrote:

Gentlemen, thanks for all of the replies. I probably won't get back to
this project until next week, but I wanted to acknowledge your
contributions. It's apparent I still have much to learn about this type of
stuff.

The biggest concern was, if I didn't use varchar, I'd always be passing
16MB of data to Qc3CalculateHash. 95% of the time, the length of the data
to be hashed won't exceed 100KB, but those outliers kill ya, so I
accommodate the max. Do I understand correctly that, by specifying
%addr(DataToHash:*DATA), that no data is being copied, but simply the
address of that data is passed to Qc3CalculateHash? If that's the case, I
wouldn't need to worry about defining DataToHash as varchar; just define it
as char. Do I have that right?

- Dan
--
This is the RPG programming on the IBM i (AS/400 and iSeries) (RPG400-L)
mailing list
To post a message email: RPG400-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: https://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at https://archive.midrange.com/rpg400-l.

Please contact support@xxxxxxxxxxxx for any subscription related
questions.

Help support midrange.com by shopping at amazon.com with our affiliate
link: http://amzn.to/2dEadiD


As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:
Replies:

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.