RE: [WEB400] Release incompatibility (was HTTP 500)

["Reeve Fritchman" <reeve@xxxxxxxxxx>]

I haven't been exposed to the Java Toolkit either but you have my
sympathies; deprecation messages are as good a solution as is available.
But that implies planning and announcement of future products, and the
lawyers...well, you know.

Regarding a "pass-through", I agree; IBM has to consider their customers'
investment in code.  Over the years, that's been a big selling point, and
IBM can't surprise us with a mandatory change three months before a release
goes to GA; we need to know at least two years in advance.  If we wanted
land mines, we'd be writing Windows applications.  Or iSeries Java.

Maybe I'm a naïf, but I've got to believe there's an ulterior motive for
this API name change.  It might be a *really lousy* reason, but somebody had
to go through a lot of work to do it.  I hope the naming-convention cart
didn't get in front of the common-sense horse this time.

The situation in question challenges conventional wisdom, no, it challenges
the existence of conventional wisdom.  On a forward-looking basis, however,
it seems that the question of how long to keep certain functions on life
support is legitimate, if for no other reason than old stuff adds to general
overhead.

There goes my SBMDBJOB...I guess I'll have to belly up to the REXX bar.

-----Original Message-----
From: web400-admin@midrange.com [mailto:web400-admin@midrange.com]On Behalf
Of Joe Pluta
Sent: Saturday, February 09, 2002 3:29 PM
To: web400@midrange.com
Subject: RE: [WEB400] Release incompatibility (was HTTP 500)

> From: Reeve Fritchman
>
> Joe, it's unusual to spot you on a soapbox :)!

<smirk>

> Unfortunately, the Blue party line will be, "Do you want us to limit new
> functionality by maintaining 100% compatibility with
> old/obsolete/unsupported releases?" Even more unfortunately, there is
> economic merit (for both vendor and customer) in answering that question
> with a "no".

While a valid argument, Reeve, it doesn't apply here.  No functionality was
added by the service program name change.  If they absolutely HAD to change
the name (for some internal consistency issue), then IBM could have provided
"pass-through" procedures in the old service program that simply called the
new procedures in the new service program.  Coupled with some nasty
deprecation message in the bind step, and the problem would have been
avoided.  It would then have become a performance issue, but one we as users
could address at our own pace.  Forcing a programming change for something
as unnecessary as a service program name change is unconscionable.

> IBM has done pretty well in keeping things
> consistent for many
> years and we've developed a zero-tolerance mentality to system
> changes.  How
> much are we missing because of "compatibility"?

I submit we're missing nothing, at least for this recent rash of "little"
changes.  I'd go through the litany of what they did to us with the Java
Toolkit, but that's rehashing old news.  Suffice to say that while the
toolkit is probably one of the finest pieces of software IBM has released
(doubly so since it's free AND open source), the release management of the
software has prompted me to have to make all kinds of changes to my software
just to support release to release changes.  Since when did I have to query
the OS/400 release to figure out the name of a command?

Honestly, I had no problems with the CPF-OS/400 changes, even though some
were substantial and they made our lives miserable for a little while over
at SSA.  But IBM had a great migration utility and gave us a lot of time to
be prepared.  On the other hand, these "little" unannounced changes,
basically land mines that we only find when they blow up in our software,
are unacceptable.  Spoiled?  Sure.  But for a good reason.  IBM, at least
once upon a time, actually knew how to develop and deliver software.  This
apparent trend towards the Microsoft betaware ("It compiles... ship it!")
philosophy is a bad move for us, for our clients, and for our industry.

Joe

_______________________________________________
This is the Web Enabling the AS400 / iSeries (WEB400) mailing list
To post a message email: WEB400@midrange.com
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/cgi-bin/listinfo/web400
or email: WEB400-request@midrange.com
Before posting, please take a moment to review the archives
at http://archive.midrange.com/web400.