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



This is a multi-part message in MIME format...
--
To: java400-l@midrange.com
From: jamesl@hb.quik.com
X-Advert: http://emumail.com
Reply-To: jamesl@hb.quik.com
Date: Mon, 16 Dec 2002 17:38:37 AST
X-Mailer: EMUmail
Subject: Re: Cycle vs. Non-Cycle RPG (vs. Java, C, et al.)

It's been suggested that people are getting formal training in RPG that never

mentions The Cycle.

Coding in RPG without taking advantage of The Cycle
sounds about as absurd as
somebody writing Java programs that don't
explicitly instantiate a single
object. If you're not making at least SOME
use of The Cycle, than why code in
RPG at all? In fact, the only thing I can
think of that seems more ludicrous
than writing non-Cycle RPG programs is
TEACHING people RPG without mentioning
The Cycle.

(For those unfamiliar
with RPG, "The Cycle" is an implicit DO-UNTIL loop
surrounding the main
logic of every RPG program, controlled by a built-in
Boolean variable called
the LR ["Last Record"] Indicator. It has the additional
capability of
implicitly reading a record at the beginning of each iteration,
and
implicitly writing one at the end of each iteration).

It's been argued that
using The Cycle makes RPG programs less maintainable.
That's (to again use a
Java analogy) like saying that the use of objects makes
a Java program less
maintainable. The Cycle is as essential to RPG as objects
are to Java, and
if one's managed to overcome the non-trivial hurdle of
learning RPG's
bizarre syntax, understanding at least the basics of using The
Cycle is
simplicity itself. Of course, using Cycle output rather than explicit
output
(and, to a lesser extent, using Cycle input instead of explict input)
can
make things a bit tricky, but then again, just because your programs use
The
Cycle doesn't mean they have to use ALL of its features.

As to RPG being an
obsolete language, consider this:

1. The syntax is almost completely
different from that of any other HLL, and is
harder to read than most modern
assemblers. It was suggested that Java would
have been a failure if its
syntax had been based on Object PL/I, but at least
PL/I syntax is something
any BASIC, FORTRAN, Pascal, COBOL, or C programmer can
easily pick up. RPG,
on the other hand, is syntactically so far from any other
language that one
must practically start from scratch.

2. Even if you're opening and closing
files explicitly, there's no provision
within the language (at least in
traditional RPG) to open files whose names are
not known at compile-time. I
can't think of another language that doesn't allow
you to wait until runtime
to specify data file names.

3. Back in the heyday of RPG, trained
programmers were a rare and expensive
commodity, and canned software was
practically nonexistent, while there were
secretaries and mailroom-kids who
could wire plugboards for unit record
machines. That's why the S-3 and its
successors were designed around RPG: its
syntax was designed to be intuitive
for the thousands of plugboard-jocks around
the country. Now,
plugboard-jocks are even rarer than RPG-only programmers,
while kids are
learning BASIC and Pascal in elementary school.

In short, while I don't
see much reason to use ALL the features of The Cycle in
an RPG program,
neither do I see much reason to use RPG in the first place if
you're not
making at least SOME use of The
Cycle.




As an Amazon Associate we earn from qualifying purchases.

This thread ...


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.