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 firstname.lastname@example.org.
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
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 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
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.