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


  • Subject: RE: MODS in subprocedures
  • From: "Phil" <sublime78ska@xxxxxxxxx>
  • Date: Tue, 8 May 2001 21:07:26 -0400
  • Importance: Normal

Thanks.

I think static is what I was looking for.

Phil

-----Original Message-----
From: owner-rpg400-l@midrange.com [mailto:owner-rpg400-l@midrange.com]On
Behalf Of Scott Klement
Sent: Tuesday, May 08, 2001 6:26 PM
To: RPG400-L@midrange.com
Subject: Re: MODS in subprocedures


Phil,

Please make sure you understand how memory allocation works in a
subprocedure:

     1)  When the subprocedure starts, memory is allocated for each
            of the local variables.  (in your case, #p_rscDS)
     2)  This memory is available while the subproc is running.
     3)  When the subproc ends, all the memory for local variables
            (unless declared as "static") is de-allocated, so that
             the system can use them again.

So, when your calling subprocedure calls getResources, it allocates
100 bytes of memory to #p_rscDS.   p_rscDS and resourceDS are given the
address of that 100 bytes that's been allocated.

When your subproc returns, that address is passed back to the calling
procedure -- and at the same time -- is made available to the system
to use to store other things.

Sometimes, the system actually uses it right away (and then you get
"garbage")  Sometimes, as luck would have it, it's not used immediately.
When that happens (you were LUCKY) you get what you were expecting.

The solution is to make #p_rscDS static by putting the static keyword
on your D-spec:

D #p_rscDS        s            100   static

(I'm also questioning all the extra pointer stuff you're doing here...
seems like you're adding extra complexity -- but I'll assume that theres
more code that I'm not seeing that requires this extra complexity)



On Tue, 8 May 2001, Phil wrote:

> I sometimes (but not every time) have this problem.
>
> I am returning a pointer to a MODS in a sub procedure.  Sometimes the data
> is valid - what I expect - and sometimes the data is garbage.
>
> Here's a bit of my code (they are SQLRPGLE members)
>
> H nomain
>  *------------------
> D getResources    pr              *
> D  pr_rsctyp                     1    value
> D  pr_key                        9  0
> D  pr_rows                       5  0
>  *------------------
> P getResources    b                   export
> D getResources    pi              *
> D  rscType                       1    value
> D  key                           9  0
> D  rows                          5  0
>  *------------------
> D resourceDS      ds                  occurs(dsSize) based(p_rscDS)
> D  resource               1     10
> D p_rscDS         s               *   inz(%addr(#p_rscDS))
> D #p_rscDS        s            100
>
> C                   clear     *all          resourceDS
> C** build the data structure here **
> C                   return    p_rscDS
>
> This is a snip from the calling subprocedure:
> D getResources    pr              *
> D  pr_rsctyp                     1    value
> D  pr_key                        9  0
> D  pr_rows                       5  0
> D p_rscDS         s               *
>
> C                   eval      p_rscDS = getResources('T':key:rows)
> C
> C                   for       i = 1 by 1 to rows
> C     i             occur     resourceDS
> C                   endfor
>
> The address for p_rscDS is the same.  But the value contains garbage data.
>
> Can anyone see what am I doing wrong here?
>
> Thanks for your help,
>
> Phil
>
>

+---
| This is the RPG/400 Mailing List!
| To submit a new message, send your mail to RPG400-L@midrange.com.
| To subscribe to this list send email to RPG400-L-SUB@midrange.com.
| To unsubscribe from this list send email to RPG400-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator:
david@midrange.com
+---


_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com

+---
| This is the RPG/400 Mailing List!
| To submit a new message, send your mail to RPG400-L@midrange.com.
| To subscribe to this list send email to RPG400-L-SUB@midrange.com.
| To unsubscribe from this list send email to RPG400-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@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.