RE: Private storage, static storage, bound modules and service programs

["Joe Pluta" <joepluta@xxxxxxxxxxxxxxxxx>]

> From: Jon Paris
> 
>> 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.
> 
> The biggest issue will be performance Joe.  AG creation while not the
> overhead of job creation is still significant.  Of course if your
design
> is such that the AGs get created at the beginning of the day and never
> get torn down until the user signs off - who cares.

> I can't help wonder if there isn't a simpler answer though.  For
> example why not have a single routine which is sensitive to the level
> of it's caller and automatically stores the appropriate values in an
> array indexed by level?

This is my first research into "service program enabling" some of my
standard architectures.  In a basic UI independent client/server
environment, I submit a job to batch which then makes requests to the UI
server.  Typically, I'll only have a single data queue (well, one in
each direction) for the communication.

However, let's take the case where I show the user a set of items
numbers, and they can then select multiple items to see the detail - a
standard subfile type of interaction.  Typically, Program A would send
the list to the servlet.  The servlet would display the items, get all
the selected items, then send those items back to Program A.

Here's where it gets tricky.  Program A reads Item 1 and calls Program
B.  Program B now starts a new conversation with the servlet.  However,
when it's done, I want Progrm B to return to Program A, and allow
Program A to pick up reading the next item in the queue.

To do this, I either must have another queue, or the queue must be keyed
by a request ID.  In my standard design, each program gets a key at
startup time, and this key is stored in a variable in a bound module
which is initialized when the program starts.  This key is in effect the
request ID.  The queue name, on the other hand, is stored in a
separately bound program called via EXTPGM and is shared by all
programs.

This allows each program to carry on a separate conversation, yet use
the same queue.  I do it this way to hide as much of the mechanism from
the application as possible, making it easier to change as circumstances
dictate.  Why hide the key?  I could of course just call a routine that
generates a key, store it in my program, and then pass it in on every
call to the send and receive APIs.  But that exposes the key to the
application and opens a point of failure, not to mention a point of
modification in every application if the size of the key, for example,
ever changes.  So I prefer to leave the inner working of the key process
to a bound module, and it works wonderfully.

Now I'm trying to see if there's a corresponding methodology in the
world of service programs.  It seems there may not be outide of AGs, and
the best I can do is a bound module that stores sensitive variables, and
then in turn invokes the service program.  This would in fact be the
"level sensitive" bit you mentioned, Jon.  It would simply act as a
delegate for the service methods, and add the hidden request ID to each
service program call as it passed through the bound module.

And maybe that's the design pattern I need to use for this sort of task.

Joe