[comp.sys.hp] Netpower: mkapr to be "obsoleted"?

jimr@maths.su.oz.au (Jim Richardson) (08/25/90)

Here's some more food for thought when you're writing your covering note to
send to HP with the Open Letter.  

In the chapter "Bugs, Limitations, and APRs" of the SR10.3 Release Notes
(copyright Hewlett-Packard August 1990, a 316 kB document of which I quote
a small extract for the purpose of comment), there appears the following
section:

     4.1  Obsoleting mkapr

     At the next release of Domain/OS we are obsoleting the mkapr utility
     in favor of the HP Response Center procedures.  These procedures
     include:

         1). Placing a call with one of our support centers using
             1-800-2-apollo.

         2). Filling out a Service Request Form from the back of one
             of our Software Status Bulletins and sending it to the
             Response Center nearest to you.

     Software Status Bulletins (SSBs) are not currently being printed from
     the Apollo Division, but should start in early 1991.  SSBs are known
     problems with their current statuses and are sent to our maintenance
     customers quarterly.

     mkapr is still shipping with 10.3 (although we will not fix problems
     reported against the mkapr command itself) and you may continue to use
     it until our next software release. However, we feel your questions
     can best be served if you place a call and talk to one of our Response
     Center Engineers.

For the benefit of comp.sys.hp readers: mkapr is a neat little window-based
tool for making an Apollo Product Report (APR).  It automatically inserts
your name, address and so forth, and has fields to fill in for title of
report, severity, product name, version, etc.  It then allows you to edit
the body of the report in a window into which you can paste transcripts
showing the bug, tracebacks, listings, and so on.  It then generates a nicely
formatted report in a file, and/or automatically emails the report off to
Chelmsford.  

For me, this is *far* preferable to either of the offered replacements 1) or
2).  I agree that the telephone has its place, and can be useful for some
kinds of problem.  But as is pointed out in the Open letter, telephone
support is not suitable for more technical questions.  Apart from the
frustration and delay of waiting on the line with nothing but canned music
for company, there are two major drawbacks: it's really hard to dictate
something precise and complicated like a traceback or a piece of C code over
the phone; and with the phone you have no record of the discussion, except
perhaps some scrappy hand-written notes, whereas an emailed bug report can
be kept on-line on your machine and form the basis for a history file of the
response from HP.  

As for method 2), do they expect me to fill out a form with a *pen*?  I
don't write anything significant by hand any more: it all goes through my
workstation where I can get it right, print it out or better still email it
off, and have a convenient record.

As goldfish@concour.cs.concordia.ca (GOLDSMITH paul) has pointed out,
> One of the things that continues to surprise me is the fact
> that people will frequently allow important information to
> exchange without any paper trail.  Lawyers call this
> "papering a file".  This means that all important
> information is either transmitted or confirmed in WRITING.

mkapr was a great way of doing that, and neither 1) nor 2) is nearly as
good.  Goldfish's suggestion of sending an email follow-up to each telephone
call is an excellent practice to follow.  But for my part at least, I'd just
as soon dispense with the call and work entirely by email, especially for
those knotty technical bugs that take the most work and time anyway.  A
"paper trail" is *inherent* to email.  

I know that a lot of people have become discouraged and don't bother to
submit APRs any more, because of the delay or complete absence of acknow-
ledgements, let alone definitive responses.  But the remedy for that is for
HP to improve its servicing of reports.  Instead ... well I've heard of
shooting the messenger, but here they seem to be gunning down the whole
*medium*, mkapr itself.  This is completely contrary to Request 2(a) in the
Open Letter, which asks HP to:

      Organize and oversee a new, effective system whereby APRs (and their
      HP/UX counterpart) can be submitted by electronic mail, acknowledged
      by return email, and then answered by email within a reasonable time
      -- say, two months.  ...

Far from abolishing mkapr, I feel HP should modify it as necessary to fit
the Service Request format, then consider making it available on HP-UX as
well as Domain/OS, with a proper working email channel to support it.  

I have spoken (by telephone :-) with the Australian Response Centre Manager,
and indicated what a retrograde step I feel the withdrawal of mkapr would
be.  I believe he will take my complaint seriously, and I hope there is some
chance of getting the decision reversed.  It should help if people put in a
kind word for mkapr in their covering letters.  

On a more positive note, he also informed me -- if I've got this right --
that there will be a 25% increase in personnel at the Chelmsford Response
Centre itself, so there's a prospect for better performance on getting APRs
answered.  

By the way, the Software Status Bulletins for Domain/OS, mentioned in the
Release Notes extract above, seem a step in the right direction.  But I
don't think a quarterly issue in printed form will really be much use.
Why not an on-line version, updated frequently, in an FTP archive, as in
Request 3(b) of the Open Letter?

Another matter:  My sales rep has informed me that at SR11 Domain/OS will
offer a choice of the DM, an X11R3 share-mode server, and an X11R4 borrow-
mode server: because of performance considerations and some design conflicts
between the DM and X11R4, a share-mode X11R4 server is not planned.  This
seems to be just what nazgul@alphalpha.com (Kee Hinckley) predicted in his
article <1990Aug11.153706.22322@alphalpha.com>.  I'm still very disappointed
by this (see <1990Aug13.091641.3639@metro.ucc.su.OZ.AU>), and I hope a way
round the design conflicts can be found.  I will pursue the question
further, and hope to report on it in more detail soon.
--
Jim Richardson
Department of Pure Mathematics, University of Sydney, NSW 2006, Australia
Internet: jimr@maths.su.oz.au  Phone: +61 2 692 2232  FAX: +61 2 692 4534