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



On 2-Nov-09, at 8:36 AM, Jeff Buening wrote:

Thanks for you input Tom.

You can only create one ProgramB in a given library no matter what.
You can't just "create duplicate programs". Of course, if you're
willing and able to run your source through the two compilers to
create programs in two libraries and qualify your CALLs or
manipulate your library lists...?

Tom,
I was thinking changing the name of each of the ProgramB for ILE and
the calls to point to that which would created duplicate programs in the
same library but different names (OPM named "XYZ" and ILE named "XYZILE").
But this seems like alot of work and (maintenance nightmare) an I think
using the *Caller seems like a better way.

Note that similar considerations will apply to COBOL as to RPG,
e.g., overrides should have appropriate scoping when additional
activation groups get involved. I haven't run into anything major
myself, but all of the COBOL programs in the past 15 years or so
have been single-purpose and wholly self-contained with no external
dependencies.

We are just going to start with one ILE program and one object and then
advance from there. I have been reading about the overrides issue and the
applications I am starting with starts from a CL call (batch jobs). I have
noticed that if I take the default of CRTBNDCL which sets DFTACTGRP
(*YES)(OPM Compatible) that the OVRDBF uses call level so as long as
everything called after that is in the same named activation group, I
should be fine(similar to how our OPM works today). Does my logic sound
correct or am I missing something there?

Thanks,
Jeff Buening




From: cobol400-l-request@xxxxxxxxxxxx

To: cobol400-l@xxxxxxxxxxxx

Date: 11/01/2009 01:06 PM

Subject: COBOL400-L Digest, Vol 7, Issue 46







1. Re: DFTACTGRP(*YES) vs ACTGRP(*Caller) (Tom Liotta)

----------------------------------------------------------------------

message: 1
date: Sun, 01 Nov 2009 01:46:24 -0700
from: Tom Liotta <qsrvbas@xxxxxxxxxxxx>
subject: Re: [COBOL400-L] DFTACTGRP(*YES) vs ACTGRP(*Caller)

Jeff Buening wrote:

Programs compiled with DFTACTGRP(*YES) do not behave the same as
ACTGRP(*CALLER), even if the ACTGRP(*CALLER) program was called from

the

default activation group. This is because specifying DFTACTGRP(*YES)

does

more than control which activation group the program is compiled into,
it also controls some other OPM compatibility things.

Jeff:

Since I haven't seen other responses, I'll comment to give others a
chance to disagree or elaborate.

I have no direct info, but I've gotten the impression that some of
the "other OPM compatibility things" are more important to older RPG
programs than COBOL. Files, for example, would be opened and closed
by Cycle code in RPG and LR had meaning for files in Cycle programs.
OTOH, COBOL had nothing like the RPG Cycle and how opens/closes
would be implicitly handled.

So, COBOL has a number of very different issues to deal with --
COBOL run units would seem to be a primary item. (And I'm not clear
how they've been affected.)

I have seen post that say DFTACTGRP(*YES) was to help RPG programs

convert

to ILE with out all the goodies of ILE, but still use SEP, content assist
etc.. CRTBNDCBL for cobol does not have a DFTACTGRP parm just ACTGRP

parm.

So can I assume using ACTGRP(*CALLER) in cobol is similar to the

DFTACTGRP

(*YES) that RPG has? Not sure what the other compatibility things are?

I would think that ACTGRP(*CALLER) for COBOL would be more like
ACTGRP(*CALLER) for RPG than like DFTACTGRP(*YES).

IMO, if you want full OPM compatibility, use the OPM compiler...
just as could be done with RPG. I don't think the differences in the
COBOL compilers are as significant as for RPG.

If I have Cobol "Program A" calls "Program B" and "Program B" is a

program

that gets used all throughout the system not just in my "Program A" Call
"Program B" application. If I am changing just my application to ILE

would

making "Progam B" ACTGRP(*Caller) be the way to go since other

applications

that are still ALL IN OPM COBOL will still be calling "Program B"? Has
anyone done something similar and sees issues with this thinking, because
one post will say one thing and the next another? Or did you create
duplicate programs one for ILE and one for OPM?

You can only create one ProgramB in a given library no matter what.
You can't just "create duplicate programs". Of course, if you're
willing and able to run your source through the two compilers to
create programs in two libraries and qualify your CALLs or
manipulate your library lists...?

In any case, I suspect that you simply want to compile as
ACTGRP(*CALLER) if you're going to use the ILE compiler.

Note that similar considerations will apply to COBOL as to RPG,
e.g., overrides should have appropriate scoping when additional
activation groups get involved. I haven't run into anything major
myself, but all of the COBOL programs in the past 15 years or so
have been single-purpose and wholly self-contained with no external
dependencies.

Tom Liotta

--
Tom Liotta
The PowerTech Group, Inc.
19426 68th Avenue South
Kent, WA 98032
Phone 952.563.2757
http://www.powertech.com


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