AW: MCH3402 - and Built-In-Function %OPEN

Hi Mark,

I got your private eMail, and tried to answer it to thank you, but my eMail
was denied from your server and came back.

I'll try your solution on our machine, but even if I have enough authority
and my client not even allow me to use named activation groups, I suspect he
won't allow me to change the system library list.

In either way thanks for suggestion. I'll add it at least to my
"collection".

Mit freundlichen Grüßen / Best regards

Birgitta Hauser

"Shoot for the moon, even if you miss, you'll land among the stars." (Les
Brown)
"If you think education is expensive, try ignorance." (Derek Bok)
"What is worse than training your staff and losing them? Not training them
and keeping them!"

-----Ursprüngliche Nachricht-----
Von: rpg400-l-bounces@xxxxxxxxxxxx [mailto:rpg400-l-bounces@xxxxxxxxxxxx] Im
Auftrag von Mark S. Waterbury
Gesendet: Friday, July 11, 2008 23:19
An: RPG programming on the AS400 / iSeries
Betreff: Re: MCH3402 - and Built-In-Function %OPEN


Birgitta:

NOTE: I recommend this approach only for certain special situations; in
this particular case, I believe this method will solve your problem.

Create your *SRVPGM to run in its own "named" activation group instead
of *CALLER. (This could be the same name as the *SRVPGM itself.) Use
the UPDSRVPGM command to change the ACTGRP after the *SRVPGM was
created, or recreate the *SRVPGM from the *MODULEs via CRTSRVPGM. (I
will call this activation group name "SRVPGM" in this example.)

The "wrapper" program(s) you wrote that call procedures in this service
program can now probably just run with ACTGRP(*CALLER).

You want to "intercept" everywhere their application issues RCLRSC, so
your software can also issue RCLACTGRP ACTGRP(SRVPGM).

This can be accomplished as follows (perform these steps on the customer
machine)::

1. create a library named "QSYS1" (for this example -- you can choose
another suitable name):

CRTLIB LIB(QSYS1) TYPE(*PROD) AUT(*USE) CRTAUT(*USE)

2. duplicate the RCLRSC command from QSYS into the "QSYS1" library:

CRTDUPOBJ OBJ(RCLRSC) FROMLIB(QSYS) OBJTYPE(*CMD) TOLIB(QSYS1)

3. change the duplicated command to use a program you will create in
library QSYS1:

CHGCMD CMD(QSYS1/RCLRSC) PGM(QSYS1/RCLRSC)

4. create a CLP program named RCLRSC in the QSYS1 library. Change the
value of &ACTGRP as needed.

PGM PARM(&LVL &OPT)
DCL VAR(&LVL) TYPE(*CHAR) LEN(1)
DCL VAR(&OPT) TYPE(*CHAR) LEN(1)
DCL VAR(&ACTGRP) TYPE(*CHAR) LEN(10) VALUE('SRVPGM')
QSYS/RCLACTGRP ACTGRP(&ACTGRP)
MONMSG MSGID(CPF1653) EXEC(DO) /* ACTGRP not found */
RCVMSG PGMQ(*SAME (*)) MSGTYPE(*EXCP) MSGKEY(*NONE) +
WAIT(0) RMV(*YES) /* remove msg from joblog */

ENDDO
QSYS/TFRCTL PGM(QSYS/QWCCRCRC) PARM(&LVL &OPT)
ENDPGM

This must be an OPM *PGM (CLP versus CLLE) as the TFRCTL command is not
allowed in ILE CL programs.

This command processing program works because the original IBM CPP for
RCLRSC can be called from user state programs. We must TFRCTL to it,
rather than CALL it, so that "RCLRSC LVL(*)" versus "RCLRSC LVL(*CALLER)
performs correctly.

You need to ensure that "QSYS1" is in the system portion of the library
list, ahead of QSYS, at runtime. Assuming your service program has an
"open" procedure that is always called before any "printing" activity,
that procedure can call another CL *PGM that issues:

CHGSYSLIBL LIB(QSYS1) OPTION(*ADD)

This CL program must be owned by QSECOFR and specify USRPRF(*OWNER)
since the CHGSYSLIBL command ships with *PUBLIC *EXCLUDE authority.

Or, perhaps your customer might already have a library specified in
QSYSLIBL ahead of QSYS where they place customized versions of IBM
commands, etc.? In that case, you can just place your modified RCLRSC
command and its command processing program there, in which case, you do
not need to use the CHGSYSLIBL command.

Or, as others have suggested, the QIBM_QCA_CHG_COMMAND exit could be
used to "re-route" all invocations of the RCLRSC command to specify
"QSYS1/RCLRSC ..." This avoids having to alter the system portion of the
library list using the CHGSYSLIBL command.

All the best,

Mark S. Waterbury