Re: MAIN and LR

Technically, one had/has no ability to define the variables within the true main() procwss of a cycle-driven program.
++
Dennis
++
“I am an old man and have known a great many troubles, but most of them never happened.”
-- Mark Twain




Bravely sent from my Galaxy tablet phone.
++


Dave <dfx1@xxxxxxxxxxxxxx> wrote:

Variables declared inside the main procedure of a program with the
cycle are global, so static. Those inside the main procedure without
the cycle are not. So I'm presuming they are reinitialised at each
call.

2012/9/26 Alan Campin <alan0307d@xxxxxxxxx>:

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.