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




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.



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.