RE: Activation groups for beginners

[Buck Calabro <Buck.Calabro@xxxxxxxxxxxx>]

I've been thinking about applications that are being migrated from OPM to
ILE, and done gradually; not converted en masse.  Perhaps that's a poor
assumption on my part.  Since that's what I've been doing, I'll stay with
that viewpoint for at least another post...

OPM behaviour.  Everybody understands it, right?

MENUCL
  IF OPTION = 01 (CALL GLCL)
  IF OPTION = 02 (CALL APCL)
...

GLCL
  OVRDBF VENDOR SHARE(*YES)
  OVRDBF GLMAST SHARE(*YES)
  OPNDBF GLMAST
  OPNDBF VENDOR
  ...
  IF OPTION = 01 (CALL BALSHT)
  IF OPTION = 02 (CALL CHTACCTS)
...

APCL
  OVRDBF POMAST SHARE(*YES)
  OVRDBF VENDOR SHARE(*YES)
  OPNDBF POMAST
  OPNDBF VENDOR
  ...
  IF OPTION = 01 (CALL VENMAINT)
  IF OPTION = 02 (CALL POINQ)
...

Scenario 1: User signs on, gets the main menu and goes into the G/L system.
They choose option 2 to see the chart of accounts.  That program has
F22-Work with vendors (users have funny requests!)  They press (never hit!)
F22 and go to VENMAINT.  Since GLCL opened the VENDOR file and has
SHARE(*YES) specified, when VENMAINT opens the file, it'll be positioned
wherever CHTACCTS left it.  That means the programmer can never be sure
where the file pointer is, so she has to be sure to reposition it in
VENMAINT.  Not generally a problem, because the first thing VENMAINT does it
ask for a vendor number.

The SHARE(*YES) isn't part of the application, as much as a performance
enhancement.  The actual records are not shared between CHTACCTS and
VENMAINT.  That's a key observation.  No real sharing.

Scenario 2: User signs on, does scenario 1 and then goes back to the menu.
After lunch, she goes into the A/P menu to do some work.  In the course of
that, she takes option 1 to run some more vendor maintenance.  VENMAINT gets
a shared open because APCL opened the file and specified SHARE(*YES).

Now convert this entire application to ILE.  GLCL and APCL are compiled
AG(*NEW), all the other programs are compiled AG(*CALLER).

Scenario 1:
GLCL - AG(AG1)
  CHTACCTS (AG1)
    VENMAINT (AG1)
When VENMAINT opens VENDOR, it's a shared open, just like the OPM example.
It happily repositions the file just like before.  Functionality identical.

Scenario 2:
GLCL - AG(AG1)
  CHTACCTS (AG1)
    VENMAINT (AG1)
APCL - AG(AG2)
  VENMAINT (AG2)
When VENMAINT opens VENDOR, it's a shared open with the other A/P programs
but NOT shared with the G/L open.  Since VENMAINT always positions the file
itself, this isn't a functionality problem, but what happened to the
performance benefit of the shared ODP?  We'll share with A/P but not with
G/L.

Okay, back up a step.  When this entire thing gets converted to ILE, make
GLCL and APCL AG('QILE') or maybe AG('MYCOMPANY').  Run the scenarios again:

Scenario 1:
GLCL - AG(MYCOMPANY)
  CHTACCTS (MYCOMPANY)
    VENMAINT (MYCOMPANY)

Scenario 2:
GLCL - AG(MYCOMPANY)
  CHTACCTS (MYCOMPANY)
    VENMAINT (MYCOMPANY)
APCL - AG(MYCOMPANY)
  VENMAINT (MYCOMPANY)

All the programs are now running in the same AG and therefore share
resources.  All the opens of VENDOR are shared.

Okay, back up again.  Don't convert every program at once; let's just do
VENMAINT for now.  Make it AG('MYCOMPANY')  Run the scenarios:

Scenario 1:
GLCL - AG(DAG)
  CHTACCTS (DAG)
    VENMAINT (MYCOMPANY)

Scenario 2:
GLCL - AG(DAG)
  CHTACCTS (DAG)
    VENMAINT (MYCOMPANY)
APCL - AG(DAG)
  VENMAINT (MYCOMPANY)

VENDOR is opened by an OPM program and SHARE(*YES) specified, so the OVRDBF
percolates through to AG('MYCOMPANY')  The original OPM behaviour and
performance is maintained.  Each time VENMAINT opens VENDOR, it'll be a
shared open.  The expectation is that the OPM programs are already doing
implicit sharing among themselves, just at the job level instead of the AG
level.

In this scheme, AG('MYCOMPANY') would never be destroyed - having the job
end (user sign off) would take care of that.

Note that this implicit sharing can be a pain - that you Really Truly Wish
you could have the A/P programs share amongst themselves and never overlap
with the G/L programs.  That's where *NEW/*CALLER shines!

I've been using a shared ODP for my example, but commitment control works
fundamentally the same way.  As do program activations.