× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



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



message: 2
date: Mon, 2 Nov 2009 10:41:23 -0500
from: MichaelQuigley@xxxxxxxxxx
subject: Re: [COBOL400-L] DFTACTGRP(*YES) vs ACTGRP(*Caller)

Jeff,

You're probably not going to like this.

First, calling an ILE program with ACTGRP(*CALLER) from an OPM program is
not a good idea. The reason you see one post say one thing and the next
another is that it depends. You can call the ILE program from OPM, but
don't use ACTGRP(*CALLER). If you run an ILE program in the default
activation group (i.e, *DFTACTGRP where OPM programs run), files are not
closed, storage is not released, and a whole bunch of other potential
problems are left waiting to happen. In general if your ILE program
doesn't open files, you can call it from OPM and be fine--just don't
compile your program with ACTGRP(*CALLER). Another thing to watch for is
if you expect certain working-storage items to be initialized when you
call the program, that may change with an ILE program running in a named
activation group. While you can get away with it at times, the general
recommendation is to avoid mixing ILE with OPM and to never call an ILE
program with ACTGRP(*CALLER) from an OPM program.

Michael Quigley

cobol400-l-bounces@xxxxxxxxxxxx



message: 3
date: Mon, 2 Nov 2009 11:19:34 -0500
from: Jon Paris <jon.paris@xxxxxxxxxxxxxx>
subject: Re: [COBOL400-L] DFTACTGRP(*YES) vs ACTGRP(*Caller)

"We are just going to start with one ILE program and one object and
then advance from there."

This is a really really bad idea and you could be in for a world of
hurt. One customer I worked with was forced to re-convert hundreds of
programs back to OPM COBOL because they could not architect their way
round the differences.

Read the ILE COBOL manual carefully. ILE COBOL is _not_ designed to be
used in this way. While they have made a few tweaks to the way ILE
COBOL works in a mixed environment it is still problematic. Once
you've read all of the pertinent stuff in the manual - read it again.

The differences and problems have been discussed at length in the past
in this forum and (I think) on Midrange-L. This thread is one
http://archive.midrange.com/midrange-l/200107/msg00628.html
one of many. This one, while ostensibly about performance also talks
to issues that can encompass file overrides and more.

This one http://archive.midrange.com/cobol400-l/200308/msg00001.html
and this http://archive.midrange.com/cobol400-l/200006/msg00017.html
also contain information that may be pertinent.

Simple summary. It is _much_ easier and safer to move an entire
system or subsystem from OPM COBOL to ILE than it is to do a piecemeal
conversion. To convert piecemeal means you have to thoroughly
understand both ILE and COBOL's Run Unit conventions. OPM and ILE
COBOL do not share the same run unit. As a result ILE calls OPM calls
ILE etc. can create some really weird situations. What works for a
single ILE program may not work when there are two ILE programs in the
mix.

Also beware of advice form people who's knowledge of ILE is limited to
RPG. Mixing OPM and ILE RPG is trivial and designed to work. Not so
with COBOL. Read, experiment, rinse and repeat.


Jon Paris

www.Partner400.com
www.SystemiDeveloper.com

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-2024 by midrange.com 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.