----------------------------------------<snip>----------------------------------
Judging from some of the posts here I think that those of you in the
user sysprog community think we software vendors stay up at night
trying to think of ways to annoy you.
It doesn't matter whether it's incompetence, malice or orders from
above. If my boss asks me to evaluate a products, I'll tell him all of
the problems I spot regardless of the reasons for them.
The problem is that many of us came up through a development career
path, not a sysprog career path.
Part of development is requirements analysis. You need to talk to your
customers and potential customers.
While I'm on a rant here you in the sysprog community should keep in
mind that you are not the entire audience for our products.
And you need to keep in mind that in some shops we get asked before
procuring, and in some shops we get listened to when we suggest
dropping a product at renewal time.
If my boss tells me that we have budgetary problems and need to find
some software to drop, the first ones that I will suggest are the ones
that are causing problems.
So by all means put in additional information, but not at the expense
of the information that we need, and not in a misleading fashion.
-----------------------------------------<unsnip>------------------------------------------
Charles, we don't paint all vendors with the same brush. There are a few
vendors that are very obscure, misleading and annoying. There are a few
that are remarkable for their openness. Most fall somewhere in the
middle Some of this range is caused by the programming "style" of the
vendor, some through incompetence, malice or orders from above. And some
from paranoia about software theft. And some is caused by a sincere
desire to meet customer needs with the least pain. It all depends on
people and we're all different, no matter what the development path
might have been.
Most sysprogs, in most shops, have a fairly good "feel" for what the
shop needs and try to be responsive, whether it's a custom-built
subroutine to fetch obscure data from the system, a customized exit, or
provide a service that isn't available in the particular HLL in use.
Selection of OEM software is part of that function, so we have to
evaluate the assets and liabilities of a number of products, and that
might also include start-up and shutdown requirements, whether it's at
system start-up and shutdown time or ISPF session start-up and shutdown.
Timing and order dependancies have to be made clear, and all too many
vendors don't provide that information, leading to a certain amount of
annoyance.
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
