I'm not an ILE expert by any means. But, looking at the example, if the
first CALL PGMB doesn't crash and burn, why would one expect the second CALL
PGMB to fall over? The second CALL, if I'm right (and that's a long shot,
admittedly), would just have to re-initialize everything it needs from
ground zero.
Jerry C. Adams
IBM i Programmer/Analyst
Good pitching will always stop good hitting and vice versa. -Casey Stengel
--
A&K Wholesale
Murfreesboro, TN
615-867-5070
-----Original Message-----
From: rpg400-l-bounces@xxxxxxxxxxxx [mailto:rpg400-l-bounces@xxxxxxxxxxxx]
On Behalf Of LuisMaldonado
Sent: Friday, March 04, 2011 9:06 AM
To: RPG programming on the IBM i / System i
Subject: RE: RPG ILE Problems (Activation Groups)
Hi,
I create a module CRTRPGMOD X
Then I create the service program:
CRTSRVPGM X EXPORT (*ALL) ACTGRP (*CALLER)
Then I execute this CLLE:
CALL PGMB (this RPGLE uses the service program x)
RCLRSC
CALL PGMB (this RPGLE uses the service program x)
If I understood well the second call to PGMB must crash !!!!!
No problem occurs, Why?
Thank you.
Lluis
________________________________________
De: rpg400-l-bounces@xxxxxxxxxxxx [rpg400-l-bounces@xxxxxxxxxxxx] en nombre
de Charles Wilt [charles.wilt@xxxxxxxxx]
Enviado el: viernes, 04 de marzo de 2011 14:23
Para: RPG programming on the IBM i / System i
Asunto: Re: RPG ILE Problems (Activation Groups)
Comments inline
On Thu, Mar 3, 2011 at 4:05 PM, Buck <kc2hiz@xxxxxxxxx> wrote:
dftactgrp(*yes) is an OPM compatibility mode. It lets us convert our
RPG III syntax programs to RPG IV and will run it as if it were OPM.
That's pretty neat because we get to use long variable names, big arrays
and all that. But if we want to use a sub-procedure, we must leave OPM
compatibility mode for true ILE mode. For the sake of convenience we
call this the default activation group (DAG).
True ILE mode programs shouldn't be in the DAG, the DAG is only for
OPM or OPM compatible programs created with DFTACTGRP(*YES)
An override touches all
programs, storage is freed and files closed when each program ends
(depending on LR). Every program shares with all the rest in that job.
This true only if the DAG is the only activation group in use... if
you have a true ILE program running in a named or *NEW activation
group it's resources are separate.
When *CALLER is used and the top menu is an OPM program, we have told
the system to run an ILE program in OPM compatibility mode.
The only thing that controls rather or not an RPGIV program is running
in OPM-compatible mode is DFTACTGRP(*YES)
It will
activate in the DAG OK, storage will initialise, files open, code will
run. When LR comes on though, strange things happen. The program comes
off the call stack but storage is not freed. RPG closes the files and
the program seems to have finished. But when you call it again, it is
already activated, and does not go through the full activation process
again. In particular, it doesn't reinitialize the internal static
storage, which usually is not a problem for a *PGM object.
(Basically?) True for DFTACTGRP(*NO) ACTGRP(*CALLER) when called from
the command line or other OPM (or OPM mode) program. The easiest
problem to manifest is when such program ended with LR = *OFF, and a
RCLRSC command is used, the reclaim won't clean it up properly. In
particular, the files will be closed but the program will still be
activated and expect it's files to be open. In fact, the %open() bif
will return that the files are open when in fact they aren't
(completely) and the program will crash with a CPF error.
I think there are some other glitches...perhaps Barbara or Scott can
elaborate.
But the point is that having a ILE mode program, DFTACTGRP(*NO),
running in the DAG by virtue of ACTGRP(*CALLER) can cause problems and
should be avoided.
Charles
--
This is the RPG programming on the IBM i / System i (RPG400-L) mailing list
To post a message email: RPG400-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit:
http://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at
http://archive.midrange.com/rpg400-l.
midrange.com
