× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.


  1.  Home
  2. RPG400-L
  3. September 2012

RE: MAIN and LR

Ok. That's different from the absolute you gave before.

Not a bug, it's been well-documented since the beginning. It is, in fact, a
feature - and a good one! For example:

If firstTimeHere ;
firstTimeHere = *Off ;
// do some setup stuff
EndIF;

... and never shall the above repeat!

One who doesn't like that behavior should steer clear of global and static
data.

One should steer clear of global data anyway, as much as possible. But the
above is useful and intended.

Dennis Lovelady
http://www.linkedin.com/in/dennislovelady
--
"A fashion ten years before its time is indecent. Ten years after its time
it is hideous. After a century, it becomes romantic."
-- James Laver


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.

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



As an Amazon Associate we earn from qualifying purchases.

This thread ...
Replies:
Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.