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.
Indeed it has happened before. I'm reading The Great Game by John Gordon which is a history of the US stock market. I don't know what Schiller's theories are but this sort of things has happened many times in the past.
Most people remember 1929 because they've heard of that but the same type of thing (but not for the exact same reasons) occurred at least a couple of times before that (at least twice in the 1800s, for example).
To me this "technology" boom isn't that different from the railroad stock boom or that of oil and steel company stocks before.
Re:My question: Will this document contain softwar
on
GPL for Books?
·
· Score: 1
Well, it is 'necessary', in a sense. The problem is that no matter what language you write in there will almost always be more than one way to do something. This is, after all, traditionally one of the basic tenets of Perl.
I'm writing a perl script now and, even though it's not finished and it works, I already have 3 different versions that do the same job. Each one is smaller than the other and I change things as my ideas about how to solve the problem evolve. (Admittedly, I can't leave well enough alone most of the time and try to come up with a solution that uses the fewest lines of code. Luckily, there's no real deadline for this one:)
There are no 'best 2 or 3 scripts' for any given job. This is always going to be subjective. As you learn more perl you'll find better ways to do things.
The authors of such a book may include only two or three examples to save space but they may or may not be the 'best' ones.
Check out the Perl Cookbook if you haven't already (though I wouldn't necessarily recommend it unless you've been doing perl for a while). Read the whole perl faq and get Freidl's (sic?) book on regular expressions. You'll be glad you did (it will help for more than just perl too).
It is unfortunate that the open source v closed source "debate" always seems to degenerate into a profoundly uninteresting discussion of politics, ego and other things not worth spending much time on. Perhaps the two cannot be separated but I think they can.
The amateur debate about the definition socialism and all the rest is easy enough to ignore, and I do. What few contributors to this thread seem to be interested in (though there are some) is the software that results.
Often, the "discussion" here reminds me of the worst of usenet. I should just stick to the articles.
Slashdot Mirror
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.
Indeed it has happened before. I'm reading The Great Game by John Gordon which is a history of the US stock market. I don't know what Schiller's theories are but this sort of things has happened many times in the past.
Most people remember 1929 because they've heard of that but the same type of thing (but not for the exact same reasons) occurred at least a couple of times before that (at least twice in the 1800s, for example).
To me this "technology" boom isn't that different from the railroad stock boom or that of oil and steel company stocks before.
Well, it is 'necessary', in a sense. The problem is that no matter what language you write in there will almost always be more than one way to do something. This is, after all, traditionally one of the basic tenets of Perl.
:)
I'm writing a perl script now and, even though it's not finished and it works, I already have 3 different versions that do the same job. Each one is smaller than the other and I change things as my ideas about how to solve the problem evolve. (Admittedly, I can't leave well enough alone most of the time and try to come up with a solution that uses the fewest lines of code. Luckily, there's no real deadline for this one
There are no 'best 2 or 3 scripts' for any given job. This is always going to be subjective. As you learn more perl you'll find better ways to do things.
The authors of such a book may include only two or three examples to save space but they may or may not be the 'best' ones.
Check out the Perl Cookbook if you haven't already (though I wouldn't necessarily recommend it unless you've been doing perl for a while). Read the whole perl faq and get Freidl's (sic?) book on regular expressions. You'll be glad you did (it will help for more than just perl too).
It is unfortunate that the open source v closed source "debate" always seems to degenerate into a profoundly uninteresting discussion of politics, ego and other things not worth spending much time on. Perhaps the two cannot be separated but I think they can.
The amateur debate about the definition socialism and all the rest is easy enough to ignore, and I do. What few contributors to this thread seem to be interested in (though there are some) is the software that results.
Often, the "discussion" here reminds me of the worst of usenet. I should just stick to the articles.
e-s-r, r-m-s, m-o-u-s-e