Service program to use temporary storage

[HMiller]

Hello,
I have a service program which is called thousands of time.

I did set H-SPECS as below

h nomain
h thread(*serialize)
/include qsrc,hspecs
h bnddir('BMS71L_BND')
h alloc(*teraspace)

and added DEALLOC in order to free up memory.

p PR004_getCosto...
p b export
*
* INTERFACE
* ---------
d PR004_getCosto...
d pi *
d p_cazi 3 const
d p_cstb 10 const
d p_cass 20 const
d p_cica 4 const
d p_csog 6 const
d p_tpcos 2 const
d p_dtiv d const
*
* DATA STRUCTURES
d PR004_Costi ds inz
d ds_livello 20
d ds_tprec 3
d ds_lgcass 20
d ds_lgqtcu 12 6
d ds_lgqtcl 12 6
d ds_lgccmpd 40
d ds_lfumtm 2
d ds_lcumft 2
d ds_lfclav 3
d ds_lfines 1
d ds_lfcatg 6
d ds_QtaFab 15 6
d ds_costoUni 12 6
d ds_costoMat 12 6
d ds_costoMan 12 6
d ds_costoExt 12 6
d ds_costoTot 12 6
d ds_pctInd 5 3
d ds_costoInd 12 6
d ds_costoIle 12 6

* STANDALONE FIELDS
d dsCosti s Dim(32767) like(PR004_costi)
d pDsCosti s * inz(*null)
d pDsCosto s * inz(*null)
d i s 5i 0

* CONSTANTS
d APEX C CONST('''')
d COSPL C CONST('COSPL')
d LAVOR C CONST('LAVOR')

/Free

lastIndex = 0 ;
dealloc(n) pdsCosto;
dealloc(n) pdsCosti;
PR004_openfiles();



My problem is that every time I call procedure PR004_getCosto the temporary storage increases even if I DEALLOC memory.
The attached wrkactjob image shows that temporary storage is not 26914M which is huge.
I tried to add RTNPARM value in the procedure interface but I didn't see any benefit.
I would like to know how to handle this memory issue.
best regards,
Giovanni

[JonBoy]

1) I don't see the point of DeAlloc - there is no storage being allocated. Unless you're not showing all the code in which case please do. Which brings me to

2) Please use code tags around your source code. Right now it is almost impossible to read and I don't have time to copy/paste/edit is elsewhere just to try and understand what is going on.

3) RTNPARM is not going to do a thing because all you are doing is returning a pointer - which in itself is a dangerous thing most of the time. Since you haven't shown us the return operation ...

4) I see that you appear to be opening files. IFS files? Are they being closed?

[HMiller]

Hello,
thank you for your reply.
I attach full source code.
I am invoking PR004_GETCOSTO PROCEDURE and not opening IFS files.

[HMiller]

Hello,
thank you for your reply.
I attach full source code.
I am invoking PR004_GETCOSTO PROCEDURE and not opening IFS files.

[JonBoy]

Can you tell me _why_ you are returning pointers? I haven't gone through the code in great detail but I can see several potential problem areas. If I understood what you were trying to do, and specifically why the use of pointers, I might be able to debug more easily since obviously I cannot run your code.

[HMiller]

Hello,
I use pointers because they are very fast and when I call PR004_GETCOSTO procedure for a single item in interactive 5250 session it's incredibly fast.
PR004_GETCOSTO procedure is a BOM explosion up to 30 nested levels and for each level it retrieves the average production cost in real time by reading inventory transactions.
The issue is during end of month jobs where I retrieve quantity on hand for each item in the warehouse and for each item (usually 20.000 items) I call PR004_GETCOSTO procedure to get the unit item cost in order to have the whole figure af the items in stocks.
In both processes (interactive and end of month) the memory is not deallocated , but while in the interactive process the user requests are very few so the temporary storage usage is not very high, the problem arises during the end of month process.
If you suggest , I can try to remove pointers and return a data structure.
Best Regards,

[JonBoy]

If you use RTNPARM then the "returned" value _is_ represented by a pointer. And that pointer's "home" is the calling routine so there is no danger of orphaned storage which I'm pretty certain is what you are seeing.

RTNPARM effectively passes the result fiels as the first parameter on the call. It is the same as if you had no return value but returned the result in the first parm. So it is every bit as fast as receiving a pointer without the risk.

If I can find the time I'll look further into your code and try and tie it down further but because storage associated with a subprocedure (unless declared as STATIC) is always released when the subprocedure returns to its caller relying on a returned pointer can be a very risky process. RTNPARM is designed for the issue you face - and using it would also make your Service Program usable by (say) IWS to present the data as a web service.