|
I've got a situation that's starting to rear it's REALLY ugly head. This situation occurred prior to my arrival here and the principal player in our organization with which this situation occurred is long gone. As you read this, please note that I AM NOT JOKING! Everything I present below is "factual" as has been told to me by IBM. We have two AS/400s (both 9406-510's running V3R7) at two of our branches whose serial numbers begin with '44'. According to IBM, '44' indicates that the box was manufactured outside the U.S. and a serial number beginning with '10' indicates that the box was manufactured inside the U.S. The problem is that IBM's records show these two systems as beginning with '10' with the correct last 5 digits of the serial number. This apparently was not a problem with all of our previous dealings with IBM since I was told that, normally, IBM only refers to the last 5 digits of the serial number, ignoring the first 2 digits. Several weeks ago, with my new responsibilities to manage all of our AS/400's, I attempted to use SNDPTFORD to order SF98370 (PSP). The system dialed up IBM, connected, but was returned a message from the IBM connection that " Service requester not registered with IBM Service." (CPF8C3B). After various calls to our marketing rep, the branch's C.E., and several other IBM'ers patched through on conference calls, over several weeks, this is what I'm being told: Basically, IBM is, for reasons unknown to me or anyone at IBM that I've talked to, unable to change their systems to show that the serial numbers on the two affected boxes are, in fact, 44* boxes, and not 10*. What they *are* supposedly able to do is to "flip a bit" that stays "on" for a period of time (have not been told how long a period of time that is) that will allow me to use IBM to order cume PTFs and MF PTFs (we do not have a software contract with them, and I am unable to find paperwork that would tell me whether we have any with a BP from whom we may have obtained the system from man, this s*cks!). Also, there is a unexplainable delay for when the "bit" is turned on; I was told I'd have to wait SIX weeks for the "bit" to be turned on!!! Upgrading the OS on these boxes supposedly wouldn't solve the problem either, even with the subscription service, since IBM will still see our boxes as 44* instead of 10*. If I were to attempt an upgrade to V4Rwhatever, I would have to make absolutely certain that I had a wide enough window for the "bit" to remain turned on, or else I'd have to wait another SIX weeks to turn it back on. It gets better. Last week I politely complained to our marketing rep that this was causing undue hardship on our company and wanted someone, anyone, at IBM to fix this problem once and for all. It was then that she told me that we wouldn't want to do that because if we do, all future software orders for these two boxes would have to be handled from overseas, which she strongly suggested that I would not want to do. Even if it could be done that way, she said, doing so would cause us to lose the ability to transfer our licenses over to any new AS/400 we would replace the existing AS/400s with (something that will probably happen within the next two years). Again, and in the words of Dave Barry, I am not making any of this up! This whole issue has the potential to explode to the point where my company discards the AS/400s with a more generic solution at the branches. In fact, I have already been called upon by my managers, as part of their new due diligence responsibility, to make the case for replacing the AS/400s we have with new iSeries boxes instead of a more generic server. I have made what I believe is a compelling case with them to stay on the iSeries architecture, but IBM certainly isn't making my job any easier. Has ANYONE had to deal with this type of problem before? PLEASE, try to keep to the topic with useful dialog! With that in mind, all thoughtful replies are solicited and deeply appreciated! Dan Bale IT - AS/400 Handleman Company 248-362-4400 Ext. 4952 +--- | 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.