RE: RPG IV and CF-spec "keep it IBM"

Bob,

>You make some good points but also have a lot 
>of incorrect assumptions.

I just gotta be me!  :-)

>First RPG pretty much supports the entire set of other 
>programming languages for the AS/400. Without RPG 
>revenue Toronto might have been closed (my opinion)
>on a business decision.

I agree completely, but I think that the RPG II version of the compiler is
what is generating the bulk of the revenue, and Toronto doesn't have to
enhance that one whit.  Before I die at the stake, look hard at the sales
numbers - all those AS/36's and S36EE machines are not running RPG III, and
a small fraction are running RPG IV.  Really, only those of us who came off
a /38 are running RPG III, and there's quite a bit of S/36 logic in that
legacy code...  Folks in these environments are standing pat: they don't
need new function in RPG II or RPG III.  They just want faster machines to
handle the workload.  I think we could all agree that RPG IV is not driving
the revenue stream, and I'm not thinking about "RPG" in general (whatever
that may be!), but whether RPG IV should have been so compatible with RPG
III.

>Next, I think the adaptation rate of RPG IV is increasing 
>on an almost weekly basis. Now that this Y2K distraction 
>is finally dieing down, companies are spending money 
>on RPG IV training (believe me, I'm pretty booked this 
>year, whereas last year it was pretty dry).

This is good news indeed!  I can tell you that it is still a struggle to get
management types to look at using RPG IV - despite the fact that it is
convertible from RPG III.  The main "reason" you hear is that "nobody but
you will be able to maintain it!"  As if newbies will be able to maintain
the indicator-laden, GOTO-filled, RPG III mega-monsters now in production.
Who gets to maintain that stuff?  Me, the old timer, who's seen this crap
for ever.  The new guys work on development, and do you know what they use
as a model for the new code?  The old code!!!  It never goes away, it just
gets copied over and over into new work.

>The issue for me is not fixed vs free-format. It is legacy. 
>RPG IV apps are fixed format and they usually work. 
>I can go write code in Java or COBOL or C++ or 
>C if I don't posses the skill to adapt to RPG IV's format, 
>and can only write pretty code in these free-format 
>languages. I'm not looking for the end-all here.
>RPG IV simply not the language of word processors, 
>a cool Palm Pilot app. It is however, great for 
>general purpose business applications. Good or 
>bad, RPG IV had fixed format, so my RPGII and 
>RPG III code will be there for another 20 years. 
>I need to be able to support those applications.

This is the other side of the same coin I'm looking at!  Having had to
maintain that 20 year old code for, well, 20 years has completely soured me
on keeping it around any longer.  Come on, "load a work file, sort (ooohh
let's use OPNQRYF then CPYFRMQRYF instead of FMTDTA!) and print (update too
if U1 is on)" just isn't cutting it any more.  The reality is that these 20
year old programs are not going to gain the slightest benefit from being
walked through CVTRPGSRC.  They are doing just fine in their original RPG II
or RPG III form, and that's why there's such resistance to using RPG IV.
There's no business case for anybody except an ISP to move to it.
"Preservation of investment" is a powerful argument for maintaining the
status quo!

>I would go so far as to say it is a life-saver for the AS/400. 
>If RPG went away, a reason to stay on the AS/400 would 
>go away. 

We agree again - just about.  I would re-state that this way: "If RPG II
went away..."  Remember, I'm not talking about abolishing RPG II and RPG III
- I'd leave them just as Toronto is doing.  Support them but don't enhance
them.  In my hindsight heaven I just wish they'd have made RPG IV
incompatible with RPG III so we'd have the opportunity to do the re-write
that this legacy stuff so desperately needs.

>If I have to rewrite my applications because their 
>programming language goes away, I might was well give 
>my uses a pretty application interface even if it doesn't work, 
>because they only care if it looks good, not if it runs every time.

Again, I wouldn't kill RPG III - I'd just make RPG IV better from the first
release!  

Then again, how long should a software application be expected to last
without being re-written?  How long should a business use card processing
logic for their mission critical functions?  Load, sort, print.  Even people
who think they're interactive use an interactive program to load a batch,
edit the batch, post the batch, print reports on the batch.  The S/36
replaced the card punch with a 5251 and preserved our investment in
software.  A few new interactive programs and voila! welcome to 1982!  Those
apps haven't changed since then.  Shouldn't they?

A savvy MIS director would keep the legacy stuff cooking away in RPG II or
RPG III and re-write today's applications using today's logic.  RPG IV
finally frees us of the damnable short-name, global variable curse  It's
pitiful to see brand-new RPG IV programs that use global variables, with the
same hideous subroutines called GETCUS that do a hundred things.  I would
much rather have seen that stuff relegated to RPG III and a forced re-write
to RPG IV.

>There are three compelling reasons to use the AS/400.
>The reliability
>The database
>The RPG language

Hm.  I suspect that none of these things sells an AS/400 to a non-IBM
customer.  In fact, RPG scares non-IBM people from it - mostly because of
their perception of the way legacy code was written.  I would guess that the
most compelling reason to use an AS/400 is that it "preserves your hardware
and software investment."  Upgrades, basically.

>There is way too much competition out there. 
>Oracle (a crappy database) Windows NT 
>(a crappy OS) and C++/Java (a complex 
>group of languages). End-users don't give a 
>rats butt if you write in Swahili or RPG, the want
>the pretty pictures, mostly.

We agree again!  Sadly, "RPG III compatible" RPG IV running on block-mode
5250 data streams isn't going to deliver any pretty pictures unless you
count one of the Visual RPGs - both of which require learning the Windows
paradigm.  This only re-enforces my point: nobody in their right mind
converts their legacy code into VaRPG and tries to pass it off as a client
server app.  They re-write it - at least the client side.  They try to keep
the old stuff running "as-is" on the back end while providing the client
with new, modern functionality.  In order to use RPG IV effectively, we need
to learn to use a new paradigm - structured code (not at all the same as
using IF/ENDIF.)  Converting old code does not embrace the new ideas, it
merely keeps the old ones on life support far beyond their usefulness.  I
guess that is my point.

Buck Calabro
+---
| 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