Excalibur wrote:
You've *GOT* to be kidding me!
Art

"Excalibur" wrote:
Feel free to disagree given your more distant perspective but I was
looking first-hand at the reports that came in, and comparing them to
what people were saying in the field, and the facts say you're
incorrect. Respectfully Peter, you've been out of this industry for a
long time. While you were gone I was trying to encourage people to
report their issues specifically because I was active in these forums
and saw first hand that the things people were most upset about were
not being reported to Pick Systems / RD. I didn't take that position
without looking to see what bugs were being reported or who was
reporting them.

As an aside, I don't want to up-play my former role over there. Many
people other than myself, particularly in Support and Engineering, had
a much closer view of what was going on and were specifically
responsible and had authority for making decisions about which bugs
could or could not be fixed and what the priorities were. I don't
want to make it sound like I did a lot over there other than try to be
the client's advocate within the company - which directly relates to
this discussion. And I have no clue what they do over there today but
I believe the process is pretty much the same as it's always been.

Many issues that get reported have no priority attached to them. One
user will report an issue and not state how critical it is to their
operation. A developer cannot make the assumption that every issue
reported is critical. Further, once a report has been filed with
Support, you can't assume that from the pile of non-critical issues
that Engineering will have the ability to determine that yours should
somehow be selected from the pile. Without user-prioritization the
market is subject to getting what the developer believes to be the
priority, and that's frequently wrong. At PS/RD, Support has always
played a major role in helping to determine priority. When an issue
is reported a couple times, Support flags it, and at weekly meetings
or other sessions their input weighs significantly with Engineering
initiatives. If they don't hear a given report more than once, they
can't be your advocate.

On the other side, there are some people who insist on everything
being a priority, and crying wolf has a tendency to cause user
priorities to get re-evaluated. Absolutely everything can't be High
to Critical. And as far as re-evaluation, there are a great many
times when a user will report something that doesn't seem like it's a
big deal but someone at RD will escallate the matter for business or
technical reasons, and a patch will get issued ASAP for something
someone thought was completely benign.

If you reported an issue to RD and it didn't get processed, it's
because:
1) you didn't ask for any priority,
2) no one else reported it so it wasn't internally recognized as a
priority, or
3) (yup, gotta be honest and this happens often enough) people over
there were just being stupid and not prioritizing obviously important
issues. There's no denying that some important things should
obviously be changed, but now we're leaving the word 'obvious' to
individual discretion, budgets, and other established priorities. On
many occasions PS/RD has taken initiative to do things that they
thought were priority and they were completely wrong. That's what we
all get for lack of communication between vendor and client.

I can't tell you how many times we internal people had issues that we
felt needed to be fixed and even we didn't get any priority either.
(Eh Bill? Mark?) This is where management personalities plays a role
and where your technical issues should become business issues. If you
don't escallate your technical issues as being business problems (like
you're going to take your 1000 seats to IBM if they don't make this
change in D3) then even issues flagged as important by interal people
don't carry much weight.

There have been many many bug and enhancement reports that I've filed
over the years, frequently based on reports from my clients or from
what I've seen in this forum, but even when I was at PS/RD I only had
one vote, and despite my begging in this forum for some backup I
rarely got support from you guys to escallate issues that were a
priority to you. This is why many things reported by any of us have
never been changed.

When I was there I was also pushing to have some requests published so
that people could vote on them. Not wanting to air its dirty laundry
PS/RD didn't want to do that. The view was that if it's a priority
the reports will come from the field. Mark and I discussed that one a
few times as we were occasionally on opposite sides of the fence,
which isn't surprising given the dynamics described here.

Most of you folks get bug and enhancement reports from your client
base but you don't have near the volume of calls that the MV DBMS
vendors get. How you establish priorities between your clients and
your development staff is your own business but given a situation that
you can't change all things for all people you also need to make
decisions about your priorities.

