RE: Release incompatibility (was HTTP 500) -- WEB400

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