× 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: Automatic Storage for Global RPGLE Variables?
  • From: "Jerry Jewel" <jerryjewel@xxxxxxxxx>
  • Date: Fri, 15 Jun 2001 12:05:22 -0700


Scott,

Thanks for your feedback!  You have correctly read between the lines.  Your 
suggestion sounds like a good direction.

Some additional info and to complicate things a bit... my global control values 
already reside in four data structures -- three of them are multiple occurance.


A couple of followup questions to be certain I understand this approach:

o  Will I will need to execute an ALLOC (in 3b of your description) to set 
asside the storage?

o At the risk of getting into a heap of trouble, I'll ask:  When you said 
"Here's a way that pops into mind... ...The idea is that you're creating a 
"stack" of global variables".  Did you mean to push a questionable pun on us?  
;-)


Regards,
Jerry


"Better living through fine code and hot coffee!"
mailto:jerryjewel@email.com



-----Original Message-----
From:    Scott Klement klemscot@klements.com
Sent:    Thu, 14 Jun 2001 16:17:05 -0500 (CDT)
To:      RPG400-L@midrange.com
Subject: Re: Automatic Storage for Global RPGLE Variables?



It sounds like you want to create a separate instance of each of your
global variables each time your "MakeXXXX" procedure is called, am I
correct?

Based on the fact that you believe ACTGRP(*NEW) will work, it sounds like
you want the global variables to work in "levels", i.e. each time your
MakeXXXX routine is called, it makes a new "level" and at some point when
you decide you're done, it shifts back to the previous level?

Here's a way that pops into mind:

1) define a global data structure that contains all of your global 
    variables, plus have an extra variable in it, a "previous
    instance" pointer.

2) The data structure described in step #1 should also be BASED() on
    a pointer.  The pointer that it's based on should be initialized
    to *NULL when the program starts.

3) When MakeXXXX is called, it:
     a)  a pointer defined as "local" to MakeXXXX is set to the
         same address as the pointer described in #2.
     b)  An area of memory the size of your global data structure
         is now assigned to the pointer from step 2.
     c)  Values in your data structure are initialized to their
         start values for this invocation.   The "previous 
         instance" pointer is set to the address stored in the
         local pointer described in step 3a.

4) When you're done using this "instance" of the global vars and
    want to back down to the previous level, you need to:
     a) Set a local variable equal to the address of the 
         "previous invocation" from your data struct.
     b) Call DEALLOC on the pointer described in step #2.
     c) Set the pointer from step #2 to the local pointer
         described in step 4a.

5) Naturally, when the pointer from step #2 is set to *NULL,
      you know you've ran out of instances...

The idea is that you're creating a "stack" of global variables in
memory.   Each time MakeXXXX is called, you ask the system for new
memory to store your global data in.   Each time you're done with
that data, you fall back to the previous level's data.

It's a lot easier to do than it is to describe :)

Hope that helps....

On Thu, 14 Jun 2001, Jerry Jewel wrote:

> 
> How can I define or simulate having global variables behave as if they
> are defined in automatic storage instead of static storage?  In other
> words, how can I get my service program's global variables to exist
> only for a particular invocation of my service program?
> 
> There must be an elegant (or maybe even obvious) way to do this that I
> am missing.  The best I can come up with is:
> 
> 1) use ACTGRP(*NEW) on a module I will execute many, many, times
>       OR 
> 2) pass an unweildy number of parameters to each procedure in
>    my service program
> 
> Here are a few more details:  I am writing an RPGLE service program
> that does some complex string evaluation and returns a result.  It
> contains about a dozen procedures.  These procedures share several
> controlling global variables that are set when I execute a MakeXXXX
> setup procedure.  My problem is that on the more complex string
> expressions, I need to recursivly execute the MakeXXXX and other
> procedures.
> 
> Am I missing the forrest for the trees?  Any suggestions?
> 
> Regards,
> Jerry Jewel
> 



___________________________________________________________________________
Visit http://www.visto.com/info, your free web-based communications center.
Visto.com. Life on the Dot.

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

Follow-Ups:

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.