RE: OPM called by program running in a named activation group

-----Message d'origine-----
De : rpg400-l-bounces@xxxxxxxxxxxx
[mailto:rpg400-l-bounces@xxxxxxxxxxxx] De la part de Simon Coulter
On 26/03/2009, at 12:53 AM, David FOXWELL wrote:

Simon, I'd also like to be able to highlight the lines of the email
I'm replying to with a >, how do you do that?

Depends on your e-mail client. The headers in your e-mail
indicate WinDOS therefore probably Outlook. Even that smelly
pile of poo can quote reply text.

Like the great white shark ( another of Australia's fearsome beasts ) can smell a drop of blood in the English channel from the Pacific ocean, you can smell Outlook from the other side of the world! Impressive. Thanks, as you can see, that's one problem solved. Now for activation groups...

One possible approach:
Step 1) Convert to RPG IV running in *DFTACTGRP. Any *SRVPGMs
should be *CALLER.
Step 2) Once all code is RPG IV run *PGM objects in QILE (or
other named activation group)--usual technique is to have
main programs specify the desired activation group and
sub-programs use *CALLER like *SRVPGMs generally do.
Step 3) Analyse application behaviour and use additional
named or *NEW activation groups where appropriate--it may be
that it is inappropriate or unnecessary for your application.

That seems perfectly reasonable and I will bring this up with management.

We are running a program that exists in several versions,

each one in

its own ACTGRP.

What do you mean by versions? Different source code? Or just
uses different libraries for files?

The same source is used to create different program objects so that they will run in the group indicated.

This will permit the application to start in a general environment
(DFTACTGRP), then depending on user choice, switch to an

environment

specific to that choice. This will let us switch from families of
files that exist in different libraries, eg File1, File2,

etc exists

in Lib1, Lib2, etc We will have an ACTGRP per library

containing each

group of files.

What is specific to that environment? What is it about the
application that needs separate activation groups per client?

Actually it's really an environment specific to a type of product. The user can display a list of products for a client in a subfile. This program exists already. The modification is to permit the user to select and manage a product. So we'd issue a call to the ProductManagmentPGM which manages files F1, F2, etc. This program must use the files in the library corresponding to the product being managed. Files F1, F2 exist in as many libraries as there are product types. On returning to the client subfile the user can choose another product type. To recap, when the subfile is displayed, we're in the DFTACTGRP, each choice of subfile record takes us to the appropriate named ACTGRP.

So, we start in DFTACTGRP, go to named ACTGRP X, return to

DFTACTGRP

go to named ACTGRP Y, etc.

Big mess! especially if you still have RPG III code being
called from your client-specific named activation groups.

I see it as starting from home ( DFTACTGRP ) going from one ACTGRP to another but each time returning home first. I agree that no calls to programs in the DFTACTGRP must be made from one of the named groups.

If the reason for this mess is simply trying to get different
libraries used by different "client selector" programs then
use *NEW as suggested by Joep. However, you still need to get
out of *DFTACTGRP. At a minimum you need to ensure that code
called by your client-specific program(s) runs in the same
activation group.

We have disregarded *NEW, because that will mean reopening the files for each choice the user makes from the subfile.

I understand now that we need to get rid of the DFTACTGRP at the start. I thought of the following possibility : file F1 used by ProductManagmentPGM gets opened somewhere before the subfile is displayed. Then, when the user selects the product and changes to ACTGRP A, normally the file F1 in library A should be opened....and blood will be spilled.

Simon, I feel I have a sharp axe rather than a knife. Unfortunately, I'm only the executionner.

Wouldn't it be a good idea to advise anyone wanting to use activation groups to start off by eliminating the use of DFTACTGRP for that application?

Thanks.