Jerry,
1) I concur with your opinions regarding RPG, as it evolves. That is
the native language for OS/400 on the iSeries platform. IBM had made
concerted efforts to make the language more OOP friendly. They have
introduced ILE which conforms more strictly to some of the other OOP
methods. My comments were geared more toward the "older" methods of
coding that still embrace the RPG II, RPG III and COBOL methods of
coding. From a business perspective, for IBM to continue to support
changes in (I apologize in advance COBOL developers) archaic languages
is the equivalent of MS Windows and Linux OS developers to provide code
to reverse engineer machine code changes in PASCAL and Assembler. It
doesn't fit with the future of the processor technology. The primary
reason that IBM can still offer these products on the System I platform
is due to the employment of several engineers to make it happen. If and
when IBM decides that the next release of the OS shouldn't contain the
translation mechanisms due to cost constraints, support for the
previously embraced languages will wane. That is the nature of
business. I would rather make 90% of my customers happy and enjoy the
benefit of future prospects than cater to 10% of my customer base and
forsake future growth without justified annual funding to support that
10%.
2) With regards to your COO comment, I understand completely. I also am
of the mind set that "customized" reports should be at the hands of the
requestor based on criteria. If spool files and DDS screens are your
only source determination, then your approach is duly merited. I,
however, have been forced into a situation where reports must be
available in multiple formats. With that in mind, it doesn't make sense
to duplicate the processor in multiple formats. The data will remain
consistent regardless of the output options. If a program is written,
for example, to only interact with Interactive objects, it requires a
duplication of code to interact with external processes, like stored
procedures for web based results. The two (or more) programs would
benefit from the same mechanism to generate data and only require
specific coding for output.
Tom Armbruster
-----Original Message-----
From: rpg400-l-bounces@xxxxxxxxxxxx
[mailto:rpg400-l-bounces@xxxxxxxxxxxx] On Behalf Of Jerry Adams
Sent: Wednesday, December 19, 2007 1:50 PM
To: RPG programming on the AS400 / iSeries
Subject: Re: RPG Cycle (was Multi-Occurring DS)
Armbruster, Tom wrote:
<snip>
I believe there will come a time when IBM, as it has done in the past,
will ultimately
dictate to conform or perish.
</snip>
I have tried to come up with a case, as regards RPG, when IBM has ever
removed anything. The only thing that I have been able to recall (I
started on a System/3) are devices; MFCU and DISK40 would cause an RPG
program (even II) to barf on the i5. I had to help port a S/3
application to an AS/400 some years ago, and the only thing I remember
that had to be changed was the F-specs.
Though I'm sure the compiler writers would love to chuck some of the
"old" stuff, they won't / can't. IBM does deprecate (strongly
discourage) things sometimes, such as not allowing MOVE in /free format
- but the compiler handles it fine if one wants to take the trouble to
code the /end-free MOVE /free set.
Outside of RPG, IBM has deleted many products, including compilers, from
the product lines. Or simply refused to bring them to the next
platform. But the discussion is the RPG Cycle, not other products.
<snip>
With a normalized database,
appropriately keyed files and valid logic, there should never be a
reason to read every record in a file. This is an old method which
requires high I/O and introduces entirely too many logic errors for
which to compensate. It also reduces the extensibility of the end
result.
</snip>
Ninety-nine percent of the time I am dealing with a subset of the
database. Even when I'm dealing with the entire database, I'll usually
wrap the file I/O in a DO loop - but sometimes it is just easier to let
the cycle help. Perhaps it is because I started on a S/3 that the cycle
doesn't frighten me, but learning and using embedded SQL, IFS access,
and prototypes didn't fright me either (just slowed me down a bit the
first time).
If by "extensibility" you mean (I apologize if I'm putting meaning to
words that you did not intend) being able to invoke an RPG
routine/function from, say, a web site (a customer wants to see their
order status, say), I fully agree. But, if I'm writing a report for our
COO (and, love 'im, he comes up with a new one every other day), I'll do
it the quickest way possible. And things like level breaks and MR have
been around for a long time - meaning that the bugs are probably out of
the compiler features.
Thanks.
* Jerry C. Adams
*IBM System i Programmer/Analyst
B&W Wholesale Distributors, Inc.* *
voice
615.995.7024
fax
615.995.1201
email
jerry@xxxxxxxxxxxxxxx <mailto:jerry@xxxxxxxxxxxxxxx>
midrange.com
