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



Yes - well aware of all this Frank but I'm sure it will be useful to others. As far as I know I was the first person (with Barbara) to use a C function from RPG. long long long time ago.

Barbara's guide to converting C interfaces to RPG is now hosted on Scott's website here: http://scottklement.com/rpg/callc.html <http://scottklement.com/rpg/callc.html> Best guide to the process that I have even seen.

But automatic translation is certainly possible to some extent but IBM never really did much of it.


Jon Paris

www.partner400.com
www.SystemiDeveloper.com

On Dec 1, 2018, at 3:30 AM, Frank Kolmann <frank.kolmann@xxxxxxxxx> wrote:

Hi Jon

You probably know this already, apologies in advance.
Perhaps the reason why the prototypes are not set up is because many APIs use pointer variables.
For a C programmer the API documentation in the manuals probably is completely obvious.
For an RPG programmer translating the C-like documentation into an RPG prototype is not so obvious.
The pointer variables such as 1 Receiver variable Output Char(*) below for QDFRTVFD can be a mystery.
I think someone perhaps Scott Klement once documented how to translate the API documentation into RPG code.
Perhaps these days RPG coders are completely conversant with pointers and understand that pointers effectively become variable length data elements not to be confused with varying length character fields.
I was not until I learnt C that I began to understand the power of pointers.

The below is an example of a prototype I got from Scott , I believe, and although the API doc mentions Char(*) for the return variable, I have coded an 8 byte value.
However by using pointer variables and %alloc the API recognises the space for the returned data is no longer 8 bytes.

Frank Kolmann

From the API manual.
'-- start --'
Retrieve Display File Description (QDFRTVFD) API
Required Parameter Group:
1 Receiver variable Output Char(*)
2 Length of receiver variable Input Binary(4)
3 Format name Input Char(8)
4 Qualified file name Input Char(20)
5 Error code Output Char(*)

Default Public Authority: *USE
Threadsafe: No

Receiver variable OUTPUT; CHAR(*) The receiver variable that receives the information requested.
You can specify the size of the area smaller than the format requested as long as you specify the length of receiver variable parameter correctly.
As a result, the API returns only the data the area can hold.
-- end --'


This is from some code I did for the Retrieve File Description API, again I borrowed from Scotts work.
There are 2 calls to the API, first to get the space needed for the return data, then the real call to get the data.

D RtvDspFDesc PR ExtPgm( 'QDFRTVFD' )
D 8
D 10I 0 Const
D 8 Const
D 20 Const
D 272


C CallP RtvDspFDesc(
C RtvSizeInfo :
C 8 :
C 'DSPF0100' :
C QDspFil :
C APIErrDS
C )
C If BytesAvail > 0
C Return *Off
C EndIf

C eval p_QDFFBASE = %alloc(RtvSize)

*-------------------------------------------------------------------
C Reset APIErrDS
* Retrieve display file description ( QDFRTVFD ) API
C CallP RtvDspFDesc(
C QDFFBASE :
C RtvSize :
C 'DSPF0100' :
C QDspFil :
C APIErrDS
C )
C If BytesAvail > 0
C Return *Off
C EndIf



On 1/12/2018 9:16 AM, Jon Paris wrote:
Anyone know what the IBM rules are for when a proto is supplied in QSYSINC ?
Going through them a lot are supplied (such as QUSLRCD for example) but others such as QUSPTRUS are not there.
I'm trying to come up with a way for clients to determine which ones they have and which they need to potentially create.


Jon Paris

www.partner400.com
www.SystemiDeveloper.com


--
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: https://amazon.midrange.com


As an Amazon Associate we earn from qualifying purchases.

This thread ...

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.