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

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


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





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
or am I missing something since these manuals can be confusing :).

Take in consideration I am using example of ProgA (OPM) calls ProgB(OPM)

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
*DFTACTGRP activation group.

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

If the above conditions are not met, the OPM-compatible run unit
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
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
(*CALLER) should be fine

In ILE COBOL, the flow of control operations, CALL, CANCEL, EXIT
STOP RUN, and GOBACK, will cause the run unit to behave differently
OPM-compatible run unit is used.

-------This last statement is confusing, but I am thinking if I follow
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).

Jeff Buening

As an Amazon Associate we earn from qualifying purchases.

This thread ...


Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2022 by 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.