SubProcedures & DFTACTGRP(*YES)

[Guest.Visitor]

On Thursday, January 22, 1998, 07:26 AM, Palarco wrote: why does DFTACTGRP *no have to be specified when using subprocedures within a program? This makes a simple report program with OVRDBF's more complex by having to mess with activation groups. Everything I've read states that subprocedures within a program(not external) are replacements for subroutines except with local variable capability...what gives? I wouldnt generally recommend running ile pgms in the default activation group, but given that you already are.... you could specify ACTGRP(*CALLER) on the compile. If the caller (which presumably does the ovrdbf's) is running in *dftactgrp so will your report program, and your ovrdbf's will behave in an opm-like manner. Subprocedures are not replacements for subroutines. Perhaps some more reading is in order... Try IBMs href="http://as400bks.rochester.ibm.com/cgi-bin/bookmgr/bookmgr.cmd/BOOKS/QBKAQ7 00/CCONTENTS">ILE Concepts and the href="http://as400bks.rochester.ibm.com/cgi-bin/bookmgr/bookmgr.cmd/BOOKS/QBKAQD 01/CCONTENTS">ILE RPG Programmers Guide. Derek

[Guest.Visitor]

On Friday, January 23, 1998, 09:04 AM, Palarco wrote: First:The Cozzi book and The RPG source newsletter from NEWS/400 both state that subprocedures used within a program are basically the same as subroutines. Neither specify how Activation Groups relate to subprocedures. Second: I asked why this happens, not for a workaround which I already knew about. If you want to know why the publications you mention didnt go into a particular aspect of ile behaviour, perhaps the best way to get an answer would be to address the question to the authors. The IBM manuals I quoted do explain activation groups and procedures. Why the restriction? Beats me...... Derek

[T.Holt]

Subroutines and subprocedures behave in the same way. You call them, they run, then execution resumes after the call. However, they are not implemented the same way. I'm not sure about this, but I think that a subprocedure adds another level to the call stack of the job, whereas a subroutine runs within the same call level as its caller. I hope somebody will correct me if that's wrong. In any event, subroutines and subprocedures are not equivalent. On Thursday, January 22, 1998, 07:26 AM, Palarco wrote: why does DFTACTGRP *no have to be specified when using subprocedures within a program? This makes a simple report program with OVRDBF's more complex by having to mess with activation groups. Everything I've read states that subprocedures within a program(not external) are replacements for subroutines except with local variable capability...what gives?

[Guest.Visitor]

On Saturday, January 24, 1998, 05:55 AM, Ted Holt wrote: Subroutines and subprocedures behave in the same way. You call them, they run, then execution resumes after the call. However, they are not implemented the same way. I'm not sure about this, but I think that a subprocedure adds another level to the call stack of the job, whereas a subroutine runs within the same call level as its caller. I hope somebody will correct me if that's wrong. In any event, subroutines and subprocedures are not equivalent. You are right about adding another level to the call stack. I guess the main reason they require an activation group is so that you can split up processing to different activations groups. src="http://prairie.lakes.com/~bvstone/gifs/as400sig.gif" BORDER=0 HEIGHT=131 WIDTH=85>

[Guest.Visitor]

On Thursday, January 22, 1998, 07:26 AM, Palarco wrote: why does DFTACTGRP *no have to be specified when using subprocedures within a program? This makes a simple report program with OVRDBF's more complex by having to mess with activation groups. Everything I've read states that subprocedures within a program(not external) are replacements for subroutines except with local variable capability...what gives? I've been racking my brains for an answer to this one - I think it would be a useful thing to know. So in lieu of an answer I'll throw in a theory - just to get the ball rolling. When you create ILE pgms with the CRTPGM command, the only options you get for activation group are *NEW, *CALLER and a named activation group. *DFTACTGRP isn't an option. So I'll assume no ILE program can be initiated in the *DFTACTGRP - only OPM programs.(this still allows for ILE pgms to be run in the *DFTACTGRP - just not as the first call). The option to state DFTACTGRP(*YES) appears on the CRTBNDRPG command, and an RPG IV program will compile ok so long as there are no sub-procedures. I'm guessing that even though it's written in RPG IV, it really creates an OPM program (and can therefore run in the default activation group). OPM programs don't have the resources available to support sub-procedures - as soon as you code a sub-procedure, the only way it will work is in an ILE program. Torch away.

[Guest.Visitor]

On Monday, January 26, 1998, 04:14 AM, J V Thompson wrote: I've been racking my brains for an answer to this one - I think it would be a useful thing to know. So in lieu of an answer I'll throw in a theory - just to get the ball rolling. When you create ILE pgms with the CRTPGM command, the only options you get for activation group are *NEW, *CALLER and a named activation group. *DFTACTGRP isn't an option. So I'll assume no ILE program can be initiated in the *DFTACTGRP - only OPM programs.(this still allows for ILE pgms to be run in the *DFTACTGRP - just not as the first call). If you call an ILE pgm with actgrp(*caller) from command line it runs fine in the default activation group. Even if it has subprocedures. So it looks like you can initiate an ILE pgm in the default activation group.... The option to state DFTACTGRP(*YES) appears on the CRTBNDRPG command, and an RPG IV program will compile ok so long as there are no sub-procedures. I'm guessing that even though it's written in RPG IV, it really creates an OPM program (and can therefore run in the default activation group). Seems unlikely. ILE pgms have a number of characteristics that differ from OPM. Things like pgm type (shown by dsppgm), the QRNX* and QLE* service pgms being used at runtime, the program entry point being implemented as a seperate procedure (and therefore an additional call stack entry)....etc. All of these ILE characteristics remain if you use dftactgrp(*yes), so it looks to me as if you are in fact still getting a real ILE pgm. color="#0000CC"> ... Torch away. :-) Like I said in an earlier post JV, I dont have the answer, but I wonder if the reason for the restriction isnt a more indirect one. Under the ILE model static storage is owned by an activation group, and can only be released when that activation group ends. The default activation group by definition does not end until the job ends. Therefore you cannot release static storage allocated by ILE pgms running in *dftactgrp (unlike OPM pgms). The restriction could be an attempt to discourage patients...er, customers from using *dftactgrp, so a "fix" wont be required for systems running out of memory. One mans cynical speculation..... Derek

[Guest.Visitor]

Might it (the new activation group) also be a vehicle to isolate local variables?