|
Jon - my whole point is that a 32 year old language (COBOL 68) has more of the basic requirements of structured programming than RPG 4 has today. I think it is laughable. I too defend RPG outside the AS400 community, but it is not a glowing example of what a language should be like in the 21st century!
My responses are below in blue. Nothing personal of course, all in fun!
-----Original Message-----
From: Jon.Paris@halinfo.it [mailto:Jon.Paris@halinfo.it]
Sent: Wednesday, December 01, 1999 4:30 PM
To: COBOL400-L@midrange.com
Subject: RE: Welcome new members
For the most part I agree that there are still a number of features that are
present in COBOL that RPG lacks. As to your individual comments:
- Indented code
This is supported to a limited degree in D specs and C specs. There will likely
be full support in C specs in the next RPG release.
Jon - Where can I indent code?? Simple stuff, like:
IF cust-not-found
initialize cust_rec
END-IF.
The only indentation allowed is so trivial and unhelpful to readability that it is a giant leap to even think that indentation is supported in RPG4.
- long field names (and be able to use them in calcs)
You mean 2056 characters isn't enough <grin>. In practice I find the current
(practical) limit of 14 to be more than adequate. If I recall correctly the
COBOL maximum is 30 but I never used them all. By contrast RPG supports 30 digit
numerics while COBOL's default behavior is still 18. Now that _is_ a limitation
that I have hit.
Where can I use long field names? Not in most calcs! Only a few select places. As long as we have fixed columns, long field names are not worth the trouble because they are not usable in most calcs.
- record handling
Not clear what you mean by this. By using RPGIV's externally described DS
support together with the Prefix keyword I can handle things at the record
level.
Yes - with any language anything CAN be done. The question is how difficult is it to do. With RPG, record handling takes the extra steps of setting up a DS for each record. So no-one does it. The vast majority of RPG programmers think that data integrity consists of locking records until a user rewrites a record. Few compare the before and after images of records because RPG makes record handling difficult. It has gotten better, I admit. But the lack of access to the entire record in each file seems silly to a COBOL pgmr.
- error trapping in free-format calcs (like EVAL x=y * z ON ERROR do something
else)
This has been "announced" by IBM in the form of the MONITOR group, which in many
ways is superior to COBOL's On error (which doesn't handle all errors by the
way). They are considering the possibility of allowing this to be more granular
(a la COBOL) but MONITOR is probably better since in general I don't care if a
single statement "blows" I want to know if anything goes wrong in a logically
related group of statements.
Listen to your replys, Jon. Yes, maybe someday RPG IX or RPG XVIII will have these basic requirements of a 1968 programming language. But COBOL had them 32 years ago! I have a funny feeling that RPG will not be around to see a version that supports these basic requirements!
Meanwhile, little time bombs are built into almost every RPG4 program, because the EVAL cannot trap overflow errors when a user keys an item number into the qty field!
Unlike the ADD and MULT opcodes, there is no compiler option to keep going.
- data replication: move CORR to replicate data to fields of same name in other
records
There has never been a need for this in absolute terms since you cannot have two
fields of the same name in different structures. I would love to see them do a
similar thing though where the field prefix governed which fields were alike.
- (and the converse: unlike RPG, dont replicate the data if the programmer
doesnt want to!)
You can already handle this with Prefix at the file level.
Again, any language can be made to do anything. A perfect database would have customer number described only once, CUSTNUM, with the same field name in all files. (Like Query/400 does, with separate prefixes to identify which table the field is from). RPG makes this impossible. RPG doesn't even allow us to have the same field name in a database file and a screen format, which makes screens and reports a maintenance nightmare.
Yes you can use the same name, but then you can't adjust the field lengths on the screen or report, you can't compare the screen field to the DB field to check if the user really changed it, etc, etc.
Using 1000 different names for CUSTNUM in a system creates a maintenance nightmare, and RPG forces us to do this.
The one biggie that COBOL is missing for me is prototyping of program calls and
the ability to define subprocedures. These have made a huge difference in my RPG
coding but I can't do it in COBOL.
I'm sure that everything in the world has some advantages over other things, but lets keep this in perspective. If you are comparing languages in 1999, you can't use COBOL/400 which hasn't had any money pumped into it for years. Compare RPGIV to one of the COBOL compilers in the PC world where there are daily enhancements!
+---
| This is the COBOL/400 Mailing List!
| To submit a new message, send your mail to COBOL400-L@midrange.com.
| To subscribe to this list send email to COBOL400-L-SUB@midrange.com.
| To unsubscribe from this list send email to COBOL400-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com
+---END
As an Amazon Associate we earn from qualifying purchases.
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.
midrange.com
