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