Re: DFTACTGRP(*YES) vs ACTGRP(*Caller) -- COBOL400-L

Excellent summary Michael.

As I have often said - the problem with mixing OPM and ILE is that you have to know far more about both than you need if you simply convert all to ILE!

The only point I would add is that the real killer is multiple boundary crossing i.e. OPM calls ILE calls OPM calls ... That is guaranteed to bite you in the ...

About the _only_ mix I would even think about risking is the simple one you describe where OPM calls ILE and ILE returns to OPM. Preferably no files in the ILE code, and it is deactivated by calling RCLACTGRP from OPM when you are done.

Jon Paris

www.Partner400.com
www.SystemiDeveloper.com

On 3-Nov-09, at 2:54 PM, MichaelQuigley@xxxxxxxxxx wrote:

Jeff,

Jon--please correct me if I'm inaccurate on this or inadequate in my
explanation.

The statement in the manual "...unless an OPM-compatible run unit is
used." has always confused me. I guess it's still due to the whole "it
depends" logic I originally mentioned earlier. If I understand things
correctly, you won't get burned under a very specific set of circumstances
"ProgB(OPM) calls ProgC(ILE)(ACTGRP(*CALLER))". The challenges involve
the way program activation is handled. Once your application does execute
a STOP RUN, your OPM programs are in essence de-activated. Storage is
released, any open data paths are destroyed (i.e., files are closed), and
some other housekeeping tasks are performed. However, not all this
happens for the ILE program. Where you can get in trouble is if you end
up calling ProgC(ILE)(ACTGRP(*CALLER)) again. Some of the normal
activation processes for that program have already taken place and were
not "de-activated."

I personally would try to avoid it--as Jon stated, "you could be in for a
world of hurt." You may want to review the ILE Concepts manual regarding
reclaiming resources. That's what got me looking at the differences in
recovering open data paths and static storage. This said, if you don't
leave any files open in ProgC and don't take the initial values of any
variables for granted, you *may* be able to get away with calling ProgC
the way you describe.

What I've done is set up ProgC to use a special named activation
group--something such as 'CELINAUTIL'. Then when I know I've completed
any calls to it--such as when you do the STOP RUN in ProgA--I reclaim the
activation group. When I do a call to it from ProgB(ILE), ProgC still
runs in ACTGRP(CELINAUTIL). There's a slight performance penalty the
first time the system creates the activation group, but to me it's worth
it to avoid the potential pitfalls. Of course if you code to verify the
initialization of all your variables on each call, you can leave the
activation group active (is that redundant?) and the calls should always
be pretty fast.

Generally, programs do not *have* to be in the same activation group
unless you want to be able to end the run unit from a sub program. (It is
interesting, but you can destroy the entire activation group with a STOP
RUN in a sub-program.)

Michael

cobol400-l-bounces@xxxxxxxxxxxx wrote on 11/03/2009 01:00:11 PM:

----- Message from Jeff Buening <JeffBuening@xxxxxxxxxxxxxxxxxxx> on
Tue, 3 Nov 2009 10:37:35 -0500 -----

To:

cobol400-l@xxxxxxxxxxxx

Subject:

Re: [COBOL400-L] DFTACTGRP(*YES) vs ACTGRP(*Caller)

Below is out of the ILE V5R3 manual about preserving Run Unit in a Mixed
OPM ILE Cobol App. I make comments after each point, is my logic

correct

or am I missing something since these manuals can be confusing :).

Take in consideration I am using example of ProgA (OPM) calls ProgB(OPM)
calls ProgC(ILE)(ACTGRP(*CALLER))

Preserving OPM-compatible Run Unit Semantics in a Mixed OPM COBOL/400
and ILE COBOL Application: :

1 OPM COBOL/400 program?s invocation (not ILE COBOL?s) must be the first
COBOL invocation

--------So OPM in my example is the first COBOL invocation

2 STOP RUN is issued by an OPM COBOL/400 program

--------So my ILE program shouldn't have STOP RUN in it

3 All participating programs in the (OPM COBOL/400) run unit must run in
the
*DFTACTGRP activation group.

--------So using ACTGRP (*CALLER) on the ILE program will keep all in

the

*DFTACTGRP

If the above conditions are not met, the OPM-compatible run unit

semantics

is not
preserved for OPM/ILE mixed application. For example, if an ILE COBOL
program is running in the *DFTACTGRP and it issues a STOP RUN, both the
OPM

COBOL/400 and ILE COBOL programs will be left in their last used state.

--------So If I don't have STOP RUN in the ILE program that is using

ACTGRP

(*CALLER) should be fine

In ILE COBOL, the flow of control operations, CALL, CANCEL, EXIT

PROGRAM,

STOP RUN, and GOBACK, will cause the run unit to behave differently

unless

an
OPM-compatible run unit is used.

-------This last statement is confusing, but I am thinking if I follow
the

3 points above my example is OPM-compatible run unit so GOBACK CALL EXIT
PROGRAM etc... should work fine except don't use STOP RUN in the ILE
program that is ACTGRP(*CALLER).

Thanks,
Jeff Buening

--
This is the COBOL Programming on the iSeries/AS400 (COBOL400-L) mailing list
To post a message email: COBOL400-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/cobol400-l
or email: COBOL400-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/cobol400-l.