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

I agree - since when did an api become release dependent?
jim

----- Original Message -----
From: "Joe Pluta" <joepluta@PlutaBrothers.com>
To: <web400@midrange.com>
Sent: Saturday, February 09, 2002 1:37 PM
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.
>
>