RE: Issue with ovrprtf/dltovr (is this an activation group issue)

Just a quick note on top of Scott's notes. The batch routing process
starts out in OPM compatibility mode. So if the first program you
submit is *CALLER, then your job stream is in OPM compatibility mode.
That means that default scope of the ovr and dltovr commands changes.
In OPM mode the default acts like *CALLLVL.

-----Original Message-----
From: rpg400-l-bounces@xxxxxxxxxxxx

[mailto:rpg400-l-bounces@xxxxxxxxxxxx]

On Behalf Of Scott Klement
Sent: Thursday, September 13, 2007 12:06 PM
To: RPG programming on the AS400 / iSeries
Subject: Re: Issue with ovrprtf/dltovr (is this an activation group

issue)

Hello,

With a batch job, the program is in memory and is released when the

job

ends.
With an interactive job, it is in memory until the program ends.

That's not true. Interactive and batch work the same. But, perhaps

you

use a different paradigm when you write your batch jobs from your
interactive jobs?

OPM programs, or OPM-compatible ILE programs will be unloaded from
memory when the program ends (or in RPG, when they end with *INLR=ON)

ILE programs (not in OPM-compatible mode) will be unloaded from memory
when the activation group ends. (Activation groups are sub-sections

of

a job -- so when the job ends, the activation group also ends.)

ILE programs that are compiled with DFTACTGRP(*YES) will be in
OPM-compatibility mode, and will behave like an OPM program.

ILE programs that are compiled with DFTACTGRP(*NO) will act like real
ILE programs. (Even if they run in the default activation group via
ACTGRP(*CALLER))

Frustratingly, the DFTACTGRP parameter is mis-named. Sure, when you

set

DFTACTGRP(*YES), it puts the program in the default activation group,
but it also changes the way it behaves -- it changes it to behave like
an OPM program. When you specify DFTACTGRP(*NO) it may still run in
the default activation group (via ACTGRP(*CALLER), that is) so it
doesn't really mean that it's not in the default activation group.

But,

what it does mean is that it will act like an ILE program. (Which is
why you need DFTACTGRP(*NO) to use ILE features like procedures)

I wish they had named this parameter OPMCOMPAT() instead of

DFTACTGRP(),

because of the confusion it causes.

But anyway, it's not a difference between interactive and batch, it's

a

difference between DFTACTGRP(*YES and *NO). Plus, the fact that batch
jobs tend to run, and then end immediately, whereas interactive

programs

tend to be started once, then re-used for many tasks...
--
This is the RPG programming on the AS400 / iSeries (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.