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

Buck,

If tech savvy managers are not moving to RPG IV because they don't have
programmers who will be able to maintain it (as suggested in several other
posts) how will adding yet another flavor (the CF-spec) enhance the
manager's willingness to use RPG IV? I believe it will not. It will have the
opposite effect, hence my dislike of introducing the CF-spec today. Perhaps
after a few years of RPG IV code, if people want to go the 'RPG V' route,
then sure, go ahead, but in today's world, CF-spec will kill RPG IV.

But, hey I only speak from talking to thousands and thousands of RPG
programmers, not a few dozen respondents from this mailing list (as IBM
apparently does).



Bob Cozzi

http://www.RPGIV.com




> -----Original Message-----
> From: owner-rpg400-l@midrange.com [mailto:owner-rpg400-l@midrange.com]On
> Behalf Of Buck Calabro
> Sent: Tuesday, August 03, 1999 9:37 AM
> To: 'RPG400-L@midrange.com'
> Subject: 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
>
>

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