RE: Compatibility across releases as curse WAS: CF-Spec - another call for ...

[Buck Calabro <mcalabro@xxxxxxxxxxxx>]

>>  Blind adherence to compatibility has lead to a situation where the /400
is
>>  putting itself out of a job, as the vintage 1980 applications it
compatibly
>>  runs becomes obsolete.  The longer we wait to re-write, the greater the
>>  chances that the application will be scrapped instead of re-written.  
>
>I would counter-propose that the very applications you defend 
>_DESERVE_ to be scrapped.  You cannot upgrade to a 
>superior application based upon an inferior database design 
>and, if you're going to redesign the database, you might as 
>well scrap the application.  

YES YES YES!  That's what I meant!  The older, primitive application as a
whole (including the database design) is being carried forward way past it's
useful lifetime by a blind adherence to the idea that "compatibility" means
"no changes are required - ever."  The idea I was struggling to write about
is that business owners confuse the idea of "the existing apps will run
under V5" and "our business will run just as well without any changes at
all."  All too often, we move to V5 and never take advantage of it's
benefits, simply because our V1 code runs fine under V5 just as it is.

>I think that it's the major ISV's blind adherence to the data 
>constructs that they used when DASD was expensive 
>(or nonexistent, in some cases) that has created this hodge-podge 
>of applications that is _UNACCEPTABLE_ by today's 
>software standards.  This has nothing to do with hardware or 
>software compatibility, it is a simple refusal by the vendors 
>to invest the money required to create an entirely new 
>product -- much cheaper just to graft new "features" 
>onto what we already have, eh?  New technology has merely 
>enabled us to have GUI versions of 1980's software, IMO.

This makes a lot of sense, especially if the ISVs continue to use V1 coding
practices to make modifications to the package.  Truthfully, I wasn't
thinking of ISVs when I typed my note - I was thinking of shops that "grow
their own."  You've made a good point here!

>I've griped about it before, but I think it's worth repeating -- 
>application software for the AS/400 is _HORRIBLE_.  
>Features that I added to software 18 years ago (like alpha 
>search, table driven business rules, event driven processing) 
>on a system that didn't support alternate indexes or logical 
>files are _JUST NOW_ becoming prevalent on the AS/400.  
>The stuff is "buggier than a 'No Pest Strip', and you have 
>to convice the vendor that any problem you encounter is 
>_THEIR PROBLEM_ before you can get a resolution -- even if 
>your _EXPENSIVE_ service contract is up to date.

It comes back to training, or the lack thereof.  How many ISV programmers
are firmly grounded in any CompSci theory before they start?  How about
AS/400 specifics?  Do ISVs aggressively train their programmers to keep them
sharp?  Does anybody?  I'd bet that the sharp midrangers are self-starters,
highly motivated to learn for themselves.  But there aren't that many
sharpies - there are many more like me somewhere in the middle of the Bell
curve. :-)

>Yes, those lucky enough to be on "home grown" systems 
>can modernize, but the code alone isn't going to get it.  
>You have to start at the heart -- the database.  
>Not an easy proposition in _ANY_ organization...

Yes!  You say it so much better than I did!  I might be able to sell a
modernisation plan if I had to do something of a re-write anyway.  When we
moved from the S/3 to the S/38 we took the opportunity to re-do some of the
database that supported our interactive workload.  We had to re-do the
interactive stuff because CCP was not very compatible with subfiles.  The
batch RPG II was so compatible with S/38 RPG III that we couldn't justify(!)
modernising everything.  We were able to use "incompatibility" as a way to
sell modernisation to an unwilling management.

>>  I'm just so tired of looking at 1980s vintage "load, sort, print."  
>>  At some point, isn't there going to be some incompatibility in order to
>>  advance?

>Not that I want to quote him but, "I feel your pain."  But the 
>database has to change before any change in the application 
>can be realized.  
-snip-
>Incompatibility has always been there, but better 
>applications have to start with more than just a new language.

Amen!

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