ILE RPG Programmer’s Guide

As CharlieBrowne said, they have different object types. Obviously, though, “telling the difference” requires knowing how you are “looking”. What do you mean by “looking at it”?

You can’t look at a program nor a module except perhaps by going in through Service Tools and examining bytes on disk. So, you must be using some command to output some results. Perhaps you are “looking at” a list of objects in a library. What command or menu option created the list?

Tom

I think there was a confusion. I wanted to ask how to differentiate between Module and program by looking at its source code.

You open a source code and now there must be differences between the these two which actually makes them different.

if this question makes Modules and procedures same then for a procedure i believe we have specifications P, D and C. Not sure. Any suggestions?

…how to differentiate between Module and program by looking at its source code.

Ah. Yes, that gets a little tricky.

First, a *MODULE must be compiled as ILE. If it’s not ILE-compatible source, it will always compile as a *PGM.

Second, ILE always compiles *MODULEs. ILE programs are never compiled; they are bound from modules.

However, the ILE languages all supply commands that do the module compilation and the program binding in a single command. For example, the CRTBNDRPG command will first compile the source as a *MODULE in QTEMP and then generate the bound *PGM from that *MODULE along with any system *MODULEs (service programs) that are indicated.

So, the distinction can be tricky since all ILE source that can be compiled is always *MODULE source. But some modules are not sufficient to create bound programs; they require other modules.

Generally, in order to result in a program, a “main” procedure must be supplied in the module source. So, the first clue with ILE RPG is likely to be the presence of the NOMAIN H-spec keyword. If the source compiles with NOMAIN, you know it can’t stand alone as a *PGM; some other module must supply the “main” procedure. (Note that the procedure doesn’t need to be named “main”. Being the main procedure isn’t the same as having a procedure named ‘main’.)

Also, RPG requires a way to end a *PGM. Usually, that means you’ll find a reference to indicator LR or *INLR in the source. Since that might be supplied in a /COPY member or similar means, it’s not guaranteed.

Now, with ILE CL, any source that compiles can be either a “main” procedure or a secondary procedure. There are no clues — the source can be handled either way.

ILE C will actually have a procedure named ‘main’ that you can search for in the source.

ILE COBOL… I’m not sure yet. Everything I tested resulted in a *PGM or *MODULE depending on the creation command that I used, even for source that I explicitly wrote for use as a *MODULE. I’ll see if I can track down details.

Well, in short, if the source doesn’t explicitly carry an indication such as the ILE RPG NOMAIN keyword, you may need to submit compiles into QTEMP and have the system tell you if it succeeds or fails when creating a *PGM. (A *MODULE can almost always succeed.) I’ve always found that the system is much faster at making the determinations than I am. After all, we’re programmers. We’re supposed to know how to get the system to do work for us.

It’s not necessarily the source that makes a difference. It’s what you do with the source that is most important.

If I find more, I’ll try to remember to add it.

Tom

thanks a ton for the explaination. Could you please also add the basic difference between module and a procedure but again just by looking at it.

Could you please also add the basic difference between module and a procedure…

For what language? ILE RPG and ILE C both have language constructs for including multiple procedures in modules. COBOL and CL both have a single procedure per module.

When multiple procedures are allowed, there will be prototypes for each one. (Though, in ILE RPG a prototype for the “main” procedure isn’t required.) In RPG, you’d recognize procedures by their P-specs.

Tom