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



Of course anytime you are using pointers you need to clean up after yourself. In the RPG convert temp example, the actual call to the converttemp() function returns a pointer to a CONVERTTEMPResult.

In the RPG convert temp client (consumer) application you'll find the following code:

D Input DS
D pTempInF *

D ResultP S *
D TempInF S 10A

// Initialize input values.
TempInF = %trim(TEMPIN) + X'00';
pTempInF = %addr(TempInF);

// Invoke the ConvertTemp Web service operation.
ResultP = ConvertTemp(WsStubP:%Addr(Input));

and in the C stubs generated by the WSDL2WS tool you'll find the following functions defined:

(in CONVERTTEMPResult.h)

extern void Axis_Delete_CONVERTTEMPResult(CONVERTTEMPResult*
param, int nSize);

(in CONVERTTEMPInput.h)

extern void Axis_Delete_CONVERTTEMPInput(CONVERTTEMPInput* param,
int nSize);

As the RPG convert temp example is written, we don't need to utilize the Axis_Delete_CONVERTTEMPInput() function because the input parameter passed to ConvertTemp() is a pointer to a 10 char field specifically defined in the RPG program itself.

D TempInF S 10A

Its memory will be deallocated at the end of the program automatically.

The return value from the ConvertTemp() call is a pointer to a CONVERTTEMPResult which is allocated behind the scenes during the calling of the ConvertTemp() function and is made available for use within the RPG program. In this case it is necessary to deallocate this memory with a call to the Axis_Delete_CONVERTTEMPResult() function.

If your deployed web service operations don't take any pointers as input/output, don't return any pointers as output, and/or all parameters used are specifically allocated (defined) within your RPG program, then you most likely won't need to make use of any Axis_Delete_* functions located in the C stubs generated by the WSDL2RPG tool. It all depends on how you write your code.

Note you will always want to call the destroy function for the stub used within the client application. In this case it is this:
destroy_CONVERTTMPPortType_stub().

Ryan Watkins



On 10/27/2010 01:34 PM, Dan Kimmel wrote:
I don't think you need it in C. RPG doesn't handle java objects very well. The RPG program retains a reference to the object such that the garbage collecter can't clear it from memory. C can play around with the object without hanging on to a reference.

-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of James H. H. Lampert
Sent: Wednesday, October 27, 2010 2:44 PM
To: 'Midrange Systems Technical Discussion'
Subject: IWS (client) issue with "destroyResult" function

Fellow Geeks:

The "ConvertTemp" client example (from the IWS tutorial) provided (and
called) a procedure (actually, a C void function), "Axis_Delete_CONVERTTEMPResult" (renamed "destroyResult" in the RPG
source) to delete the "result" stored in the web service client engine, once the calling RPG program had read it.

But when I generated C stub source for our customer's web service, nothing remotely comparable was generated.

Can anybody explain what's going on? What (if anything) I need to do after calling the web service, in order to avoid creating memory leaks?

--
JHHL
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list To post a message email: MIDRANGE-L@xxxxxxxxxxxx To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx Before posting, please take a moment to review the archives at http://archive.midrange.com/midrange-l.




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.