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



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

As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:
Replies:

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.