Re: New program call model and V6R1

Hmmm. Ok, I get it. I would have thought the behavior would have changed
with the NPM. So what we are saying is that using a named activation group
and the cycle it will reinitialize the variables but not free them.

With the new model is will keep them in memory but will not reinitialize
them. Gotcha I will have to watch out for. You cannot assume that the value
of a static variable is initialized to blanks or zero using a MAIN
procedure.


On Tue, Feb 9, 2010 at 3:05 PM, Scott Klement <rpg400-l@xxxxxxxxxxxxxxxx>wrote:

hi Alan,

What you're describing is the way ILE has always worked. Static storage
is allocated when the program is activated. Activation occurs the first
time a program/srvpgm is called within an activation group.

Static storage is deallocated when the program is deactivated, when only
happens when the activation group is reclaimed.

This is not related to v6r1 -- it's the way ILE has worked from the outset.

HOWEVER, there's one exception:

In OPM compatibility mode (enabled via DFTACTGRP(*YES) during program
creation) a program is deactivated when it ends with LR turned on.
(This *only* happens when you specify DFTACTGRP(*YES) -- ACTGRP(*CALLER)
won't do it.)

Also there's one more thing that can throw you off:

When the RPG cycle is enabled (i.e. the MAIN and NOMAIN keywords are not
used) and a main procedure ends with *INLR=*ON, it sets a flag. On the
next call, if that flag is set, it reinitializes all of the variables
(to blanks or zeroes or whatever the initial value is). Note that this
does not cause the storage to be freed or reallocated, it only resets
the values of the variables.


For example, you can try this on ANY release of ILE RPG (well, v3r2 or
higher, since that's when RPG got subprocedure support):

H dftactgrp(*no)

D count pr

c callp count
c eval *inlr = *on

P count b
D pi
D num s 10i 0 static
c num dsply
c eval num = num + 1
P E

Every time you call this (until you reclaim the actgrp) it will display
a number one higher than the last time. EVEN THOUGH LR IS ON!

The only difference with the 6.1 support is the MAIN keyword lets you
define a main procedure that works the same as a subprocedure (and
therefore it's values aren't reinitialized by LR).



On 2/9/2010 3:36 PM, Alan Campin wrote:

I have come across something that puzzles me about the new program model

in

V6R1.

I created a test program using the new H spec keyword MAIN.

In this version I included a global variable and code in the MAIN

procedure

that first display the value and then initialized it to 1.

When I called the first time is displayed 0 which is what I would expect

but

I when I called it a second time is showed a value of 1 again.

In other words the value of the static variable was kept between calls.

I took another version with no MAIN and LR = *On and value was always 0.

Since you now longer have an *INLR in the new program model how does the
storage ever get released? Only the ending of the job?

Seems kind of strange. Shouldn't it always be 0 with the new program

model

because the storage is released on each call?

Thanks.

--
This is the RPG programming on the IBM i / System i (RPG400-L) mailing list
To post a message email: RPG400-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/rpg400-l.