RE: A different kind of persistence?

Is it making sense now?  Not really any more than it already did.  I
understand the mechanics much better now, but I am still left with the
unanswered question of 'why'...and the sad realization of 'no way...are
you serious'?  I do, however, appreciate the lengths to which you have
gone to explain this.

Not withstanding that LR is specific to RPG (after all, this is an RPG
specific list), was there a compelling reason to stop shy of
re-initializing all of the statically bound modules that make up the
compiled object?  Since the 'main' module remains resident until the AG
is destroyed, apparently there was a requirement to re-initialize these
'main' modules at one time or another and LR was used as that mechanism?
I wonder why this concept wasn't taken a step further into the
statically bound 'nomain' modules.  I mean, from what I am hearing no
other programs or modules can use them since they are specific to the
'main' that they are bound to...no?  Again, I'm just trying to
understand some of the advantages or disadvantages of these
mechanics...LR seems a little 'incomplete' to me...in this circumstance.

In the time that I have been using RPG, I never realized that this was
the way 'nomain' modules behave in an activation group.  I have always
heard (or maybe just thought) that everything got reinitialized when the
'bound program' sets on LR.   This doesn't seem to get advertised a lot.
Granted, service programs are a different story since they can be used
'across main module boundaries', but bind by copy was always advertised
as more of a fancy copybook.  How very wrong that analogy is. :-)

Again, thanks for all the information.  It has been very helpful and
educational.


-----Original Message-----
From: rpg400-l-bounces@xxxxxxxxxxxx
[mailto:rpg400-l-bounces@xxxxxxxxxxxx] On Behalf Of Scott Klement
Sent: Tuesday, January 11, 2005 11:57 AM
To: RPG programming on the AS400 / iSeries
Subject: RE: A different kind of persistence?


> Scott - First, let me say that I am not 'blaming' anyone or anything.
> I'm simply looking for information.  Also, you never really answered
my
> question.  Why are we persisting a module that may never be used
again?

I don't know. It's your choice. Why are you persisting a module that may

never be used again?  I assume it's because you want to speed up 
subsequent calls to it.


> You state in a previous answer that "...each time you bind this way,
it
> copies the module into your program. So, indeed, they're NOT both
bound
> to the same module -- they are bound to different modules which had
been
> copied from the same source..."  If that is the case, then why do you
> then say in this last response that "In order for 'main' to know that
it
> has to notify 'nomain' to shut down, it would have to know at compile
> time (not bind time!) that it will eventually be bound to another RPG
> module, and what that module is called, so that it can insert code to
> notify it...".  Based on what you are saying...it does... otherwise it
> wouldn't know which instance of the module to use...no?

Okay, back to the basics... There are two steps in creating an ILE 
program. The first is compiling the source code into one or more
modules. 
The second is binding one or more modules together to make a program.

The first step is language-specific. To compile an RPG program into a 
*MODULE object, you run the CRTRPGMOD command. It compiles the RPG
source 
code into some routines that Integrated Language Environment (ILE) 
understands.  If you wrote your module in ILE C or ILE CL or ILE COBOL, 
you'd compile it with the CRTCMOD, CRTCLMOD or CRTCBLMOD commands, 
respectively.  The module that's created is no longer an "RPG" or "CL"
or 
whatever module, it's code that's already compiled into something that's

(almost) executable by the machine.  But there's something missing... 
there are routines that each program needs to call in runtime libraries,

in ILE and in the operating system in order to do it's job.  For
example, 
every program needs memory to store it's variables in, in order to get 
that memory, it has to call a routine in the operating system that will 
provide that memory. It can't call these routines because they're not a 
part of the code you wrote (they're part of the OS) and are therefore
not 
in the module.

This is also called "compiling" on Windows and Unix systems. Modules on
a 
Unix or Windows system are called "object files".  In Windows they 
typically end with ".OBJ", and in Unix with ".O".  (You can see why they

didn't use the term "object" in OS/400... that would've been confusing.)

Step 2 is called binding. Binding is the process of finding all of the 
routines that your program needs in order to run and either copying them

into your program (bind by copy) or providing a link to where they're 
located in a service program (bind by reference.) Even if your program
is 
made up of only one module, it still has to be bound because it requires

access to routines in the operating system and the runtime libraries...

On Windows and Unix systems, they use the term "linking" instead of 
binding. On those systems, instead of the term "service program" they
use 
the term "library" (you can see why IBM used a different name there, 
too...) and they've actually got two types of libraries on those 
platforms...  one is for bind by copy, and one is for dynamically
linking 
to (bind by reference.)  The former is sometimes called an "archive"
file 
(since it's really just a collection of object files together in a
single 
archive) and usually ends with a ".a" on Unix systems, or a ".lib" on 
Windows systems.  The latter is sometimes called a "Dynamic Link
Library" 
(DLL) on Windows systems, or a "Shared Object" (.SO) on Unix systems.

ANYWAY... the point that I'm (slowly) making is *INLR is an RPG-only 
thing. It does not exist in other languages. For everything else, the 
program ends when the activation group ends.  That's what ILE expects as

well.  In RPG we have this notion of setting on *INLR.  When that
happens, 
the program doesn't end, but all the files get closed and the storage
gets 
set back to zeroes and blanks (or whatever.)   This is a weird concept.

At the RPG-specific part of the process -- Step 1, above -- the COMPILE 
time, the RPG compiler is making a *MODULE.  It has no concept of what 
other modules you'll bind to or what languages they'll be written in.
It therefore has no notion of how to tell them to "reinitialize" when 
*INLR is on.

At the language-independent ILE part of the process, it's combining 
different modules together.  At that point, it has no notion of *INLR, 
since that's an RPG peculiarity.

> Maybe I'm just a little slow on the uptake, so help me understand this

> further if you have time.

Okay, does it make sense now?


> To all - thanks for the education!  I think I now understand the HOW's
> of some of this, but my last question was more of a WHY than anything.
> It doesn't make sense to persist a 'bound by copy' module that may or
> may not be used again (unless perhaps you make it a service program
with
> the intent of using it again).  It even makes less sense when you find
> out that each instance is specific to the module to which it is bound.
> No other modules can use that instance, so again, if the original
> calling (bound) program ends, why shouldn't the module go away with
it?

First of all, you have to make the distinction between the program
ENDING, 
and RETURNING TO CALLER. Two very different things. In OPM RPG ("RPG
III" 
or "RPG/400") when you end your program with *INLR=*OFF, the program 
remains in memory, ready to be called again.  The program didn't end, it

just returned to it's caller.  It's expecting to be called again.

When you compile an ILE program with DFTACTGRP(*YES), it's in "OPM 
compatbility mode" (which is what they SHOULD'VE called it instead of 
"default activation group") and programs behave the same way they did in

OPM.

In any other case, an ILE program remains in memory until the activation

group ends.  Always.  Period.

An ILE program can "return to caller", but it doesn't actually "end"
until 
the activation group ends.

*INLR just says "close files at end, reinitialize variables (and call 
*INZSR) at start".  The program still "returns to caller", it does not
end 
until the activation group ends.  And in any case, *INLR only affects
the 
module that it's in.


-- 
This is the RPG programming on the AS400 / iSeries (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.




NOTICE: This electronic mail message and any files transmitted with it are 
intended exclusively for the individual or entity to which it is addressed. The 
message, together with any attachment, may contain confidential and/or 
privileged information. Any unauthorized review, use, printing, saving, 
copying, disclosure or distribution is strictly prohibited. If you have 
received this message in error, please immediately advise the sender by reply 
email and delete all copies.