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



Okay, I've completely confused myself now.

I have values that I like to keep for an entire job, and values I like
to keep at a program level.  So, Program A calls Program B, and they
share a job level value J_SESSION, but each has its own program level
value, P_CALLLEVEL.

Typically, I have a separately bound program I call that keeps the job
level values, and I bind in a module to keep static variables at the
program level.  So, I have a program that returns J_SESSION, and both
Program A and Program B call it through an EXTPGM call.  However, each
has its own P_CALLLEVEL value, which it gets through an EXTPROC call to
a bound module.

In the world of service programs, can I emulate this?  Barring getting
into activation groups, it seems to me that the only way I can keep data
at the program level is by a module bound to that program.  It seems to
me that all calls to a service program from the same job regardless of
the opposition of the calling program in the call stack will always have
the same global variables.

As I look at this, it SEEMS as though activation groups might allow me
to do something.  If I put each program in the stack in its own
activation group and had one service program with a named activation
group and the other with an activation group of *CALLER, it seems that
the first service program's global storage would be shared among the
programs, while the second service program's variable would be unique
for each program.

That's a pretty elegant concept, although it does mean I have to have an
activation group for every level of my stack.  But in the great scheme
of things, that doesn't seem to be all bad.

Comments?

Joe


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.