Slashdot Mirror
Preventing Vendors From Playing The Blame Game?
Johan asks: "In choosing an enterprise architecture, one of the considerations I have is support. IBM provides a good database (DB2), a bad Enterprise JavaBeans Container (Websphere) and an excellent OS (AIX). If I tolerate the delinquent EJB container I will have the advantage of one phone number to call for support and a single "point of responsibility". However, I dont want to have a mediocre architecture by getting all three components from the same vendor (IBM). I would like to get the database, EJB Container and OS from different companies (Oracle, BEA and IBM). How do I prevent (or at least minimize) them blaming each other when support issues come up? Anyone have a solution for this?"
It's easy... when you have a problem, don't bother ringing support - just Ask Slashdot
:-)
I've done tech. support and required tech. support for products like these, and I can only recommend that you not compromise by single-sourcing your products when there are better alternatives for individual components.
If you understand exactly how you are using each of these components, it will generally be self evident which one is to blame for any particular problem. Convincing the vendor can be another problem, but if you come armed with clear facts about the situation, it shouldn't be that bad.
Know your system, and how it interacts with each product. Convincing the correct support department that it's their issue isn't as bad as people would have you believe, as long as you are insistent and persistent.
scrap that sluggish Java stuff. Use Windows 2000 Server, COM+ and Micorsoft SQL Server 7 which are far superior. Write some components in VB 6 which is easier to learn and more readable than Java. Hold on for a few months if possible so you can take advantagee of VB7 and SQL Server 2000. Apparently VB7 is a great improvement over 6 with inheritance and proper error handling (no more ON ERROR GOTO ...). Remember, nobody got fired for choosing Microsoft.
Request that each company certifies their product on when in use with the remaining two.
--
--
We have fought the AC's, and they have won.
Whne you have a problem first step is to understand why you believe it is not working. This is the hardest part and it should not be your job if you are for support. It reality if you go to your tech support with the exact problem. It make everyone jobs easier.
Easy: get a "blame consultant" or "blame vendor". This is: get a guy or company (an external one, an internal employee will NOT do the trick) who/which, per contract, HAS TO solve your system problems. The idea is to set up things in such a way that if Mr. Externalguy says "Its a database problem" your answer has to be: "Ok then, call Oracle and have them fix it; if they claim it's an OS problem, then YOU call IBM and coordinate them with Oracle and whoever else to get the thing solved, Mr. Externalguy! That's the job I'm paying you for!" In short, the idea is to pay someone to serve as a "no-excuses" focal point and have him deal with as many vendors you may need.
Strength, balance, courage and reason. If you know what's this about, contact me!
If these three vendors already participate in a joint venture, perhaps a b2b or other e-commerce initiaitve, then they have a political to interoperate lest their JV be seen as a failure. If they aren't in a JV, find three vendors who are and have best-of-breed or close to it as possible.
Make sure that each part of their contract shows what part they are responcible for, there is a good example at private support.
I'm a big flaming gay nigger
My company did the same thing last year. We ended up going with AIX, DB2, and Websphere. _BAD_ choice. We've since switched a lot of what we'd hoped to use the RS/6000 for to a different platform.
The AIX has been OK, but IBM doesn't seem to know their own hardware/software very well. We've tried to order some performance monitoring software and were sent the wrong CD (three times and counting). When we discussed our performance problems (definitely not IBM-related) the senior technical person had 'never heard' of a configuration like ours (internal SSA disks). When trying to buy an extra hard drive we were promised Monday delivery. On Thursday we get a call asking for more detailed information so they can ship the right drive (even though there is only one possible drive to ship for that model/capacity).
DB2 is not a bad database, but good luck finding A: any software that _really_ supports it, and B: any DBA that can support it -- there are lots of Mainframe guys out there, but mainframe DB2 is a bit different than DB2 'UDB'. Enjoy the 1-2 books out there.
For my part I would heartily recommend looking _really_hard_ at Oracle, MS SQL server, Sybase, DB2, et. al. and verify you can: get a DBA, can find developers familiar with the database (DB2 is different enought you don't just develop and pretend it's 'any' database), and that any future software you might use supports the database.
As far as 'no finger pointing' -- getting everything from IBM does nothing to prevent finger pointing. Instead of Oracle blaming Sun who blames BEA, you'll have the websphere group blaming the DB2 group who blames the AIX group within IBM. Unless you're a really big IBM customer (read: have a mainframe or two) forget about getting it resolved instantly.
"But actually trying to use m4 as a general-purpose langage would be deeply perverse" --ESR
When you put together a mish-mash of best technologies as you're proposing, you're telling your boss that you're man enough to make it work.
That's why they pay you the big bucks, honey. Aren't goals fun?
Celebrate Adulthood - Bush/Cheney in the New Century
The answer is that these days there is no problem. All the old "big iron" companies have re-invented themselves as service supplies. Consider, for example, Compaq who bought out DEC not for their hardware or software but for their large portfolio of nice juicy service customers.
;o)
IBM is no different. All you have to do is tell your IBM rep what 3rd party components you want to run and that you want IBM to support the whole shebang. They'll be glad to do it - revenue is revenue. The one thing you'll *never* hear them say is "Er...I don't know how to do that"
It shouldn't be more expensive than paying for three separate support contracts either, in fact you'll very likely be able to negotiate a discount.
Looking beyond the obvious, you could in principle get a comprehensive support contract from just about any major service supplier, eg Compaq or ICL. But IBM are one of the best these days. They had to get that way to survive (remember how they were bleeding money a few years ago).
Consciousness is not what it thinks it is
Thought exists only as an abstraction
Since you said the magic words "enterprise architecture" I'm assuming you're already planning to spend a lot of money. That's usually a good way to start, although you have to make sure that its a lot of money relative to the amounts typically spent through your VAR, ISV or the local sales office of your company. Leverage with the local sales office is CRITICAL; these people count on your money and keeping them fat and rich will keep them loyal to you and will enable them to lean on the organization for support in ways that you couldn't. Even if you split your purchases among multiple businesses like you'd like to, you always have the leverage with each one (except IBM, since neither Oracle or BEA sell hardware) to drop its product and move to something sold by the other one. Often referred to as the "divide and conquer" startegy...
Being vocal in support groups (online, real-world, etc) that give you an option to make support statements in front of other users is really helpful. Its one thing for the vendor to lie to you in a private conversation, "We think AIX sucks and Oracle should really be run on Sun.." It's quite another for you to say in front of Oracle and other customers "Why does Oracle have these bugs on AIX?" If your claims are true, they'll have to address the problem in a more constructive manner, especially if you've brought up this problem publicly before. They're much less adept at finger pointing in public.
In a slightly simimlar manner, I had a problem with my home DSL service. My ISP for DSL was also my business ISP. The ISP kept giving me a rash of crap and foot dragging about their inability to deliver advertised bandwidth. Finally I sent a message to the technical suport mailing list for corporate customers asking why DSL bandwidth was so lame and why engineering was too lazy to look at it (not those exact words, but that exact meaning). Within six hours I had an email from a senior engineer and two phone calls from the director of operations and the director of engineering. The point is that public humiliation is a powerful tool..
The downside to buying everything from one shop is that they might tend to look at you as a bit easy. If you were willing to spend all your money with them, why won't you believe everything they say?
In my current job, I'm using AIX and Websphere (though not EJBs). I've not found any problems with Websphere at all, it was simply a matter of configuring it and letting it run. I was wondering what problems people had encountered with it which made it a bad choice ?
You buy single vendor support, usually from one of the big systems integration houses:
The above is obviously a sale blurb (and not directly relevant to your problem at that) but you get the idea: Pay somebody lots of $$$ to make them own the problem. I'm sure there is a growing market for this type of services.
I can't really recommend anybody for your particular problem.
---
"Where do you come from?"
Hi!
I work for IBM (full disclosure :) supporting a major telco. This telco has Sun, HP and IBM servers with the whole lot supported by IBM. I personally support the HP servers and know next to nothing about IBM servers (ironic I think).
So referring back to your question, simply select the bits and pieces that you want to run with and then get a major service supplier to bid on supporting the lot. You'll find that all of them will be more than happy to support whatever you have.
Just choose IBM since they are the best! (wearing my big blue IBM underwear on the outside :-)
If you have a bunch of lousy developers, yuo will be in trouble. Good tech support or not. Chances are that you might get better developers on board if you go for solution X. Once a crap system is build, no tech support in the world can save you.
Even with the best selection of vendors, you cannot escape a certain amount of "not my problem; it's him" finger pointing. The reason is simple; when something breaks, you are not dealing with a hive-mentality supplier where everyone in that company knows everything about the company's products. You will be dealing with individuals. And usually, the first person dispached on a problem call is the lowest-ranked, -paid, and -trained. And a large percentage of such, if they can't resolve the problem, will resort to finger-pointing instead of calling their next level support.
As suggested elsewhere, you (or someone in your shop) will need to be learn enough about the entire installation that you can tell when someone is pouring lemonade in your ear and saying it's rainwater. Don't just give some surplus manager the title of "Architect" and let it go. Find a techie who knows how to back off and observe.
Other suggestions:
Getting reps from all suppliers in the same room is a good idea, but not generally possible until you have been down much longer than you want.
Don't be afraid to "escalate" the problem. If the first response body can't / won't solve the problem, ask for a manager. Managers don't like talking to customers, but the good ones like even less having unhappy customers because of untrained employees or employee attitude. Odds are that the manager may not even know about your problem (other than "there was a ticket but we closed it").
If you find a support rep who really knows her stuff, saying "thank you" never hurts. (Lots of customers think it does.) For a really good job, a note to the salesman (to be forwarded to the support boss) will be appreciated.
Sometimes, it is possible to request that a particular support rep be assigned to your account. If you find a good one, do so.
Bottom line: support reps from the suppliers are not your employees and so do not care quite as much about your company's problems as you do. Since you cannot completely avoid getting involved in problem resolution, get trained. Get multiple people trained.
I live in Texas - I would probably get shot for driving around with those stickers. I love em though!
"For the children!" - Vote Republican!
One good way of minimizing vendors blaming each other is making sure your product works with components from at least two vendors. Then you can always substitute the faulty component of the package, and tell the vendor whose software faulted that "when I replace this with , the problem does not occur". Sometimes it's enough that you support several versions of the same vendor's product, but for best results, you need to support different vendors' products.
For some reason, it seems that when you tell a vendor that you are readily able to replace their software with someone else's, they respond much better to requests for support.
The same works other way around too. If you have vendors blaming each other, you just need to replace one of the components with something else, and you are able to say the problem was or was not corrected by replacing that component.
If none of this is possible for your product, then the only real alternative is to prove your point by producing a test driver that only uses one of the products [again replacing other products with something else], but is still able to reproduce the problem.
-- Esa Pulkkinen
I have found that using Sun Hardware is a really good solution to your problem. Sience Sun like IBM will use a costom disigned OS for its arctecture (Solaris/SunOS) and Sun offers good support and the Solaris Software is really flexable. If you start off in a small company and use the smallest of Suns equiptment then your company grows and your purchase the the most powerful Sun System (The Enterprise Ultra 10000 (Dool)) Your software will work on the upgrades with a minum in configuration while with the other Unix arcetures you may be required to to a bunch of patches that actually take the blame away from IBM because they will no longer support your hacked configuration. While with sun you dont need to hack your configuration.
If something is so important that you feel the need to post it on the internet... It probably isn't that important.
This isn't Dell supporting your new PC with Win98 - you won't have 20-year-old college drop-outs answering the phone. Enterprise Unix support is a big part of the revenue for IBM, Compaq, Sun, HP, Oracle, etc. The people who will be supporting you are professionals, and if they know what's good for them (and their company) they won't play "the blame game" - it just doesn't make business sense at this level. If they try to give you the run around on some critical problem, you will eventually find out (or else your machine will remain down), at which point you'll probably walk to another vendor, taking your fat support contract with you.
Finally! A halfway decent "ask slashdot" question.
--
http://gammatron.weblogger.com
"...an excellent OS (AIX)."
*spit out milk* HAHAHAHAHAHA!
*wipe tears from eyes* AAAAaaanyway, you'll still have a blame game problem. When you call up with an OS problem (and you will) the tech support guy will say "that sounds like a DB problem, here's the number". It's not going to matter that it's nominally the same vendor--from IBM's point of view it's a different business unit.
--
Give us our karma back! Punish Karma Whores through meta-mod!
Linux MAPI Server!
http://www.openone.com/software/MailOne/
(Exchange Migration HOWTO coming soon)
You have no problem!
If you think AIX is an excellent OS, you're so bug-tolerant you're never going to need technical support.
;-)
It would be simple, if you (or your staff), knew ALL the ins and outs of ALL these parts. In the real world, this is not likely to happen. But, if you can isolate a problem down to being NOT in two out of those three, then it looks pretty likely that it would have to lie in what's left. Hence "know what you don't know." That is, know what areas you are weak, and what areas you are strong. Use that to your advantage in trying to sort things out.
Often, in my experience, have I found myself going down the debugging path in frustration until I step back and realize the problem is not where I thought it had to be. That meant those areas which were not even a consideration, before, now come back for another look. I had again stumbled upon a case of:
But, I suspect the real desire of this post is not improved debugging skills, but to avoid the need for debugging inter-vendor problems in the first place.
Good luck! It's the nature of the beast that bugs tend to occur in the interfaces.
But, there are some steps that can be taken to lessen the challenge... find someone else who has been down this path before and can point out the landmarks and land mines along the way. I commend you for doing so here in /., but there is more that can be done:
When you get that working and stable, take what you've learned and then add capabilities. Build not your house upon the sand.
Consider, for example, your database vendor. Contact IBM and ask for references of customers who have used their DB2 database in a similar situation. Contact those references and find out what THEY learned from their experience. Do the same with Oracle and MicroSoft. Build up a table of strengths and weaknesses.
Yes, it is a lot of work, up front, but it has been well said:
The blame game is only effective on inexperienced users. All 3 companies know pretty well that your average Oracle/BEA/AIX user is no fool. I would imagine that you have at least enough experience with server administration to know which of only 3 peices of major software to blame when something goes wrong. Even if a company denies responsibility, a few, um, harsh words to a tech (I'd like to speak to your supervisor. Don't make me give you bad press, etc.) will have them quickly sending an expert to your location.
I should also mention that since you'll be running AIX, you'll also be using IBM hardware, which makes them a fallback point. They may say that they don't support your particular configuration, but once again, they'll fold under pressure. I've done it before with IBM (OK, so it was a Thinkpad running Linux, not a massive AIX server, but still).
Anonymous Luddite: "What do you think of the dehumanizing effects of the Internet?"
Andy Grove: "Not Much."
I work as "tech support" for my department at Texas Tech University. (Nothing quite as complicated as the origional "ask slashdot" submission but I enjoy it.) One morning I'm chatting with my coworkers and one of them mentions that Real player isn't crashing alot, I tell him he can just reinstall it and it would probably work. He then asks when I can do it for him. I think "I'm to important to do some small job like that" and tell him he can just do it himself. He then counters that with his job as a "interviewer" he could just hand someone a list of questions and tell them to hit record on the tape player and just leave the room... I replaced it later that day.
Last night at exactly 12:03AM I got a call from my aunt because she wanted to add her mother on Yahoo Messenger, and wanted me to walk her through it.
It seems like I'm constantly troubleshooting computers (who isn't?). But the worst problem I ever came up with was when I bought an IBM Aptiva, added a slave drive, ran Aptiva's "update" program to be current and all. After tearing my hair out trying to get it to boot, and then doing the investigative work for 4 hours, it turned out to be an incompatibility with my new slave drive, which was the same brand and model (aside from size) as the first. Blimey.
It's ignorance itself to think you know all the answers. -Miles Comer
Of course, in one sense, there if "no problem" but is he wants to use three different products then there will be inevitably. Paying IBM to support all of them is one option. .
As for the original question, there is no way to prevent one vendor from blaming another's product. The easiest way to get the problem resolved is to submit a detailed, accurate description of the problem, preferably with a test case, that demonstrates that the problem lies with one particular vendor.
I've done a lot of support and I can't tell you how many times people call and say "x is broken" and they don't describe the problem or provide any diagnostic data to support it. The first thing a support person is going to do is to throw it back at you and say "give me more detail." It's no wonder why people complain so much about support when they don't even help themselves in the first instance. In my experience, ore than 80% of the questions are answered in the documentation (for the stuff I support). Of course, no one reads it, they want the answer spoon fed to them. Pathetic.
If you're using complex software you damn well better read the documentation (yes, a lot of it is poorly written -- that's another thread).
Web app servers, networks, different databases -- all these make the problem that much more complex.
Another poster said "tell them to certify their products with the other software you want to use." This is a nice idea but if there's no business case for it it won't happen. If IBM is pushing WebSphere there's no real reason for them to bother certifying that Weblogic works with DB2. The answer is: read the documentation, keep up to date on the fixes and patches, and, when there is a problem (and there will be) send everything: the steps you took, the documentation you read, what you thought would happen, what did happen and provide data to back it up. More is better than less.
As usual i've found another link that deals with this matter
------------------------------------I am an illiterate dork!--------
The Link is here.
------------------------------------I am an illiterate dork!--------
Unfortunately, there is no way of avoiding finger-pointing. As others have pointed out, if you go and get a single big vendor, they will keep bouncing you between project groups, who will keep remarking on what a fascinating problem you have or what a strange/nonstandard setup you have.
The best ways to get a problem fixed in a hurry is to keep escalating it. You don't want to be a 'problem customer', but it sounds like you are pumping plenty of moolah into this, so they won't be able to just brush you off.
Ultimately, picking a single vendor will better avoid the fingerpointing between unrelated service techs because you can always find someone who is superior to both of them. But if you pick an inferior system, you'll have to make more service calls.
If it is onsite service, throw a 'tea party'. Get all the techs from each software package which has been blamed, and say that none of them can leave until the problem is fixed. I've had three weeks of back and forth end in two hours that way-- usually the tech isn't going through his whole routine and so is missing something. Once he is in that environment, he will have to do everything, even the stuff he thinks he doesn't have to do.
I guess my answer to your question is to thoroughly explore interoperability before you buy, but then get the best stuff with the best service-- without trying to find the one company for everything. Make sure interoperability is explored before you buy, so the sales reps won't weasel out of it later.
I am currently in the middle of a series of irefights. WebSphere with Oracle and Sybase on some really big Solaris boxes (4x8CPU boxes etc...).
My problem is not finger pointing by IBM support, my problem is finding anybody at IBM who has worked with an environment with more than 2 dozen EJB classes. We have 200+. We finally found a guy yesterday with a clue. Now, if I can only get him on site for a week or two.
No finger pointing. Lots of cluelessness for the size and load that we expect to have.
ciao
The culture of the said organisation (or team within) is also critical. Avoid a backward looking, blamecentric cultures if possible.
Rob.
My little experience with tech support is that they blame something anyway. Things like "it should work now" and "it works from here", and I being unable to convince them that it does *not* work from *here*.
This experience is with service providers (for websites, etc.). And what I really want to do then, is get over there myself and solve the problem with my very own hands: because I experience the problem myself, I won't stop after a minute trying to solve it or declare it as done, forcing the costumer to ring for the Nth time saying "no, it still doesn't work". I will solve the problem instead of making the costumer so tired that he gives up - but I am not allowed to do that.
The problem I have with service providers, is the same as what you have with your soft-/ hardware providers. My advice would be to minimize your dependency on the service of your provider, because they don't really *care* about your problems.
So, open source springs to mind, no matter how boring it is to put the topic up here. You can repair your own problems, have a third party look into it, etc. Vendor independent, bladidibla, go ask ESR anyway.
For those parts that you'll really have to get as closed source (in the cases when the propietary product simply outperforms the alternatives), I guess all you can do is bothering tech support with your problems and keep bothering them, as others have already advised.
Some "IANAL"ish excuses are in place, though: I am not a specialist, but these are my thoughts on the topic.
It's... It's...
"We can confirm that Debian does *not* ship the version with the trojan horse. Our version predates it." [CA-2002-28]
Okay, so what's the point? There are other companies, who because of their market share, or just bad support, will find it easier to blame the other guy, than find the real problem. I've had to point out specifically what was wrong on another vendor's implementation, before closing a case. It's really a function of how good a company's support team is...they represent the whole company. Which is what I keep trying to tell my guys...
So...get a taste of what kind of support you will be receiving from the company you choose...call them with a problem, and evaluate how they react. If it's "too late" and you're already in bed with a certain vendor, learn how to yell. In other words, when you are talking to a support engineer, and not receiving good support, ask to speak to their manager. If the manager doesn't respond, tell your salesperson, and get loud. Trust me, if you shake the tree hard enough, you will get your problems resolved. (Just make sure your problems are legit...don't make these guys send someone onsite to fix a problem that isn't real, etc. -- remember, support are people too...)
Good luck with your project...
It's the "One throat to choke" theory.
Besides, have you checked out WebSphere lately?
WebSphere Studio allows you to develop on the Windows platform, and drop your application into AIX.
M$: "We're #2!"
"The highest of four new performance numbers on the TPC-C benchmark show SQL Server 2000 Enterprise Edition achieving a rate of 262,243 transactions per minute1 on a federated cluster of 12 ProLiant 8500 servers. That beats the record that Microsoft and Compaq set last February by 15 percent and, like that earlier measure, also beats the best performance results from Oracle and Sun, delivering nearly twice the performance of the largest Sun system. At this transaction rate, SQL Server 2000 could handle all of the e-commerce transactions that Amazon.com and eBay.com processed in 1999 -- and it could do it in just two days. "
At work I use Linux, Tru64 and AIX. Of the three, AIX is, by FAR, the least sane. You can't boot from anything but harddrive or TAPE, the NIS stuff is hosed and many of the supposedly POSIX functions are screwed up.
--
Give us our karma back! Punish Karma Whores through meta-mod!
Linux MAPI Server!
http://www.openone.com/software/MailOne/
(Exchange Migration HOWTO coming soon)
You reminded me of something I was doing this past December.. I was giving intermediate technical support to someone (meaning I was doing all the work), upgrading their system from PC-DOS 3.2 to Windows NT4 (ugh) because they were concerned about Y2K issues. They were mainly concerned because their vendor told them to be concerned (!).
;-)
Anyhow, they already bought the new hardware and such (brand new) and wanted to use the old internal tape drive on the new machine. Now, remember that this is a 10 year old tape drive to get working on a brand new machine... no drivers... no support... no help... I got it working (whoho!) by hacking simelar drivers to reconize the drive, even though they weren't supposed to (a little late night hex editing if you catch my drift).
Anyhow, the only thing that DIDN'T work was their management system (a piece of old crappy cobol code... not that theres anything wrong with cobol, its just this was ms-cobol and was all compiled sans source code). Of course, all of his records for the past 10 years were in this and you think I could get ANY info on the specs? Haw.
So I call their technical support in Vancover (I'm out here in Ontario) and guess what...
TECH: Whats the problem?
ME: Its giving me error code #03-02-somefile.ext-29-3294.2093 (yeah.. nice error code there).
TECH: Oh? That error never happens.
ME: Well it's happening... what does it mean?
TECH: It means that somefile.ext doesn't exist. But that file isn't needed by the system anyway.
ME: So?
TECH: Uhh..
ME: How can I fix it.
TECH: Click on the dial manager icon and I'll log in to fix it.
Okay, he's being nice about it. Calling in long distance right across the country to look at it himself. They spend nearly 12 hours straight working on it.
Next day...
ME: So did you find the problem?
TECH: Well, we downloaded the whole system and got it working here.
ME: Great! So can you upload it to this system and have it working?
TECH: We tried that, but it doesn't work on the system.. must be a hardware problem.
ME: But they bought the EXACT system that you asked them to and had it checked out by a fully qualified technicain several times (yeah, so I'm a measly PFY with lots of technology certifications).
TECH: Oh.. Maybe it's Windows.
ME: You think?
We went through fixing several files and what not.. no success.. they went back to using the old computer. Eventually they sent the HD over, the tech fixed it and sent it back. Happy ending.
Know that in this persons other office (he has two nearly identical offices in 2 seperate locations) I had done a flawless upgrade of his other system (everything is identical except for the records in the system). Nothing wrong there.
Oh well. c'est le vie I suppose.
Sometimes techsupport means you talk to a programmer or someone who has indepth knowleadge of the program and it's quirks. More often than not you get stuck with some secretary with a rolodex of possible issues and possible ways of fixing them. If the solution isn't there it depends on the company policy of handling exceptional errors... and we all know how Microsoft deals with exceptional errors (BSOD).
;P
Price, Quality, Time. Pick none. What, you thought you had a choice?
You are obviously one of those nitwitts that rates an operating system on a boolean scale...
It's either good or bad.
It's either Linux or not Linux.
Perhaps he should have said, "...AIX is an excellent OS, though obviously not as excellent as Linux..."
Why is there no spoon?
The List of Grievances with Slashdot.
I've been working on AIX boxes for 3 years and _yes_, they have an _excellent_ support, provided that you know whom to call and have the best support contracts. I had a really painful job of trying to get a problem solved until i contacted an ex-ibm exec working with us. He knew whom to call, past the technical support first-level front line (no hope to get anything solved by them, they can just escalate problems to higher levels). Since then, i've been just jumping the front line and _yes_ their support is really good :-)
Vacuum cleaners suck. Kings rule.
Most of the vendors we have worked with are really good about integration, but one in particular seemed to really stand out. Have you checked out Allaire's JRun 3.0? We tried them out against BEA and really felt like they kicked WebLogic's butt. Here's Allaire's website.
how much have you actually used it? Or did you sit down and look at smit and go "woah, this must be a toy!" or was the lvm too complicated for you? I know being able to resize filesystems on the fly may be a little too much for you, but I bet nobody ever told you you can migrate an active swap space to another disk. I've (under AIX) had reported hardware failures (I still like that it tells you when a disk is about to go bad) migrated all the data off that disk (including swap) replaced the disk, and suffered no downtime because of it. And those weren't even hot swap drives.
so you people can talk it down all you like. It's my commercial OS of choice (I'd rather run linux) unless we're talking about orable, then it should be slowaris as discussed earlier in this topic.
"We are not tolerant people. We prefer drastically effective solutions"
After 10 years of dealing with vendors (SUN, IBM, SAS, NetAPP, ECCS, HP) I can only be envious of someone who expects tech support from one. I can only recall a single instance when a vendor fixed something in response to my trouble report. Even in single vendor setups, the DB support group will have no hesitation to blame the hardware group, or the OS group for problems and close the problem report as 'solved'. If there is a vendor that doesn't do that, someone please mention them here. And I don't know any vendor that would not be perfectly comfortable closing a problem report with 'That is a known bug documented in TR123456. No patch or workaround is available'. Only a few favored customers actually get tech support, the rest might as well be buying at a flee market. The best way to protect yourself is to make sure that your configuration and purpose are very similar to a favored customer, or a target market.
I have a RS/6000 S80 running 600 users on a text mode app and the box and the OS never burps.
Specific Config:
8 Processors
4GB RAM
90 GB SSA (Mirrored down to 45 GB)
and most importantly...
2 black cabinets the size of fridges.
This box makes you remember the good ole days in terms of size!
No kidding. The UDB is superior to Oracle in just about every way. I think IBM has to break through this Oracle "paradigm" that is prevalent in some business sectors. It is a great product.
I work for a company which is using RS/6000 and AIX servers exclusively. AIX servers have _never_ crashed on us, even though they run under serious load all the time.
:)
AIX has an unmatched volume management facilities, it integrates well with other vendor Unixes and it is sufficiently BSDish for me to feel at home while working on it. Very close to the perfect OS, indeed
Scrap the expensive and vendor lock stuff. Use FreeBSD (or Linux) use Perl, use DBI and any Database you want. Forget VB, which you will be left stranded and locked into an obsolete path when MS starts pushing C#. Open Source solutions will have significantly more longevity than most closed solutions and whatever closed propriety closed solution you choose you will find yourself in a continous upgrade for $$$ cycle. Oh yes, and Perl is Rapid Development compared to even VB.
Benchmarks can be altered in different ways. It is nice that microsoft made their product a little faster but Orical and Sun put emphysis on quality and not just raw speed. My expernece with Microsoft is that inorder to keep it running properly it will need constant administration. While Sun and Orical although may be slower acording to the benchmarks in realworld Orical and Solaris will be more useful in the long run because you will not haveing to make sure your system is running.
If something is so important that you feel the need to post it on the internet... It probably isn't that important.
IF it happens, ask the provider for any additional information that they can give you that will help document their companies position and get their name and a "ticket number" to reference when you call back. DO NOT try to pretend that you haven't called on the issue before, if you get "busted" you will be far less likely to get assitance if you pull that one.
If at all possible, try to set up some sort of conference call between the providers. Getting everyone involved can be a really positive thing.
Consider an alternitive resource for support, there are pay-per-call companies out there that do a great job of troubleshooting and resolving issues.
Don't forget to access the different companies websites for support information before calling! If you can't find the answer, then call but stay armed with the info from the different documents, that way you can quote from them and keep the person on the other end on their toes.
Again, I want to stress that a lazy employee is probably the worst enemy that both the company and the customer have. Just because you get a bad apple, don't assume the entire batch is bad! Of all the calls I've taken, I think those are the ones that bother me the most - because I really do try to help and try to keep my skills current. I know there are others who don't do as well and I am ashamed to work with them but these days sometimes companies have to settle for the help they can hire, not the help they want. I assure you these folks will be the first to go when the labor market loosens up a bit.
You or someone you hire will have to know what's what to keep on top of the ball. No if's, and's or but's. That's why top system integrators get the big bucks. Their motto: "Know the answer before the customer asks the question."
- real hackers don't have sigs -
I have just gotten out of tech support, so let me shed a little light from that perspective.
What you have to do to avoid finger pointing is ISOLATE the problem BEFORE you call.
For example, you have a problem with the tape drive on your RS\6000, using some non-IBM tape backup software. BEFORE you pick up the phone, try tar. Now you know who to call. Since it is IBM's tape, in IBM's system, with IBM's tar it is IBM's problem if it doesn't work. OTOH, if it works, when you call your backup (or DB) vendor and tell them their software is goofy. If (when) they try to point at IBM you tell them, "Hmm, works with tar."
See?
Again, from a tech support guys point of view, this is YOUR JOB. Using a single vendor makes your job easier, because you don't have to figure out who to call. But it is not the tech support guys fault if you just call the vendor who's product is exhibiting the SYMPTOM, if it is not the component that actually has the PROBLEM. You will be the victim of finger pointing as long as you don't believe it is your responsibility to isolate the problem before you pick up the phone.
Please don't interpret that last paragraph as "finger pointing is the customers fault." It is not. The vendor should say "It is possible, or even likely that the problem is in fooware. Here is how we can make sure our product, barsoft, is working correctly." Bad support techs don't do this. (Actually, this is a management problem, but that's another thread.)
The point is sometimes you will get bad tech support. Doing your homework is how you avoid finger pointing.
-Peter
By going to a good VAR.
If you can find a Value Added Reseller that supports the combination of products you want to use, of course.
But, be very picky about choosing your VAR, as many are little more than fly-by-night operations.
Of course, most VARs will just try to convince you that what you REALLY need is what they already offer, 'trust us, we know this stuff!'. Don't beleive it unless they can show you.
A truly good VAR will listen to your needs, and try to support your choice of products with a comprehensive support contract. That is, of course, what 'Value Added' means.
--
The real Webmaven is user ID 27463. I don't rate an imposter, because my ID is such a lame-ass high number.
Which version are you using? What are the problems?
Have you considered open source Enhydra? Then you can have multiple sources of support.
What about Linux, PostgreSQL, and Enhydra combo?
Aide: Grant drinks too much to command an army. Lincoln: Find out what he drinks and give it to my other generals!
Bingo -- 7x24 platinum plated super-duper on-site tech support from 37 vendors is no substitute for proper diagnostics. You designed the system with help from their SEs, now you're supporting the system with help from their techs. It's up to you to manage and direct their efforts.
If you don't want any responsibility in this, then you can outsource the entire effort to a managed service company. But don't be surprised when the CFO starts asking what it is that you do for your paycheck.
"Nothing was broken, and it's been fixed." -- Jon Carroll
All you need to do is thoroughly narrow down the problem until you find it's source, and DOCUMENT what you did so you can explain to their tech people what steps you took. That way, they can either tell you to test a couple other things to make sure, or they will go, "Oh, you did that? and it did what? Hmmm... Okay, let me get back to you."
Ah, progress! You now have gotten them to realize that it may just be their problem and they can't push it off that easily...
It's all very simple, really.
----
Lyell E. Haynes
+1 Insightful, -1 Troll. What can I say, I'm an Insightful Troll.
Pretty lame posting this as anonymous coward. I've seen technical and functional studies that illustrate that AIX has the richest function set of any UNIX/Linux/BSD/NT.
Aide: Grant drinks too much to command an army. Lincoln: Find out what he drinks and give it to my other generals!
MY NAME IS BONGO NOT BINGO. And as a recipient of your various works of gay porn, I'm VERY DISPLEASED. No double fisting scenes? WHAT IS THIS. GIVE ME MY MONEY BACK. And STOP CALLING ME BINGO.
-Bongo
Why do you fear "problems"? What makes you think that the vendors will solve them for you? (What ever makes anyone think that?)
Stop worrying about blame, think, and solve all the "problems" as they come. Pick the best technologies with the best track records to keep the problems to a minimum. Sun, Oracle, Bea Systems or I-Planet.
Be a computer engineer, not a blame engineer. Succeed or fail and take your due of the credit and the blame.
Deal with like people and do not fear anymore.
Fast forward a month, when it comes time to pay the bill, i get not one, but two. The first dealership just dripped with incompetance, and forgot to cancel the initial account. Ok, so i call Roger's tech support to get this corrected... only to find out that want me, personally, to go back into the incompetent dealership to make them fix the problem, despite the fact i had no contract with Rogers on that number, and that it was an internal screwup.
The point of the story... yes, while they kept putting the onus on me to fix the problem their incompetence created, I kept insisting that it was their fault, I had no contract for that number, and therefore was under no obligation to fix it. I kept increasing the asshole factor (asking to talk to the supervisor, etc.), until eventually they caved in, and the supervisor personally called the incompetent dealer that messed up, getting the problem fixed.
The lesson to be learned is that... well, put enough pressure on them when it is obviously their responcibility, and wonderful things will happen. =^)
-legolas
i've looked at love from both sides now. from win and lose, and still somehow...
(Commercial) support like you say is just one of the arguments upon which the enterprise design should be based. I think there are some other points that are more important.
1) Human resources.
How many administrators and developers can you bring together with good knowledge of those IBM components (AIX, Websphere, DB2)? Here Linux or FreeBSD clearly beat AIX. For webapplication developers with Java and RDMS skills the scale (for now) is probably a bit more even, due to healthy competition between the different webapplication frameworks.
2) Product Continuity.
The basic architecture you lay down now will probably be around for a few years, maybe even more, so having your products evolve in sync with new standards is very important. OSS projects, by their very nature, nearly always tend to more aware of interoperabillity than their closed source equivalents.
3) Security, Robustness, Scalability, Performance.
I think the the OSS models, in general create products that score quite good on each of these points, especially when they have been activly developed on during more than a few years.
4) Product functionality.
The XML and Java features of the Java Apache Project or the entreprise ready Enhydra server (with commercial support from Lutris) are already more advanced than those of the IBM Websphere modules. Combine that with an excellent RDMS (with full JDBC driver support) like PostgreSQL and I think you got an excellent webapplication platform that is able to quickly evolve with future technology extensions.
- just my Euro 0.02c
Those are clusters, high numbers for tpc-c clusters is an exercise in how many PCs a vendor can put in one room. It does show that both IBM and Compaq can build rooms with good cooling. If you, or anyone alse, thinks the cluster tpc-c numbers has more relevance--please supply me with a reference of a real application using a setup like those, that does what the tpc-c benchmark is supposed to measure.
In a sentance, nothing beats having skilled employees that know there stuff!
Ands it really does not matter what OS/ DB/ EJB's you use, it matters more how well the people that you are getting to do the job, know what they are doing.
send flames > /dev/null
Only 'flamers' flame!
And, of course, the obligatory Bush/Dick campaign stickers. I guess this year the choice is between sex and violence: Bush/Dick, or Gore.
___
__
Do ya feel happy-go-lucky, punk?
Not that this is purely an IBM thing. I've had support people at several major corporations try to give me the run around, pass the buck or blow me off. Having been on their side of the phone, I can generally spot this and I don't put up with it. If I have to call support, I'm having a problem their frontline has never seen before and I'm not about to put up with some $8 an hour phone monkey jerking me around. I tell them that too, and ask for their manager. I tried to provide the level of support I'd want on the front lines when I was working the OS/2 support desk at IBM Boca and my manager told me that if I didn't get my numbers up, they'd fire me. Most of the frontline drones are idiots, because the smart ones either get promoted out rapidly, quit in disgust or get fired because some fucking bean counter would prefer quality to quantity. I ended up getting promoted out of phone support at Boca, in record time.
I'm trying to teach myself to set people on fire with my mind... Is it hot in here?
You must be very angry about being abandoned as a child. Don't worry, time heals all wounds.
I manage a television broadcast facility. The majority of systems are automated and there is a lot of software/database interaction. Pointing the finger in problem situations is what I get to do.
My tips:
1) Pre-arrange response times and service levels with each vendor. Know exactly how long before they can have an expert on the phone with you. Don't confuse this with general tech support response time. The first person that picks up the phone usually can't solve your issue. Know the names and skills of the people in support in advance. Make the vendor supply you with names. titles, phone numbers and written escalation plan for their support group.
2) Do research before calling. Do some basic trouble shooting before picking up the phone. Have software/hardware version levels ready to go. While your vendor *should* have this info, they never do.
3) If you have two systems and you can't decide which is at fault, ask the vendor how to eliminate the other guy as the problem. For example if you can't decide if vendor A or B is a fault, ask vendor A how to prove it's not vendor B. This turns the problem around. Usually they get focused on proving it's not their own gear.
4) Put the involved vendors on the phone together to help them hash it out. I have gone so far as to get engineers from two companies to stand in front of the problem system and we all looked at the RS-422 analyzer together to agee who was at fault.
5) Escalate a problem up higher. If you aren't getting the support you want, escalate to higher levels of both technical support *and* salees/marketing. Never forget how much power(wrath) the sales guys can bring on the support guys. In most companies the management chains of sales & support join up rather high. So if you complain loudly to sales, usually a person fairly high up hears and issues a "fix it NOW, I don't want to hear about this anymore" order.
Good luck.
nuclear iraq bioweapon encryption cocaine korea terrorist
First, going with BEA is the right choice on the EJB front. I don't mean to be all conceited, but WebSphere really sucks. In competitive situations, we found that WebSphere couldn't point to a single marquee customer which was using their EJB technology in a production site. Their Servlets and JSPs were okay, and their JMS definitely was better than WebLogic's, but their EJB infrastructure was pretty much unusable. An ironic thing to note here is that one of the largest systems integrators working with WebLogic Server is IBM Services....they don't even pitch their own product for their own customers. That should be a sign of the relative strengths of WebSphere vs. WebLogic on this front.
BEA's technical support people are extremely overworked. It's just a fact of life there after the BEA acquisition of WebLogic that BEA hasn't spent that much on the technical support infrastructure. However, there are two mitigating factors there:
Specifically on your choice of Oracle for the database, I'd recommend that you think again. The Oracle model of concurrency control makes doing serializable transactions damn near impossible for real-world EJB-enabled applications, and you'll find Oracle rolling back your TX_SERIALIZABLE transactions all over the place. Either move to a different DBMS (DB/2 rocks, actually....), mark your transactions TX_READ_COMMITTED, or be prepared for constant rollbacks of far-along transactions at COMMIT time. Unfortunately, there isn't much of an option otherwise, because Oracle does crazy things internally to try to maximize concurrency at the expense of transactional semantics. Think carefully about this one!
In short, WebLogic rocks, DB/2 rocks, AIX rocks, and if you know how to work the system, WebLogic support is the best of the three.
Kirk
I'm kinda wondering about BEA's long term business model given they are the high volume leader, but not revenue leader, e.g. by my estimates, WebSphere is more than 2x BEA, the company, in revenue.
But much worse, will Enhydra, etc... do to them what Linux has done to SCO? Or Apache to IIS or Netscape?
Aide: Grant drinks too much to command an army. Lincoln: Find out what he drinks and give it to my other generals!
All you have to do is maintain the proper level of support contract with each of the companies involved. For more information on SunVIP, check out http://www.sun.com/ser vice/support/servicealliance/sunvip.html.
Disclaimer: I work for Sun.
Admittedly I AM using 4.2.something. I also forgot to mention that the hardware is really loud too--can't blame AIX for that, but I CAN blame IBM.
--
Give us our karma back! Punish Karma Whores through meta-mod!
Linux MAPI Server!
http://www.openone.com/software/MailOne/
(Exchange Migration HOWTO coming soon)
Just thought I'd point out that AIX 4.2 is ALSO capable of booting from cd tape disk and network
Vermifax
Vermifax
Logout
Just responding with as much info as you did for it being an "abortion"
Vermifax
Vermifax
Logout
I can't help but jump in on this...
Tech's notes on avoiding the run around with commercial vendors:
* Document everything. Every configuration from the Prom to the OS to
the details of your custom application must be in hardcopy.
* Don't call anyone until you have every relevant piece of information
you can imagine (and there will be some that you can't imagine).
* Keep daily tabs on the products you use- Subscribe to the newsgroups,
announce lists, etc., check one of the Usenet searches like deja weekly,
join a users group.
* Train at least two people in your organization on each product
and make them responsible for it. Get backing for a policy that no
closed-source, proprietary, or commercial product can be used unless
there is in-house knowledge.
* Call the sales reps and pre-sales engineers monthly and ask them about
patches, notices, updates, etc.
* Never buy a product that only runs on one platform or with one
back-end. Best-of-breed also means best chance of survival, so don't get
locked in.
* Fight against using proprietary or non-standard anything when
possible. Stay as flexible as possible but don't think for a second that
open-source will save you from a knowledge deficit.
* Always have more than one product of a given type under testing.
* Negotiate with multiple vendors but try not to let on with which ones
you are in contact.
* Get a support contract from the vendor and from a third party. Use the
third-party to hassle with the vendor for you.
* When selecting a product try to get a written statement that the
product works as described and what the vendor's responsibilities are.
Run everything past your legal people.
This is exactly how I ended up liking open source. I've always worked for small companies, which means that the vendors really don't care about me. I got the run-around every time, and ended up having to find a solution myself. It's hard to fix software that isn't opensource, so here I am.
Been there, done that.
Eventually, you get around to reading the 3-ring binder that your support contract came in and you find out that IBM's various support groups aren't allowed to even be in the same room as each other!
Jesus on a stick! That has got to be one of the most obnoxious post that I have since on Slashdot in a long time! Does you ego know no bounds, you Republican?
DREAM LOUD!
Choose Linux and you could go with a support company like us or LinuXcare. We'll take care of the whole kit and caboodle.
AIX is a good os, though I have never personally liked it. As for stability, it's pretty solid. My main complaint (among others) is that I have to add a ton of stuff to make it useful (and I'm not talking about GUI stuff) like vim, bash etc. I also very much dislike the way command history is the same for all shell windows. I guess I'm just spoiled on Linux...
Also, for web stuff, there's no getting around 100 1u Linux servers behind an f5 load balancer. Save your big iron for your database (until someone figures out how to decently cluster a database).
-Chuck
--
Quantum Linux Laboratories - Accelerating Business with Linux
* Education
* Integration
* Support
*Condense fact from the vapor of nuance*
If you understand the software and systems, you will know who to blame, and you will have enough proff to lay your accusation.
Time does not wait.
Yep...!
Aide: Grant drinks too much to command an army. Lincoln: Find out what he drinks and give it to my other generals!
As with any project, you need to define the borders(/interface?) between each part of the system. You can never avoid it 100% but you can limit it by doing this. It will also help you when you need to debug errors.
Get any book about project management, it's a classic scenario of how things can go wrong.
---
Well, it depends on your budget here, but since I used to work as a service delivery manager for IBM, I know a bit about how their support agreements work.
:)
-
The client I was SDM for had IBM as the first point of contact for *all* of their software stuff. I had to negotiate "back to back" service level agreements and maintenance contracts from the other vendors.
So basically, you could get the 2 products you wanted - DB2 and AIX - and skip on the websphere, and go *through* IBM for whatever product you wanted - and ask them to provide support.
It may be that their support will really only be providing the same easy one-number contact for you for that product, and then IBM calling the vendor on your behalf. With service level agreements in place between yourself and IBM, and IBM and the vendor, it should mean that the back to back agreement is essentially transparent to you.
At the end of the day, my experience with IBM is basically that if you are willing to pay for it, they can provide the support.
Chrisom.
-------------------------------------------------
Michelle
----
Be true, regret not, and let your star shine forth!
What is it about a fag that makes him want to tell everyone all about his private life? It is none of our business who or what you have sex with.
You don't see heterosexual or celibate people going around screaming about what they do in private do you? The other thing is race. You gays keep attaching color to sexual preferences as if they are the same thing. They are not. The fact is even race needs to be kept quite unless it is relevant. I.e. I'm black so sunscreen isn't something I need. Someone wants to have a problem with your color. Let him find out about it in your presence and have his hisy fit to your face.
--= Isn't it surprising how badly I spell ?
We work vendors for a large variety of products, from databases to CORBA OBR's, etc.
;)
The key to resolving these conflicts, as far as we have determined, is knowing EXACTLY what the problem is, what is causing it, and then contacting the appropriate vendor.
Every vendor product has a well defined (at least, in theory) interface and functionality for their product. For example, an Oracle database will have an API for the embedded SQL library, and an ORB vendor will state their CORBA compliance.
If something is not working correctly between components, it is either user error, or a flaw in the component. (or unsupported functionality, but you should have verified this before purchase right?
At this point, you know exactly where the problem lies, and which vendor owns the problem.
The problem with going with a single vendor is are you really getting a single vendor. Outsouring is a major problem in the industry. The quality level of the tech support is pretty much related to the turn-around rate at the centre you get connected to. So even if you were to go with IBM, that doesn't mean you won't get sent over to a support centre run by Stream or some other outsourcer of ill repute.
And even when you do get the actual vendor will they even care. Will they speak f*ck'n english? A former tech support person for a major database company once told me that it was standard practice to blame it on the OS first. If the customer was actually able to prove the problem was with the DB then they'd submit a bug. But the point was it was up to the customer to do all the leg work.
I think we as techs are to blame though. It's our way of doing things in IT. You've seen the SNL skit with the bastard tech support people. Sure they couldn't get the terms right if their life depended on it, but the point is we have huge ego's and little personal responcibility. Even played the blame game inside the company when someone left?
BOSS: "Why isn't this project done?!?!"
TECH: "Ahh..yeah..Habib was supposed to do that before he left the company."
BOSS: "Damn that Habib!"
At any rate, it's been said before, quality people. Also, if you have the money, go with a vendor that will offer "internal" classes for the product. HP for example has special "Internal Use" classes they will let customers go to. It might cost a little more. Hell, you may have to send your people to the UK for them. But it's well worth it to know what's going on under the hood.
(from my experience)
If you are a small company in a big pond like IBM...forget about consistent timely responsiveness that you can bank on. You would soon realize that dealing with different parts of IBM is like dealing with different vendors...sometimes even worse.
If it is mission critical you would be much better off in building an in-house ace support team and use the vendors support as a resource...because your mission critical is NOT their mission critical. Having a strong team would also give you the flexibility of choosing the best of breed products rather than getting tied to particular vendors. It's obvious to realize that IBM is happiest when you buy IBM equipment (even if they claim otherwise).
Above all use common sense in deciding strategy and taking decisions rather than getting swayed by the marketing hype and panacea of off loading problems from your shoulders.
Umm, I wrote the previous post. How did it get assigned to that poor (or maybe very lucky? ;-) fellow?!
Re: high numbers for tpc-c clusters is an exercise in how many PCs a vendor can put in one room.
-- Gee explain number 11, Sun?s Starfire Enterprise 10000, not a cluster. A few weeks ago it was number 6. Obviously your statement is wrong.
You seem to be unable to read, or maybe to understand what you read. I did not say, and never have said, that you have to use a cluster to get a high tpc-c score. Scores six to nine are none cluster system (IBM AS/400, Fujitsu something with SPARC CPUs, IBM RS/6000, BULL with PPC CPUs)
Re: It does show that both IBM and Compaq can build rooms with good cooling. -- You are showing your ignorance of clustering.
Or your ignorance of humor?
Re: relevance -- Check out tpc-c faq for an explanation of tcp-c and for a real-life example
Couldn't find how many NT boxes they had in their database back-end (11 servers in total, no mention that I could find on how many were used for what), but the availibility was strangely low for a cluster (99.97 percent, or 2.6 hours per year). No I didn't read it all--too much marketing drivel. Could you provide a technical paper on that setup so I could evaluate it?
Has it ever occurred to you that God might be a committee?
Has it ever occurred to you that God might be a committee?
--- Jubal Harshaw
the usual appraisal is more along the lines of "AIX? Uurrggghhh..." ;)
/.ers pay similar compliments to AIX. It really is a solid OS designed to never crash. Thats what mainframes are designed for.
I'd never auctually used AIX, but from what I heard, most complaints are directed towards its design and its divergance from Unix standards that we all have come to know and love. Do not quote me on this, but I believe that AIX does not use the traditional text configuration files.
I have heard
Does that mean that the average admin coming from a BSD/Solaris/Linux/NT envirorment would enjoy admining an RS/6000 giving the proper training? Depends on their adjustability and how strong there feelings are about how a Un*x should be. Personally if I had a choice between a Sun enterprise server and an RS/6000 to play around with at home (and the space to store it as well as a 220 volt outlet), I would personally go with the Sun Server and play around with NetBSD. However, for a five 9's envirorment I'd probally go with RS/6000's.
--- Justin Dearing http://www.justaprogrammer.net/ We're just programmers.
you could also find a var that's willing to put together the pieces you want, mix and match as you choose. Ask IBM to supply you with a list of var's, ask your fav ejb company to also supply you with a vendor list. more often than not, an integrator will act as you single point of contact, cause their the ones taking your money, it'll be their responsibility to act as the first and second tier support levels.
three can keep a secret, if two are dead - benjamin franklin
Main issues are:
- Your other vendor needs to be on Sun's list (includes IBM, Oracle, Sybase, 3Com, Cisco)
- You need a fairly high-level support contract with Sun (& probably the other vendor)
More info at Sun's support page.Disclaimer: We haven't used the service - I just heard the spiel at a Sun presentation & thought it was a rare example of common-sense.... it may not actually work :-)
-- Only speaking for me. Honest.
Well I work at IBM and here's how it goes: the customer just screams until they get a marketing rep to call about 4 layers of managment. Then no matter where the problem lies, we get to go fix it. So try that, it seems to work quiet well for everyone else :-)
-Skrim
Damn, I wish I was in the position to recommend the systems. All I got to do was to pick a technology or two (and using Java only got me the position; it wasn't my first choice for this).
Speaking through an NDA, I get to hack together support for an application server that's
I probably would've gone with Sun boxen (pre-existing hardware, and something I know), BEA Tuxedo (this is a large enough shop to warrant something like this), Oracle (ditto), and let the front-end programmers worry about the presentation layer *grin*
*sigh* back to reality.
Finger pointing? We love it! Remember: every support call you make reduces the vendor's profit on the support contract.
See under "Support" here.
Ade_
/
Big Bubbles (no troubles) - what sucks, who sucks and you suck
Although this sounded like a good idea, practically it was hopeless. We had to farm all hardware support out to a 3rd party, and finding a competant 3rd party that was aware of our OS was impossible. We also had to learn all the applications and other tools used by the customer, not all of which we had supplied.
One customer was a nightmare. They used us for everything. They'd call us for support on a DOS application that was over 8 years old, wondering why it couldn't handle PentiumMMX processors. They'd call us to download printer drivers for their 5 year old printers. They'd even get us to call hardware engineers to clean a mouse. Yet they wouldn't upgrade their network to even a remotely current release!
Eventually we stopped doing hardware, as we were loosing money.
If you've got a big enough shop, the fastest solution is to get a consultant from each company on site. They don't have to be rocket scientists, but if they get the idea that they have to work together as a team, they will. Of course, this doesn't work at a small company - there, your best chance is to get someone from one company (either one of the vendors or a large consulting company) on site, and make it contractually their problem to keep your site going.
Law is whatever is boldly asserted and plausibly maintained. -- Aaron Burr
Ever since I started using AIX (3.2.5) it has supported booting from tape, disk, cd and network. And hey if you were really perverse you could boot AIX from floppy. Okay AIX can be a bit picky about what type of CD it boots from i.e non-IBM badged CDs can be a bit challenging; but in general it works.
Of all the unices I've used, AIX is just about the easiest to administer and once the ODM has gone; it will be even better (well unless they replace with something worse; like the SDR...aaargh!!)
I've checked out websphere lately.
I'm still not impressed.
Only the expensive version supports EJB, the JSP engine is almost entirely unhelpful for debugging (tomcat at least tells you soemthing beyond "compilation failed" when there's an error), it's excrutiatingly picky about what it runs with (needs a specific version of Oracle which naturally none of my other apps want to use), doesn't support JDK 1.2, has some OS issues...
In short, it's a good idea that came out rather messy. It might work fine under AIX or OS/400 with DB/2 as a backend, but if you ever want to add any functionality for any other platform or any other database, you're essentially boned.
----
----
"I used to listen to Null Device before they sold out."
If they are still hesitant to take charge, or the blame, require them by way of your service contract to work with you and the other vendor(s) until it's resolved.
As Chris Farley once said: "I can shit in a box and stamp in guaranteed if it'll make you feel better, but it doesn't mean my product is any good" (paraphrased, thankyouverymuch)
My 2
Ctimes2
My cube. My friend. My solace. My prison.
Why would you want to use anything other than DB/2 with AIX? I have been a lifelong DBA and have tried many combos, some which I am ashamed of :) I think DB/2, especially the 7.1 version just out, has come a long way, and certainly kicks SQL's butt (as released in a benchmark last week. I think www.infoworld.com ran the story) and Oracle won't submit to benchmarks,which makes me think they lack in speed as well. Plus the easy to use interface of DB/2 (command center is a godsend) mixed with bulletproof stability, who could ask for anything more?
Here's a super-short 30 second list of AIX annoyances:
11*43+456^2
How do I prevent (or at least minimize) them blaming each other when support issues come up? Anyone have a solution for this?
Before you buy, make sure that your prospective vendors are members of TSANet. Then, if one of your vendors points the finger at another, tell them to use TSANet to open a ticket with the other vendor on your behalf. As a support engineer at Tivoli Systems, I've used TSANet to open tickets with other vendors in order to resolve customer problems.
There have been a few other people who have mentioned this already, but I thought I'd pipe in with my story. At AOL (I was young and foolish then...) I had someone call me with the other vendor's tech on the line already. Within 10 minutes we had figured out that it was Microsoft's fault. There's always *someone* to pass the blame onto.