RE: Passing a pointer between programs when using a dynamic call -- clarification attempt

Eric, Scott and Carel,

Sorry - I think I should have explained my problem much better. It's a long
story but basically an attempt to modernize an old application that
currently consists of large number of RPGIII programs. Let's say that every
program is a "product" and today they are called from other programs using a
different parameter list for every product. I referred to those as program B
in my original mail. We want to reuse as much as possible of those programs
and it is not possible to standardize on a general parameter list. They are
today outputting hardcoded html-strings. What I am trying to do is to have a
main program (Pgm A) that gets invoked every time and decides what type of
output we need ( being it html,xml or csv ). Then pgm A should call pgm B
with the specific parameter list corresponding to that particular pgm B (
hence the dynamic call using qcmdexec ).

Then we would have to modify every pgm B where html is outputted today with
a call to a couple of procedures in serviceprogram C that based on the rules
set by pgm A writes the correct type of output. But the procedures in srvpgm
C needs to know a lot of information currently set in a datastructure in pgm
A. My intention is to hide that datastructure and also try to eliminate a
recompilation of all program B's if/when the ds changes. That?s my
motivation for using a pointer.

So an invocation would looks like this
Wherever we come from we call PGM A that finds out what to do and builds a
datastructure of "rules". Then it looks up which pgm B to call and build the
needed parameter list and calls pgm B

Pgm B runs its business as usual - but output part is modified to use
procedures in srvpgm C to create the output.

The procedures in srvpgm C needs information from ds in pgm A on how to
format the output and where it should be written (preferably in dynamically
allocated memory ). There will be many calls to srvpgm C in every single
call to pgm B.

Alternative?
As an alternative I may use an temporary streamfile as output from the pgm C
procedures and parse that streamfile in pgm A upon return from pgm B. But
there is a large number of outputs and that streamfile can be pretty large
so I am a little bit concerned about performance.

Answers on questions raised after my first email:

"1) Why does PROGRAM A work this way? Why do you need so much flexibility
in terms of the parameter list? Do you work for a software house where your
software has to be able to call a customer's program with any arbitrary
parameter list? I can't think of any other reason someone would do
something like this."

I am working as a consultant, yes. It's a do or die issue for this system i.
The alternative would be a complete rewrite on a different platform ( read:
windows ).

"2) I don't understand the "Program C" business at all. If you're passing
the data via a parameter, how does a service program help? Why not pass the
data via the service program instead of the parameter list?"

My attempt is to hide the output complexity and try to minimize the
necessary changes in every pgm B. A procedure call seems to be a decent way
of doing that. Or- ah! - are you suggesting that pgm A calls a procedure in
srvpgm C with the pointer to ds as a parameter and then stores that pointer
in a static variable in srvpgm C - before calling pgm B?

"3) Why does a pointer need to be used to "connect" your programs?"

Perhaps my "Swedish in inglish" was too bad...too much surströmming.... What
I meant was that the output routines in srvpgm C needs information currently
available in a datastructure in pgm A.

" Oh, I forgot, "no procedure calls": the last and perhaps only resort might
be the good ol' LDA."

Interesting - can I use a part of the LDA to store a pointer to the ds in
pgm A and then use it as a basing pointer in the srvpgm C?

Summary:

Based on the input I've got so far it seems that the main problem is the
need for the call of pgm B with many different parameter lists.


Best regards and apologies for a lengthy mail which may make you even more
confused.....



Stefan Tageson

AddconIT AB

Cell : +46 (0) 732 36 99 34

stefan.tageson@xxxxxxxxxxx