|
James, In a message dated 1/14/00 7:33:13 AM Eastern Standard Time, email@james-w-kilgore.com writes: > I hear what you're saying. > > The fact that the B series had a S/36EE so IBM wouldn't lose their loyal > and happy S/36 customer base has locked IBM into upward compatibility > and made the customers complacent and reluctant to adopt newer/better > methods. Nice that someone got the point so early ;-)! > Maybe the Y series should have been the path to the 236 and the B series > could have separated the wheat from the chaff. The 436 would have been > the appropriate migration solution. Not a bad idea. Too bad IBM didn't think about it. The Y series was no more an "AS Entry" box than was the HP 9000. > Just a thought, how about making something old new again. The S/38 did > not have a S/34EE but did have a migration tool. What if IBM would have > made a model change where RPGII/RPGIII were not supported but > converted. Even at V3 a site could choose RPGLE, but have no real > compelling reason to switch to RPGLE, and that's a no brainer. A model change is eventually inevitable. Unfortunately, IBM seems to be more into "rebranding" of late than the true innovation that their patent filings would intimate. IBM's midrange offerings other than the AS/400 still leave something to be desired, yet those "other" brands continue to get more advertising funding for the same reason that we're griping here about RPG -- people that own them refuse to move. Your suggestion would be essential to the survival of the new model, but would also open up existing customers to "comparison shop" other vendors. I don't think that IBM is innovative enough to take that chance. > Once you're there, you'll use every feature at your disposal. IMHO, V4 > could have been a good place to make such a separation. It leaves me > wondering, if a 7xx machine runs a S/36EE, which big name customer is > IBM trying to make happy? I think that the /36EE is more of a habit now than an actual requirement. > Historically, IBM only develops products for large clients and offers > that solution to the general public as an afterthought. Like, I've been > told that the only reason the 5363 existed was for the US Postal service > and Farmers Insurance. The rest of the users were nothing more than > filling plant capacity to reduce cost to the only clients that mattered > to IBM. Not hard to believe. What _IS_ hard to believe is that IBM would sell a "C" model AS/400 running the /36EE that ran _SLOWER_ than a 5363. > It's late and I'm starting to ramble, but I hear ya. Maybe the AS/6000 > will be the machine to kill off the old code. Probably won't happen. To pull together a few threads that I've been griping about of late: 1. The new /400 cannot survive without new techniques. 2. Unfortunately, the old /400 has many _SOLID_ mission-critical applications that would not necessarily translate to another company, but serve their current company well. 3. Other than JAVA, /400 languages (including COBOL) do not translate well to other platforms. 4. Many AS/400 programmers are simply _INTRACTABLE_, and refuse to move to another language of any kind. I remember a client that my old boss used to do work for that changed his signon so that he had to answer "COBOL" to the question "What is the best 3GL language in the world?" Language wars serve nobody other than IBM's competition, and to prove the ignorance of those espousing one over another for other than technical reasons. I seem to recall writing an application in REXX (hard to do without any examples or mentors) for a paging (i.e., "Change tapes" to a pager) function because REXX was the only application that supported variable length parameters (or for some other reason, that was eight years ago). Use the language that supports your _BUSINESS_, not the one that you know only _BECAUSE_ it's the one you know. To do less is to do a disservice to your employer... JMHO, Dean Asmussen Enterprise Systems Consulting, Inc. Fuquay-Varina, NC USA E-mail: DAsmussen@aol.com "Experience is a wonderful thing. It enables you to recognize a mistake when you make it again." -- Anonymous +--- | This is the Midrange System Mailing List! | To submit a new message, send your mail to MIDRANGE-L@midrange.com. | To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com. | To unsubscribe from this list send email to MIDRANGE-L-UNSUB@midrange.com. | Questions should be directed to the list owner/operator: david@midrange.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.