Understanding what the tool is *specifically* doing and knowing what the took is *supposed* to be doing are completely different. The first implies reverse-engineering of the application's code, the second implies knowledge of your systems.
Saying it's the responsibility of the vendors... I am talking about situations where you have purchased the software tool, purchased "extended support" and can now lean on the vendor to respond within the terms of their SLA. And you always have to have a plan B in case the vendor can't deliver on their promises. Mike http://www.lostinthedetails.com On Jan 27, 2011 9:22 PM, <[email protected]> wrote: On Thu, 27 Jan 2011, Michael Ryder wrote: > Yes, Atom, that's exactly what I meant. > > And no, Robert, I wouldn't be sitting on my hands wait... In order to script your way around the problem, you have to be willing to go under the covers enough to understand what is happening so that you can script to get it done. >From your initial post it sounded like you were saying that you saw no reason to understand what was actually happening, "that is the responsibility of the vendors". If that was what you were saying, there would be no possible way for you to script around the problem as you would have no way (and no intention) of understanding what the tool was trying to do. David Lang > In my experience, at least in the last 5 years, the Windows tools I use are > all stable, all wo... _______________________________________________ Discuss mailing list [email protected] https://lists.lopsa.org/cgi-bin/mailman/listinfo/discuss This list provided by the League of Professional System Administrators http://lopsa.org/
_______________________________________________ Discuss mailing list [email protected] https://lists.lopsa.org/cgi-bin/mailman/listinfo/discuss This list provided by the League of Professional System Administrators http://lopsa.org/
