Michael and Jon,
Thanks for all your help. I think I am understanding it after
reading parts of the manual, this list, and websites. A couple final
thoughts I have.....
<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."
- - - - -This is what I don't understand, why couldn't it of been made
simple, If you use *CALLER with CRTBNDCBL cmd all the things that get
"de-activated" in OPM would get deactivated in the ILE program that use
*CALLER? Seems like an easier transition to ILE. I want applications that
use that sub-program and I am not changing to work exactly like the OPM
way. But it looks like I have to make a more program changes to
"de-activated" the sub-program I moved to ILE. :(..
<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.
- - - - - One thing our sub-programs are doing is and Open and close on the
files, not saying this is the best way just how they are. Or have no files
just reformatting text and such. So that is what you mean by not leaving
the file open (there isn't some behind the scenes RCLRSC that needs done)?
<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.
- - - - - - So since these sub-programs are used throughout the system I
will need to add a RCLACTGRP everywhere just to get my one application
switch to ILE or make and ILE version of the sub-programs for my
application? This all seems to go against the KISS principle if you ask
me.
Thanks,
Jeff Buening
message: 1
date: Tue, 3 Nov 2009 14:54:12 -0500
from: MichaelQuigley@xxxxxxxxxx
subject: Re: [COBOL400-L] DFTACTGRP(*YES) vs ACTGRP(*Caller)
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
midrange.com
