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.