• Subject: RE: RPG IV and CF-spec "keep it IBM" (ILE Pgm MAKE)
  • From: "John Taylor" <john.taylor@xxxxxxxxxxxxxxx>
  • Date: Fri, 30 Jul 1999 15:25:46 -0600
  • Importance: Normal


Scott Klement wrote:

> I personally think that the ability to bind multiple modules, and
> use activation groups is really the problem with RPG IV on the
> AS/400!   I think they're a great idea, and necessary to make RPG
> a modern language, but they could've been done better.
>
> Another way is to have a "make" utility like there is in UNIX that
> can be used to tell someone how to build a program, making sure to
> build all of the dependencies first, then the actual modules, and
> finally bind them all together.  Sure, I can put comments in the
> top of my code telling another programmer how to compile it...
> but that won't work if the programmer doesn't know to check ....
> or even worse, if a batch program is recompiling all the programs
> that use a file because something has changed...   This is my big
> problem with RPG IV, its too damned hard to rebuild programs that
> use things like multiple modules, activation groups and service
> programs.


Scott,

Although a proper MAKE utility would be a wonderful addition to the AS400
development environment, there are other ways to get around this problem.

Each new ILE program that I build is associated with a CL source member that
contains the "Make" instructions. The following is an example:

//BCHJOB   JOB(CRTPGM) JOBD(QGPL/QPGMR) JOBQ(*JOBD) +
             PRTDEV(*USRPRF) OUTQ(JUNK) LOGCLPGM(*YES) MSGQ(*USRPRF)

CRTPGM     PGM(CUGSON/SPE005) MODULE(SPE005* SPM001 INM001) ACTGRP(SPE005) +
             DETAIL(*EXTENDED) USRPRF(*OWNER)

//ENDBCHJOB


To run this source, I've added a new PDM option called "DJ" which runs the
following command:

SBMDBJOB FILE(&L/&F) MBR(&N) JOBQ(QGPL/QPGMR)


Now, the program will be built the same way each time.

The module compilation is a different story, although it is getting better
with the addition of the new keywords on the H-spec. I'm at V4R4 now, and
virtually every CRTRPGMOD parameter that I need can now be specified in the
H-spec.

Again, this is not the ideal situation. But it does make the problem
manageable enough to allow me to use ILE effectively.


> Another problem, something that scares people away, is the terminology
> I mean, MY GOD, on every PC system you build "object files" that are
> "Linked" into a program.

Is there really such a big difference?

object file = module
linking = binding
exe file = program
link library = service program


I also work on both PC's and the AS/400. It took me all of about 2 minutes
to grasp the concepts involved. Most AS400 programmers won't have the PC
"baggage" to deal with at all, so it's not really an issue.

> Anyway, I'm getting off-track here.   It seems to me that the CF
> spec would (with the current state of the language) make things
> easier to work with and maintain.   I don't think the free-format
> spec is going to scare away IT managers.  (Unless, of course, you
> discontinued the normal C spec, so it could no longer be used, in
> that scenario, yeah, everyone would be afraid...)


Back to the CF.. I've refrained from commenting so far because I think that
Doug Handy and David Morris have done a superb job of summing it up already.
My position is, bring on the CF! Sure, as Bob pointed out, there are
additional areas within the language the still need improvement. But I would
rather see these improvements built upon a foundation of free-format,
instead of yet another OPCODE cludge.


John Taylor


+---
| This is the RPG/400 Mailing List!
| To submit a new message, send your mail to RPG400-L@midrange.com.
| To subscribe to this list send email to RPG400-L-SUB@midrange.com.
| To unsubscribe from this list send email to RPG400-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com
+---END



This thread ...

Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2019 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].