Re: New program call model and V6R1

Hello, all:

As far as I know, internally, during development, OPM was "Old Program Model" and NPM was used for the "New Program Model" -- and then, some time before it was ever released to customers, OPM was renamed "Original Program Model" (presumably because "Old" sounded too much like "legacy"...) and NPM was re-branded as the "Integrated Language Environment" (ILE). This was done prior to V2R3, the first release of OS/400 to support ILE (although at that time ILE C/400 was the only ILE language compiler available.)

Cheers,

Mark S. Waterbury

> Alan Campin wrote:

No, I just think that is me trying to think of something to identity the
difference. I guess you could call it the more ILE model.

On Wed, Feb 10, 2010 at 11:49 AM, Vern Hamberg <vhamberg@xxxxxxxxxxx> wrote:

Alan

I'm just curious - is IBM actually speaking of a New Programming Model?
I thought there was still only OPM and ILE.

Vern

Alan Campin wrote:

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.

--
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.