Re: MAIN and LR -- RPG400-L

Yes, but only the first time, if the variable is global, that a given
module or program is called. In my opinion, that is a bug. I think
every time you call a program or module it should execute the
initialize logic for a global variable if the variable has a INZ
keyword on the variable.

To prove it just take the test program and add the INZ keyword to the
global variable and you will see the following:

DSPLY 'TANGO' -- INZ value
DSPLY 'ZEBRA'
DSPLY 'ZEBRA'

On Wed, Sep 26, 2012 at 1:45 PM, Dennis <iseries@xxxxxxxxxxxx> wrote:

INZ, by my experience, will initialize global/static and local variables equally well.
++
Dennis
++
“Guidelines for Bureaucrats:
(1) When in charge ponder.
(2) When in trouble delegate.
(3) When in doubt mumble.”
-- James H. Boren

Bravely sent from my Galaxy tablet phone.
++

Alan Campin <alan0307d@xxxxxxxxx> wrote:

If you are talking about the global or static variable that only works
the first time the program or module is called. After that it stays at
the value it was last set to in the program before it exited. If the
variable is global, you must initialize the variable in code before
you use it if you must have at a certain value before you start.

On Wed, Sep 26, 2012 at 1:34 PM, DeLong, Eric <EDeLong@xxxxxxxxxxxxxxx>
wrote:

Hm, I just add the INZ option to the variable definition, to ensure

that the automatic storage is initialized to an expected value... I
guess I like to be explicit with my code.

-Eric DeLong

-----Original Message-----
From: rpg400-l-bounces@xxxxxxxxxxxx

[mailto:rpg400-l-bounces@xxxxxxxxxxxx] On Behalf Of Alan Campin

Sent: Wednesday, September 26, 2012 12:13 PM
To: RPG programming on the IBM i / System i
Subject: Re: MAIN and LR

I wrote the following test program awhile ago. This is what the

output

looks like if called multiple times.

DSPLY
DSPLY ZEBRA
DSPLY ZEBRA
DSPLY ZEBRA

In other words, between each call the static storage remains the

same.

h Option(*Srcstmt:*Nodebugio:*NoUnref:*NoShowCpy)
h Main(TestStatic)

/copy *libl/qsrcf,cb_StdType
/copy *libl/qsrcf,cb_Std_Con

d TestStatic...
d pr ExtPgm('TESTMAIN')

d g_TestVariable...
d s Like(StdNam)

p TestStatic...
p b
d pi
/Free

Dsply g_TestVariable;

g_TestVariable = 'ZEBRA';

Return;

/End-Free
p e

On Wed, Sep 26, 2012 at 9:56 AM, Dave <dfx1@xxxxxxxxxxxxxx> wrote:

Vern, your questions are starting to scare me, as I wrote a couple

of

MAIN programs a couple of years ago, left the company for a year and
came back. I didn't think about the initialisation of the main sp.

As

it's variables are not global as in a program without MAIN, I would
think so. I notice that MAIN has not been used yet anywhere else in
our shop and I suspect that noone else has tried it or even knows
about it. I stopped using it as I had to keep remembering how to do

it

when I was writing a new program, which is rare, and I wondered why
bother, you win on performance because of the cycle but you lose on
hassle because the programmers have to learn new stuff. IBM has not
pushed us towards using it as far as I know, so who will bother?

2012/9/26 Vernon Hamberg <vhamberg@xxxxxxxxxxxxxxx>:

Hi Barbara

So to clarify about initialization - and I did look at the

reference and

programmer's guide just now - when using MAIN, the extra

initialization

for the cycle doesn't happen. You can't even HAVE an *INZSR, as I
understand.

I assume that data declared in the MAIN subprocedure is initialized
every time it is called, unless declared as STATIC.

So what happens with global data? If running in *DFTACTGRP? Or is

that

not possible with a linear-main module? I did see the section on

module

initialization, with the subtopic on global data. But it wasn't

clear

what happens with global data when there is no cycle

initialization.

Maybe, too, this is a stimulus to avoiding global data and passing

it

along in parameters from the MAIN subprocedure, eh?

I have to find a few minutes to try out some stuff, I can see that!

Thanks
Vern

On 9/25/2012 7:16 PM, Barbara Morris wrote:

On 2012/9/25 1:49 AM, Vernon Hamberg wrote:

Help me out here - I've always thought leaving *INLR *OFF means

that on

another call to the program, variables will have the values they

had

when the program ended before. Is this different with the MAIN

keyword -

remember, we don't compile to 7.1 (blushing!).

Vern, you're right about how *INLR works for what's now called a
cycle-main module. (And was formerly just not called a NOMAIN

module.)

With the MAIN keyword, you have something very similar to a NOMAIN
module, but the MAIN keyword indicates which of your subprocedures

will

be the program-entry procedure. The main procedure is called a
linear-main procedure (running from beginning to end) rather than

a

cycle-main procedure (running the RPG cycle).

Cycle-main:
/free
dsply 'hello';
return;

Linear-main:
H main(mypgm)
P mypgm b
/free
dsply 'hello';
// return opcode not needed
/end-free
P e

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

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

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