× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



It's reasonable to assume CPF and some components of OS/400 are closed for
tactical (business) reasons.  Intellectual property unprotected by patents
almost certainly exists, and it doesn't make sense for IBM to give it away.

The tactical reason for protecting (hey, IBM: this is your new spin verb)
key components of OS/400 is to protect the reliability of the product.  A
marketing target for iSeries is those darkened rooms full of H-P, Dell, and
Compaq servers, and one of the arguments against the
all-your-eggs-in-the-iSeries-basket is that an iSeries system failure brings
everything down.  Yes, the loss of a key server can bring a server farm down
too, but the loss of the accounts payable server will not stop the rest of
the business, and if you consider the odds of a server failing to be equal
regardless of the application, server farms have merit.

IBM's hardware reliability is generally excellent, even considering the rash
of disk drive problems.  Software reliability is much more challenging
because of the staggeringly large number of combinations of user and system
actions and the consequent results.

Unprotecting OS/400 would slow the development process and make OS/400 more
expensive because IBM would be compelled to document OS/400 internals and to
honor the published interfaces.  With the exception of library list
processing, API interfaces have remained constant; it's likely IBM won't
release an API until the underlying function is stable.  Also, there
certainly must be provisions for proposed future functionality hidden in
current code and opening the code would reveal IBM's direction...and IBM is
under no obligation to do so.

IBM will unprotect more of OS/400 if the market demands it, but I suspect
there's quite a lot in the pipeline for OS/400, including its rebranding,
the demise of the iSeries product line, and the announcement of a new
bottom-to-top product line as revolutionary as the System/38.  The long-term
strategy will be subjected to market forces demanding "openness".

Perhaps some MI experts could weigh in here: does OS/400 "protection"
eliminate the possibility of OS/400 viruses?

I'm an applications guy and lost my addiction to internals when I put my CCP
manuals on the shelf.  I still like to know, but I just don't do anymore!
Perhaps it's my ignorance that makes me comfortable with knowing I can count
on certain functions to work across systems and OS/400 releases.  If some
customer propeller-head diddles OS/400 and my ERP application crashes, the
customer will blame my application and I'll be stuck with repairing the
damage regardless of who's to blame.

You can extract a remarkable amount of information with API's.  An iSeries
can communicate with anything under the sun.  Functionally, what more do we
need?  Yes, these are certainly fringe areas where 3rd party developers
could come up with some interesting functions.  But would these incremental
"improvements" be worth the loss of our confidence in the integrity of
OS/400?

Reeve Fritchman
reeve@ltl400.com






As an Amazon Associate we earn from qualifying purchases.

This thread ...


Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.