|
Carel Teijgeler wrote: >There are two groups of programme's (PGM): OPM >and ILE. OPM PGM's are written in RPG III or >RPG IV. ILE PGM's are only written in RPG IV >and uses elements of the ILE concept. Since this is the RPG list, I'll say that ILE RPG programs are only written in RPG IV. Other ILE languages include Cobol and CL (oddly enough.) >RPG IV PGM's can be compiled with the following >options: DFTACTGRP(*YES) (default) This AG is >created at the start of the job and I assume the >name of the AG is the jobname. Do a DSPJOB option 18 and you'll be able to verify the name for yourself. Here's my V5R1 system: ----Activation Group----- Number Name In Use Indicator 0000000001 *DFTACTGRP Yes 0000000002 *DFTACTGRP Yes 0000001676 QLGLOCAL No 0000001921 QTOSSAPI No -snip- >In all cases: any AG has a name. This is true; but when we speak of Named Activation Groups, we're speaking specifically about other groups than *DAG. The vocabulary does not make it easy to talk about these concepts. Non-*DAG is a mouthful. At least NAG can be pronounced, however horrible it may sound... >You can run a PGM in three kinds of AG's: > >1) Default Activation Group (DAG). The DAG is >the environment that runs a mixture of OPM >PGM's and ILE PGM's. Yes, but the behaviour of ILE programs compiled DFTACTGRP*YES) is different than the behaviour of ILE programs compiled *CALLER being called from *DAG. >2) A Named Activation Group (NAM). In the NAM ILE >PGM's will run that have been compiled with the >name of an AG provided or with the special value >*CALLER. > >3) A *NEW Activation Group. I've been calling a Named Activation Group a NAG. The only difference between a NAG and *NEW is who assigns the name. With a NAG, the programmer is responsible to see that the chosen name is appropriate (that it won't clash with other applications). With *NEW there can never be a name collision; the system will assign a unique name every time. >Considerations in defining an AG to an ILE PGM are >manyfold; think about sharing resources, overrides, >record locks, error handling, recursive calls >(call stack), performance. Exactly right; that's why this thread came about. So many people have asked "What's the best way to deal with Activation Groups?" The very question implies the belief that there is a single "right way" to think about the subject. I do not believe there is a simple answer, so we're "exploring" different AG strategies in the hope of making some of the decision points clearer. Thanks Carel! It's good to have another voice in the discussion! --buck
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.