This is a lot longer than I intended (so what else is new). I'll just
summarize that the people managing all of these processes now are
completely different than the people managing the processes before.
You have different people in business management, Support, and
Engineeering. Take advantage of that, communicate your needs, and if
you don't get what you want, ask why and escallate it if you feel you
have a reasonable business case. And if you still don't get
satisfaction, there are a lot of migration options these days...

HTH
T

Hi Tony
I am interested to hear that I have been out of this industry for a long
time.
Funnily enough all my clients are on D3. I have been programming in Pick a
lot longer than you as I started in 1976. I have met with Rick Davies, Mark
Brown and others on their infrequent visits here. I have raised questions
with Dick Pick on his visit and attended every Pick conference that I could
afford. I was a lead vendor of AP on substantial machinery with serious
country wide connectivity (16 16 port muxes feeding modems into a large Edge
in 1988).
I have always used standardised code. In fact I was the co-author of the
first Pick 4gl. I have always had a test suite for my packages. In fact
one of my questions to Pick Systems was regarding that very item - a test
suite. Obviously the test suite that you ran as chief of QA must have been
thrown out given the current issues with Indexing.
My comments stand. In fact I can see from Mark's earlier responses where
the problem lay - what did he say, approximately 29000 issues as I recall.
Despite your disbelief I have always reported my issues. How far they get
through the chain is something I have no control over. As I said things may
have changed but "once bitten twice shy". Why do I comment because I want
MV through RD et al to be a roaring success and the only way I can hear is
through this forum. RD do not respond to straightforward things raised on
their own forum - please none of that codswallop about that is their rules.
Peter McMurray.
"Tony Gravagno" <g6q3x9lu53001 (AT) sneakemail (DOT) com.invalid> wrote

Peter wrote:

Either you said something that gave me that impression or I have you
confused with another Peter in your direction.

Apologies on that, we can agree or disagree regarding the comments, so
be it.

Regards,
T

Hi
I do appreciate your programming insights. I am arguably a little jaundiced
in my view of operating system errors. The support that TDATA provides is
great and I know Ross Ferris is helping RD sort out major issues. Thank
heavens he has the time and resources although I am sure he would rather
spend them on development.
You have wondered why I use this forum. Well I live in a beautiful place, I
know if it is going to be cold because the black cockatoos come down to my
trees, I can see Mcnaughts comet in the evening from my verandah, but I
cannot pop down to the local for a yarn with my Pick peers. This is "my
local". Also thanks to global decisions by New York based oil companies I
have a second string to my bow in hydroponic tomato production. However the
last time I cut any code was this morning - Oh! by the way, thanks Grigory I
suddenly had to do a csv import from Cobol/ISAM files produced by a
competitors system. I hate the things and the gifthorse saved me mucking
around.
Regards
Peter McMurray
Universe Central - Lilydale Tasmania


"Tony Gravagno" <g6q3x9lu53001 (AT) sneakemail (DOT) com.invalid> wrote

On Feb 17, 1:38 pm, "Peter McMurray" <excalibu... (AT) bigpond (DOT) com> wrote:

Pete,

Don't make too big a deal out of the fact that I'm "reporting issues"
- RD are SOLVING the issues all by themselves (I'm finding they do
quite a good job of that these day once you let them know!! I recently
got around to reporting the fact that I "always" had to change
"listfiles" for it to pickup "qs" accounts ... but along with everyone
else I simply didn't report the issue, so no surprise it didn't get
fixed. Very pleased to see it listed as a recent resolution)

I'd recommend that everyone (with a current support agreement) take
the time to simply document a single problem that they are aware of
with D3 (real problem rather than a nice to have - and to be fair,
confirm issue still exists on current release) and see if the "new" RD
is more responsive than your memory would suggest of the "old" RD. I
think the guys ARE doing a good job these days (warts & all) - put
them to the test and see. If the first one works, try another, and
another! We can all do our bit to help make things better

I also agree that TData does an excellent job in this corner of the
Universe :-)