RE: Release incompatibility (was HTTP 500)

Joe, it's unusual to spot you on a soapbox :)!

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

This is one more area where we've been spoiled rotten, although there are
lots of areas where we've been abused like red-headed step-children.  Didn't
a couple of commands/etc. change early in CPF, or am I thinking about
something else?

One of the strongest arguments for compatibility is that it eliminates
problems associated with the introduction of new code.

Although I wasn't directly affected by the library list mess, I can
sympathize with those who were, especially since there's a strong argument
that this problem was an IBM design oversight with OS/400 V1R1 and never
should have shown up this late.  My iLife is not heavily dependent upon
API's (except through CGIDEV2); the problem is once the veil is torn away
from the face of compatibility, who knows where it will stop...perhaps I'd
have to go through my code and change my treasured "ROLBK" to "ROLLBACK"!

I'd like to hear IBM explain what we're losing by keeping our software "dial
telephones" in service.  With sufficient notice and overlap in old and new
functions, it might not be too bad.

Regards,
Reeve Fritchman
reeve@ltl400.com
reeve@3pl400.com
reeve@transtechgroup.com


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

>>> From: Phil Groschwitz
>>>
>>> I found the cause of the problem:  I had QTMHCGI *SRVPGM bound to the
>>> program and it needs to be changed to QZHBCGI in V5R1.

>> From: Jim Franz
>>
>> i went to the ibm link and am concerned.
>> is it saying any attempt to get environment on a V5R1 machine has to
change
>> it's code/recompile?

> From: Phil Groschwitz
>
> That's what I had to do (change the binding directories & recompile).

This is enough to get me on my soapbox.

<SOAPBOX>

When did backward compatibility lose its priority?  I absolutely love the
new capabilities of OS/400.  Unlike some who think that the new openness may
dilute the platform, I view it as an incredible opportunity to allow us to
merge our decades of application development experience with the new
capabilities afforded by TCP/IP, the Internet, Java and a host of other new
technologies.

However, the folks that are in charge of the implementation of these new
technologies seem to have missed one of the (if not THE) most crucial
strengths of the IBM midrange platform, dating back to the old System/3 (or
at least the 34/36/38): BACKWARD COMPATIBILITY.

Except for some notable exceptions (Al Barsa would point to the library list
fiasco), this is a fairly new state of affairs, and almost entirely centered
on the "new" technologies.  "Legacy" OS/400 seems to still have the correct
mindset: the fact that we were able to move CISC programs to the RISC
platform without any manual effort was, to my mind, one of the most well
executed technological triumphs of our industry.  In my opinion, being able
to move legacy programs from one machine to another has been a primary
reason for the continued prevalence of the IBM midrange platform as it
evolves.

However, that point seems to have gone by the wayside in recent years,
especially in the areas of Java and WebSphere.  There seems to be absolutely
no reluctance on the part of the development teams to make changes in the
products that break, in significant ways, existing software.  Whereas BPCS
code written in the 80's still works just fine on every release of OS/400,
my CPYSPLFPDF product has had to be changed for every release, because
someone moved an object or renamed a file or changed an API.

This is a standard practice at Microsoft, one some people see as proof of a
conspiracy of planned obsolescence, but could be as easily attributed to a
lack of basic software developemnt management skills.  In either case, we've
grown to accept it (shame on us) from the somewhat technologically
challenged folks at Microsoft.  However, it's absolutely unacceptable from
IBM, the last bastion, to my mind, of quality commercial software.  Whatever
controls used to be in place to ensure compatibility from one release to
another seem to have been completely abrogated by the "integration
technology" (for lack of a better term) teams of the OS/400 development
group.

It may be acceptable to have a few of these glitches when a product is just
being introduced, so I really didn't say much for the first few versions of
WebSphere and Java, but the trend continues, and doesn't seem to be abating.
This latest problem is just another instance of what seems to be a growing
pattern.  I mean, who decided that the service program had to be renamed?
Whoever made that decision doesn't understand the basic tenets of software
development, ones that were evidently well understood by the architects of
CPF ad OS/400.

I'm unsure what to do.  What I do know is that this keeps me from upgrading
to a new release of the operating system unless absolutely forced to do so.
The secondary effect of this is that I have to advise my clients not to
upgrade, either, until a significant amount of time has elapsed to find
these sorts of problems.

I don't know if anybody else feels this way, or if anybody has made a
concerted effort to bring this to IBM's attention.  If not, I'm tempted to
say something at the next SoundOff at COMMON.  If anybody else has similar
experiences of release incompatibilities, let's start a list of them.  I
suppose this forum should focus only on web-related issues, so only post
here if your experience is HTTP, CGI or WebSphere related.  JAVA400-L would
be a good place to post issues about Java, RPG400-L for compiler/execution
inconsistencies in RPG, and MIDRANGE-L for other things.  I monitor all
those lists.  I'll try to compile the issues in my copious free time - I
think it will be interesting to see where these inconsistencies are most
prevalent.  If you choose to participate, please keep the words "release
incompatibility" in your subject line.

Thanks!

</SOAPBOX>

Joe Pluta
Pluta Brothers Design, Inc.
www.plutabrothers.com

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