Re: Compatibility across releases as curse WAS: CF-Spec - anothercall for ...

Oh, Buck,

In a message dated 8/12/99 1:21:16 PM EST, mcalabro@commsoft.net writes:

>  Colin,
>  
>  >One of the AS/400s main strengths is its compatibilty across 
>  >releases. Are you saying that idea is a bad thing?
>  
>  I would respectfully answer that it might be a Bad Thing indeed.

<<snip>>

>  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.  If we
>  use a new, not-so-compatible version of RPG IV as an excuse to re-write AND
>  we use modern, modular techniques to do it, we'll be in a better position 
to
>  face the changing business rules of the next 20 years.  The alternative is
>  to sell management on AS/400 Java when it comes time to scrap the existing
>  apps, I guess.

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.  While I agree with your "Blind 
adherence to compatibility..." comment in part, 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.

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.

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

>  Some businesses operate in an environment where their business rules 
haven't
>  changed since the '80s.  Compatibility is a godsend for them.  They can get
>  more horsepower without having to touch their software.

And they survive only because of an established, happy, customer base and/or 
lack of effective competition.  The business rules _HAVE_ changed, it just 
hasn't been important enough to tell anyone in IS unless new government 
regulations, commission schedules, or marketing campaigns become involved.  I 
have an old client just like this!  Exclusive vendor in the area for several 
niche products.  They had the foresight to upgrade their S/36 5363 to an 
AS/400 C10 ten years ago, but only because they wanted new functionality in 
their legacy OE/I system to support vendor demands so they wrote off the 
hardware as part of the required software changes.  We redesigned the 
database, rewrote the application, and debugged the vendor's problems in the 
core accounting system that had just been migrated to the /400.  Meanwhile, 
all the secretaries were upgraded to brand-spanking-new _TYPEWRITERS_ with 
attached VDT's during the first wave of cheaper PC's and decent alternatives 
to IBM's pricey 5250 emulator cards!  Doing _JUST_ what it took to get by, 
instead of looking at the big picture.  Wonder what compatibility will do for 
them when they can't get a decent person to work on their archaic junk?

>  For companies where the business rules change by the minute and we are
>  forced to try to maintain this "compatible" code on a daily basis,
>  compatibility is an excuse for management to not spend the time and money 
to
>  do the job properly.  Or perhaps it's our excuse for taking the easy way 
out
>  rather than try to create a new plan, sell it to management, construct, 
test
>  and implement it.  I don't know.  I'm just so tired of looking at 1980s
>  vintage "load, sort, print."  Remember that I'm not talking about a single
>  program, but all of the programs that make up an application.  We can
>  re-write individual programs one by one to modern standards, but that won't
>  help much with the old business rules that the application as a whole
>  encapsulates.  
>  
>  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.  Before I 
worked with software houses on the AS/400, I utilized every new opcode that 
came out (sometimes to my detriment when the customer was on an older release 
of OS/400).  I ordered the "DDS Windows" PTF back at V2R1M1, and fought 
through the lack of documentation to discover the need for the use of a 
"dummy" record format.  Incompatibility has always been there, but better 
applications have to start with more than just a new language.

JMHO,

Dean Asmussen
Enterprise Systems Consulting, Inc.
Fuquay-Varina, NC  USA
E-mail:  DAsmussen@aol.com

"Slumps are like a soft bed.  They're easy to get into and hard to get out 
of." -- Johnny Bench
    
+---
| 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
+---