>On Mon, 27 Nov 1995, Jeff Kell wrote:
>
>>...  RPG is a non-language
>> anyway (IMHO) and most of the "compilation" is plugging additions into a
>> fixed run-time module anyway (unless they did miraculous things with the
>> language after RPG-III which I have coded for food at one point in my life).
>>
>> Jeff Kell <[log in to unmask]>
>
>Why does everyone knock RPG?  Of course it is not a system programmer's
>language, but if you knew how it worked, you could do an application
>with the least code of any language and the least debug time.  It is
>really the first 4th GL.
 
Er, no. RPG as a report writing language is fine, but not nearly as useful
as today's dictionary-driven report writers. One RPG report program is OK,
but a library of them is a maintenance nightmare. I'm rescuing a client
from just such a nightmare at the moment.
 
RPG as an application language was designed for card and tape systems. It's
terrific for sequential grandfather-father-son merge updating (hey, it's
'60s technology so we use '60s terms) on unit-record devices. As an
interactive language, it's dreadful, heroic efforts to the contrary
notwithstanding. RPG's calculation specifications are little more than
fixed-field assembly language for a not-very-capable computer, so one 7,000
line RPG program, since replaced, used 2,000 lines of calculation
specifications just to parse a simple input line. The entire program was
replaced by 100 lines of declaratives in a data dictionary, plus the same
inquiry/report tool that's used for dozens of other similar programs; as a
bonus, it runs faster than the RPG did.
 
On the 3000, RPG can't handle IMAGE except in a mode where it models KSAM
files. This precludes using custom lists to improve the maintainability and
reusability of a program, not to mention record-level locking. In another
case for this client, seven separate update programs comprising 4,000 lines
of RPG have been replaced with a single 400-line COBOL program -- with
record-level locking and extra data auditing thrown in for good measure.
Thanks to IMAGE custom lists, the program updates all seven data sets with
no special cases, and won't need to be changed when the client changes the
data base layout. This would have been impossible in RPG.
 
The end result of the conversion that my client now has underway will be an
order of magnitude improvement in maintainability, a noticeable improvement
in performance, elimination of 95% of their scheduled application downtime,
and a large increment in customer responsiveness, all with lower payroll
costs. Eliminating RPG is the source of part of the improvement; the rest
is the replacement of the antiquated system architecture forced on them by
the use of RPG.
 
RPG is a good language for traditional batch reports on sorted data but
modern 4GLs are at least as facile, with better maintainability as a bonus.
RPG is no better than assembly language for calculations, analytical
reporting or complex processing. To paraphrase the nursury rhyme, when it's
good it's really pretty bad, and when it's bad, it's horrid.
 
-- Bruce
 
---------------------------------------------------------------------------
Bruce Toback    Tel: (602) 996-8601| My candle burns at both ends;
OPT, Inc.            (800) 858-4507| It will not last the night;
11801 N. Tatum Blvd. Ste. 142      | But ah, my foes, and oh, my friends -
Phoenix AZ 85028                   | It gives a lovely light.
[log in to unmask]                 |     -- Edna St. Vincent Millay