RE: OVRMSGF and QCMDEXC procedure

We just got done fighting this one. It's one of the only things
preventing us from moving more stuff to *CALLER and separating into
activation groups. QCMDEXC is wrapped into a procedure that returns CPF
messages etc.

PGM A calls PGM B (does override via QCMDEXC) calls PGM C (uses
override)

Sometimes PGM A calls PGM B interactively, sometimes it submits PGM B.
IF A, B and C are in named activation groups (QILE in this case) every
thing works fine both ways. If B and C are *CALLER, it fails in batch
because of the scope and the fact that batch are running in *DFTACTGRP.
A always ends up in a named as it picks up an activation group off the
menu that calls it, so interactively *CALLER works. Unfortunately, we
don't have time to go and move all the QCMDEXC calls inline right now,
so everything is staying compiled into QILE.

Kevin

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

[mailto:rpg400-l-bounces@xxxxxxxxxxxx]

On Behalf Of Scott Klement
Sent: Friday, August 24, 2007 1:05 PM
To: RPG programming on the AS400 / iSeries
Subject: Re: OVRMSGF and QCMDEXC procedure

I learned this years ago -- and it's why I never wrap QCMDEXC into a
subprocedure. Granted, it adds one more line of code to my program,

but

one line won't kill me.

Peter Dow (ML) wrote:

In this situation, the override is only in effect while control is

in

the QCMDEXC procedure. When control returned to the TESTADDR

procedure,

the override was gone. I guess I should of realized this since a
procedure is another entry on the call stack.

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