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

Hi, Mihael:

I think rather than creating a whole new "layer" or "wrapper" around your service program, if you have the source for the *MODULEs comprising the service program, you could just change the "interfaces" to the exported procedures and functions so they use 128-bit pointers, e.g. using the special __ptr128 keyword:

char * __ptr128 p;

Then, within your procedures, the first thing you do is copy the parameter pointer to a local variable that is a 64-bit pointer, then use only 64-bit pointers inside the C or C++ code, which is more efficient. Then, if you need to return a pointer, convert that from a 64-bit pointer to a 128-bit pointer just before the return.

Does that make sense?

In other words, you don't need a whole extra layer. If your intention is that this *SRVPGM procedures are callable from any other ILE language, all parameters should be 128-bit pointers, because I don't think any other ILE HLL languages besides C and C++ currently support 64-bit pointers.

Does that help?

Mark S. Waterbury

> On 6/4/2010 5:16 PM, Schmidt, Mihael wrote:
Oh. I think I missed something. Pointer conversion will automatically take place for C and C++ programs. Does the RPG compiler / runtime automatically convert pointers? If I take the result of my program my guess is that it doesn't.

Is the solution to build a C wrapper service program for the "real" service program which contains a wrapper procedure for every procedure containing pointer as return values or parameters, so that they will be converted from 16 byte to 8 byte and vice versa?


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