×
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?
Mihael
As an Amazon Associate we earn from qualifying purchases.
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.