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

Hello, again, Birgitta:

Thinking about your situation again, there may be another way to resolve this for your customer, without resorting to any "tricks" (like a front-end to the RCLRSC command, or altering the system library list, etc.) Here is how this would work.

The problem arose because RCLRSC will not "deactivate" a *SRVPGM that is activated in the default activation group -- in this case, because your customer complained about named activation groups, and so you changed your *SRVPGM to ACTGRP(*CALLER).

You can create an RPG IV program using CRTBNDRPG with ACTGRP(*DFTACTGRP) as a way to designate a *PGM as a "pseudo-OPM" program that runs in "OPM Compatibility Mode" in the default activation group (where all the "real" OPM *PGMs run).

You mentioned that you wrote a "wrapper program" so they could call your service program procedures from their (OPM?) code.

Instead of creating a *SRVPGM, just bind the module(s) that comprise the service program directly into your "wrapper" program. You MUST create the wrapper program using CRTBNDRPG with ACTGRP(*DFTACTGRP) which ensures that this program behaves like a "real" OPM program (it runs in the default activation group). When you issue CRTBNDRPG with ACTGRP(*DFTACTGRP), you cannot specify MODULEs to bind with on the CRTBNDRPG command. But, there is a "trick" to get past this; create a binding directory; for this example, "OPMBINDER" (you might name yours the same as the original service program name). Then, issue ADDBNDDIRE to add each of the modules that are part of the original service program into this binding directory, e.g.:

CRTBNDDIR BNDDIR(yourlib/OPMBINDER)
ADDBNDDIRE BNDDIR(OPMBINDER) OBJ((module1 module2 module3))

with as few as one *MODULE or as many as as currently comprise your current *SRVPGM.

Then, add the following "_H-spec_" to your RPG IV source for your "wrapper" program:

H ActGrp(*DFTACTGRP) BndDir('OPMBINDER')

This allows you to create the "wrapper" program as a single bound pseudo-OPM *PGM that contains your "wrapper" program and the other *MODULE(s) that were (formerly) in a separate *SRVPGM, and it runs in the default activation group. The wrapper program is now "OPM compatible" because it runs in the default activation group, so it is subject to the normal OPM rules and behavior, so RCLRSC will reclaim the program and close its files, etc.

What if there is more than one "wrapper" program, e.g. one for "open", one for "close", etc.? That complicates the situation only slightly. In that case, create a NEW "wrapper" program that accepts a "function code" parameter ("O" for Open, "P" for Print, "C" for Close, etc.), plus the rest of the needed parameters, and modify your existing wrapper programs to call into this one NEW wrapper program, passing the appropriate function code and any other needed parameters. The other wrapper programs must use a "full external CALL" (versus a bound call) to the NEW wrapper program. Add the H-spec with the binding directory to this NEW wrapper program, and create it with CRTBNDRPG as per above.

Does this "make sense"?

All the best,

Mark S. Waterbury

BirgittaHauser wrote:

Hi,

It's a shame, this isn't your own company. Then you may have another

option, leave the project, as incompatible based on the users requirements,
... Not possible, it's a rather big project and there is too much money that
is not yet paid. As far as I know we confirmed in our contract, that the
client do not have to change ANYTHING. That's why he is not willing to add a
RCLACTGRP(MyActGrp) to his programs nor is he willing to execute routine
correctly and he insists on using RCLRSC to close the files.
At least we learned something for the next project: Adding a term to our
contract that we use ILE concepts with named activation groups and do not
change our concept.

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 Bob P. Roche
Gesendet: Thursday, July 10, 2008 21:07
An: RPG programming on the AS400 / iSeries
Betreff: Re: AW: MCH3402 - and Built-In-Function %OPEN


It's a shame, this isn't your own company. Then you may have another option, leave the project, as incompatible based on the users requirements,


From:
"BirgittaHauser" <Hauser@xxxxxxxxxxxxxxx>
To:
"'RPG programming on the AS400 / iSeries'" <rpg400-l@xxxxxxxxxxxx>
Date:
07/10/2008 01:41 PM
Subject:
AW: MCH3402 - and Built-In-Function %OPEN



Hi Jon,

Thanks a lot for your comments, I just read your article which is a really
good basics to discuss with the client.

As far as I can estimate he uses 6 of these 7 deadly signs: - all programs (except triggers, that run in a named activation group! An
other deadly sign at least if commitment control is used!) run in the
default activation group (or better are created with activation group
*CALLER)
- To close files RCLRSC is used.
- Because he's working in an ILE environment (haha), after the RCLRSC and
sometimes RCLACTGRP *ELIGIBLE is executed!

The only deadly sign he didn't use, is to change the override scope in the
override command. After changing everything to default activation group, I found out he did an
override for ALL printerfiles and overwrote my printer file. So I had add an
override to set the overriden parameters back to the original values.

He already expressed against my manager (who unfortunately is no programmer
but sales man):
He had around 40,000 programs running in this way, without problems. Service
programs and Prototyping (an other problem when he send me a parameter with
the wrong definition) are not necessary. And he don't want to add an RCLACTGRP(MyActGrp) to around 150 programs!

Until now I already wasted 2 days, to get my programs and service programs
run in his environment. In this time I could have added the
RCLACTGRP(MyActGrp) into his 150 programs several times.
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 Jon Paris
Gesendet: Thursday, July 10, 2008 16:39
An: rpg400-l@xxxxxxxxxxxx
Betreff: Re: MCH3402 - and Built-In-Function %OPEN



On 10-Jul-08, at 7:54 AM, rpg400-l-request@xxxxxxxxxxxx wrote:

As far as good and everything run ok. But then our client saw the named activation groups and insited on only using the default activation group.
("The former software did not use named activation groups!")
In this way I had to change the activation group of all my programs and
service programs to activation group caller. Even though I predicted several
problems. But the client is the king!
An a lot of problems came up. First he overwrote my printerfile and a couple
of other things, but that's an other point.

And problems will continue and continue and continue and ...

The client is not always right. In this case he is just plain wrong!

The simple fact of the matter is that IBM's original intent was that ILE programs would not run in the Default AG (DAG). Period. That restriction had to be relaxed for a number of reasons - but it is important for your client to understand that this was the original design point. The problems generally surface when using Service Programs in the DAG - and specifically when those Service Programs use files. Once you are in that mode you can pretty much guarantee that you will have problems. They can be surmounted, but often at the expense of additional coding and design compromises. And once one problem is dealt with another will arise. You already have experience of this! These problems will continue for the life of the software.

The whole point of using Service Programs is simple and safe re-use. Your client is guaranteeing that your Service programs will be neither. Both you and anyone who subsequently uses the Service programs and/or modify the application will have to know ILE inside and out to make changes safely. If you go back to using ILE as it was designed and intended to be used, these problems will disappear.

I would point out to the client that:

1) The fact that the previous software designers did things the wrong way is no reason to continue to do so.

2) He is building a maintenance and reliability nightmare for himself

3) Other programmers will be able to use and safely modify your design much more easily and safely that the half-assed approach he is forcing you to take.

4) If he owns a BMW he _could_ use it to tow a manure spreader on a farm, but it wouldn't do a good job, would probably get stuck in the field, and/or be permanently damaged. Much better to use the correct tool for the job!

You could try pointing him at this article in the IBM Systems Magazine (the one published by IBM!) - and tell him to note the first two sins! http://www.ibmsystemsmag.com/i5/developer/7923p1.aspx

Good luck - if he forces you to continue on the current path you are going to need it!


Jon Paris

www.Partner400.com
www.SystemiDeveloper.com