Difference between Module and a Program in AS/400

635 pts.
Tags:
AS/400
AS/400 programming
OS/400
Can someone please tell me how to differentiate between Module and Program in As400 just by looking at it?

Software/Hardware used:
OS400

Answer Wiki

Thanks. We'll let you know when a new response is added.

By just looking at it: a Object Description you would see if it is type *PGM a module is of type *MODULE.

Discuss This Question: 7  Replies

 
There was an error processing your information. Please try again later.
Thanks. We'll let you know when a new response is added.
Send me notifications when members answer or reply to this question.

REGISTER or login:

Forgot Password?
By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy
  • HMSSL2K
    3,175 pointsBadges:
    report
  • TomLiotta
    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
    125,585 pointsBadges:
    report
  • Sangay
    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?
    635 pointsBadges:
    report
  • TomLiotta
    ...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
    125,585 pointsBadges:
    report
  • Sangay
    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.
    635 pointsBadges:
    report
  • TomLiotta
    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
    125,585 pointsBadges:
    report
  • Sangay
    [...] All the usual suspects showed up to help Sangay tell the difference between module and a program in AS/400. 6. Rakei and Rechil do their best to describe how to properly mass delete user profiles in [...]
    0 pointsBadges:
    report

Forgot Password

No problem! Submit your e-mail address below. We'll send you an e-mail containing your password.

Your password has been sent to:

To follow this tag...

There was an error processing your information. Please try again later.

REGISTER or login:

Forgot Password?
By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy

Thanks! We'll email you when relevant content is added and updated.

Following