Re: share variable between programs thru static pointer in export procedure

Hello,

On 6/13/2011 11:27 AM, Lim Hock-Chai wrote:

I've a program, PROGRAMA, that accepts two entry-parms. This program
calls PROGRAMB, which in turn calls PROGRAMC. I've a need to change
PROGRAMC to now call PROGRAMD. However, PROGRAMD, which is an existing
program, already has code to call PROGRAMA. Of course, the causes the
recursive call problem.

Errr, okay. The obvious question is... WHY? What does PROGRAMA do that causes the need to call (ultimately) PROGRAMD? What does PROGRAMD do that it needs to call PROGRAMA?

What are the roles of these programs in the overall system architecture?

I've a wild idea to resolve this recursive problem and want to see
what's your opinion about this:
The reason that PROGRAMD needs to call PROGRAMA is becuase it needs a
value on the PROGRAMA's entry-parms, which is already populated by
PROGRAMA by the time PROGRAMD is called.

That's a very vague description.

My idea is to create an export procedure in a service program. This
procs will accepts the PROGRAMA's two entry-parms by reference. The
main code in this service program is to create a static references to
these two entry-parms. I can then change PROGRAMD to call this proc to
get the value it needs thru these static references. I know is a bit
confusing. May be code below and clear up a bit:

Is there some reason you actually need to keep track of their memory locations? i.e. why not copy the values into the service program with a "setter", and then retrieve those values with a "getter"? It seems silly (IMHO) to keep track of the addresses where the data is stored in memory -- unless you have a really good reason to do that?

It really depends on what these parameters are for... should they be settings in a configuration file? Or environment variables that pertain to the current environment? Or maybe a data area or user space in QTEMP? Really depends on the purpose of these variables.

IMHO, you should have a single interface for setting these, and a single interface for retrieving these. You should be able to change the underlying implementation without affecting anything else -- the callers shouldn't know or care of the properties are stored. And that's the problem with the shared address technique you're proposing... it exposes them to any sort of access. There's no control.

That's the same problem with using IMPORT/EXPORT on variables in a program. You have no control over how they are used, etc. It's no different here...