T.R | Title | User | Personal Name | Date | Lines |
---|
795.1 | No Problem | JUMBLY::DAY | 99% of Everything... | Fri Apr 28 1989 11:47 | 9 |
| Easy.
1. Search Easynotes.lis for the appropriate notes file
2. Post your grumble as note n
3. Post your SPR as note n+1
That should sort it ..
Mike Day
|
795.2 | a more formal approach | WHIRL::HCROWTHER | HDCrowther|USIS|297-2379|MRO3-1/N17 | Fri Apr 28 1989 12:15 | 48 |
| The following, from VAXWRK::VMS_FIELD_TESTS Note 2.1 (David STAR::BERNARDO),
describes how to use the QAR system, the internal/electronic SPR system.
[Disclaimers: I'm not sure "SPR" and "QAR" are exactly equivalent;
the QAR system is not too user-friendly, and not for all products,
but it *is* electronic.]
---------------------------------------------------------------------------
It is now very easy to enter a QAR in the VMS QAR database on node TRIFID.
To enter a QAR, simply SET HOST to node TRIFID and login with the username
QAR_INTERNAL and password QAR. You will then be prompted for the database;
select the appropriate one.
At the "QAR>" prompt, type the command "ENTER" to enter a new QAR.
You will then be prompted for the following (once per login):
Name
Cost center number and name
Enet mail address
Phone number and mail stop
CPU type
Memory size
System device
For each QAR entered, you will be prompted for the following:
VMS version
Attachments (ie, LISTING, TAPE, etc.)
Publish (QAR can be read by "others")
Reproducible ("problem" can be reproduced at will)
You will then be placed into the EDT editor where you can enter text to
describe your problem. Please include examples if possible. If you
have crash dumps, make them readable and tell us where they can be found.
Please use this account to enter QARs for the following products:
VMS
MicroVMS
Volume Shadowing
DECnet-VAX
RMS Journaling
Local Area VAXclusters (LAVc)
VAX Encryption
NOTE, this account should be used by all employees who are NOT formally
participating in any VMS field tests. If you are doing lots of testing
and expect to be entering numerous QARs on occasion, then send mail to
TRIFID::QAR$MANAGER and request your own QAR account.
|
795.3 | | BISTRO::WLODEK | Network pathologist. | Fri Apr 28 1989 16:10 | 17 |
|
ICARUS::SPRADMIN is the right address, although my SPRs have
been confirmed from :
From: CSSE::HOLMES "Ponce Inlet is Paradise" 13-APR-1989 20:15:55.89
To: BISTRO::WLODEK
CC: HOLMES
Subj: SPR V11-631
Hello, SPR received and processed as ICA-22039.
Regards,
Tod
|
795.4 | They just moved to Stow, MA | VAXWRK::SKALTSIS | Deb | Mon May 01 1989 19:26 | 5 |
| For what is is worth, SPR administration just moved down the road from
PKO2 to STO about a month ago, the move took about a week. I believe
that they are still on ICARUS.
Deb
|
795.5 | | SCARY::M_DAVIS | nested disclaimers | Tue May 02 1989 20:42 | 66 |
|
For internal users who do not have an IN-DEC support contract, there is
still a means for them to submit an SPR on DIGITAL Engineered products.
The form and mailing address is attached.
Subj: Electronic SPR form, send to ICARUS::SPRADMIN
On-line SPRs can be submitted to ICARUS::SPRADMIN if you are a
U.S. submitter. SPRs are then sent to the CSCs for screening.
European/GIA submittals must go directly to the local country office
where they will be processed and screened in Europe/GIA first. Any
non-U.S. submittals will be routed back to the country of origin if
they have not been screened.
If you have any questions regarding the SPR submittal process, please
contact ICARUS::SPRADMIN.
D I G I T A L FIELD CODE NO. SPR NO.
-------------------------------------------------------------------------------
| OPERATING SYS | VERSION | PROGRAM OR DOC. | VERSION OR DOC. PART NO. | DATE |
| | | | | |
-------------------------------------------------------------------------------
| NAME: |DEC OFFICE AND CONTACT PERSON |DO YOU HAVE SOURCES |
| FIRM: | | YES( ) NO( ) |
| |-----------------------------------------------------|
| | REPORT TYPE/PRIORITY |
| ADDRESS: | ( )HEAVY SYSTEM IMPACT |
| | ( )PROBLEM/ERROR ( )MODERATE SYSTEM IMPACT |
| | ( )SUGGESTED ENHANCEMENT ( )MINOR SYSTEM IMPACT |
| CUST. NO.: | ( )OTHER ( )NO SIGNIFICANT IMPACT |
| | ( )DOCUMENTATION/SUGGESTION|
-------------------------------------------------------------------------------
| SUBMITTED BY: |PHONE: | CAN THE PROBLEM BE YES( ) NO( ) |
| | | REPRODUCED AT WILL? |
------------------------------------------------------------------------------|
| ATTACHMENTS | COULD THIS SPR HAVE BEEN PREVENTED BY |
| | BETTER OR MORE DOCUMENTATION? YES( ) NO( ) |
| | PLEASE EXPLAIN IN PROVIDED SPACE BELOW. |
-------------------------------------------------------------------------------
| CPU TYPE | SERIAL NO. | MEM. SIZE | DIST. MED. | SYS. DEV. | DO NOT PUBLISH |
| | | | | | ( ) |
-------------------------------------------------------------------------------
| |
. . .
. . .
. . .
| ALL SUBMISSIONS BECOME THE PROPERTY OF DIGITAL EQUIPMENT CORPORATION. |
-------------------------------------------------------------------------------
|SHORT NAME |MNT. CAT. |MNT. GRP. |XFER. GRP. |PL | PRB. TYPE |
| | | | | | |
-------------------------------------------------------------------------------
|DATE RECEIVED(MAIL) |DATE TO MAINTAINER |XFER. DATE |LOGGED ON |
| | | | |
-------------------------------------------------------------------------------
|DATE RECEIVED(ASG) |DATE RECEIVED FROM MAINT. |DATE ANSWERED |LOGGED OFF |
| | | | |
-----------------------------------------------------------------------------__
|
795.6 | Got it. | INFACT::NORTHERN | easy as shoving a goat uphill... | Wed May 03 1989 15:45 | 10 |
| Thanks for all the information all,
Come to find out, the DECnet move of ICARUS was hosing me up.
Fixed my DECnet database, and the thing actually got sent.
Am now awaiting response from my submittal...
- Lou
|
795.7 | SPR On-Line Submission Form | DEBUG::GALLO | Fast/Cheap/Good... limit 2 only! | Mon Aug 26 1991 11:08 | 90 |
| Well, it's been a few years, and the process for On-Line SPR submission
has changed slightly. Here is the most current information...
-----------------------------------------------------------------------
Attached is a blank on-line SPR form. Please fill in all fields as you
would when submitting a paper SPR form. Send the completed SPR to:
CSCOAC::REGISTER_FS
or CSC/AT FS REGISTRATION @ ALF (From ALL-IN-1)
SPR Contact Name: Ken Steffensen @ALF (8-343-1747)
SPR Corporate Problem Mgt Admin: Randy Gauthier @OGO (8-276-8810)
As the SPR submittor (your name/node should be in the "Submitted by"
field), you will receive an acknowledgement after the SPR is processed,
with the corporate SPR number which has been assigned.
In order to recognize which submittal we are acknowledging, it would be helpful
if you would include some type of identifier if the SUBJECT line of the mail
message. For example, the DSIN sequence number (if applicable), or the
customer name and product, and/or a brief description of the problem.
For SPR status information after submittal, contact the CSC in Alpharetta
and request SPR status against specific SPR number.
D I G I T A L FIELD CODE NO. SPR NO.
-------------------------------------------------------------------------------
| OPERATING SYS | VERSION | PROGRAM OR DOC. | VERSION OR DOC. PART NO. | DATE |
| | | | | |
-------------------------------------------------------------------------------
| NAME: |DEC OFFICE AND CONTACT PERSON |DO YOU HAVE SOURCES |
| FIRM: | | YES( ) NO( ) |
| |-----------------------------------------------------|
| | REPORT TYPE/PRIORITY |
| ADDRESS: | ( )HEAVY SYSTEM IMPACT |
| | ( )PROBLEM/ERROR ( )MODERATE SYSTEM IMPACT |
| | ( )SUGGESTED ENHANCEMENT ( )MINOR SYSTEM IMPACT |
| CUST. NO.: | ( )OTHER ( )NO SIGNIFICANT IMPACT |
| | ( )DOCUMENTATION/SUGGESTION|
-------------------------------------------------------------------------------
| SUBMITTED BY: |PHONE: | CAN THE PROBLEM BE YES( ) NO( ) |
| | | REPRODUCED AT WILL? |
------------------------------------------------------------------------------|
| ATTACHMENTS | COULD THIS SPR HAVE BEEN PREVENTED BY |
| | BETTER OR MORE DOCUMENTATION? YES( ) NO( ) |
| | PLEASE EXPLAIN IN PROVIDED SPACE BELOW. |
-------------------------------------------------------------------------------
| CPU TYPE | SERIAL NO. | MEM. SIZE | DIST. MED. | SYS. DEV. | DO NOT PUBLISH |
| | | | | | ( ) |
-------------------------------------------------------------------------------
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| ALL SUBMISSIONS BECOME THE PROPERTY OF DIGITAL EQUIPMENT CORPORATION. |
-------------------------------------------------------------------------------
|SHORT NAME |MNT. CAT. |MNT. GRP. |XFER. GRP. |PL | PRB. TYPE |
| | | | | | |
-------------------------------------------------------------------------------
|DATE RECEIVED(MAIL) |DATE TO MAINTAINER |XFER. DATE |LOGGED ON |
| | | | |
-------------------------------------------------------------------------------
|DATE RECEIVED(ASG) |DATE RECEIVED FROM MAINT. |DATE ANSWERED |LOGGED OFF |
| | | | |
-------------------------------------------------------------------------------
|
795.8 | | COVERT::COVERT | John R. Covert | Tue Aug 27 1991 12:54 | 1 |
| So, can customers send this thing to [email protected]?
|
795.9 | foreign SPRs? | ERICG::ERICG | Eric Goldstein | Sun Sep 01 1991 05:26 | 6 |
| Thanks very much to the author of .7, but does the US-only rule specified in .5
still apply? Even by the standards of Digital's beaurocracy, having local
country offices "screen" SPRs of standard products sounds bizarre. Will the
friendly folks in Alpharetta accept an SPR from me, a loyal Digital employee,
even if it's submitted from outside The Land Of The Free And The Home Of The
Brave?
|
795.10 | typically illogical Digital bureaucracy | ERICG::ERICG | Eric Goldstein | Sun Oct 27 1991 04:51 | 21 |
| It wasn't easy, but eventually I managed to submit an SPR electronically.
Here's what happened:
I sent mail to Randy Gauthier (referenced in .7), who explained the procedure.
The vast majority of Digital employees, those who work in the US, can send
electronic SPRs to a single CSC. An employee who works outside the US, on the
other hand, submits them to a designated person in his general area. I work in
Jerusalem, and Randy gave me pointers to service people in both Valbonne and
Herzliya (Israel). They, in turn, sent me pointers to other people, but no one
admitted to knowing how to handle an electronic SPR.
I finally appealed to Randy again, and she told me to send my SPRs to the US
office. I sent two SPRs, and within a couple of days had responses from the
person responsible for the product. Simple and efficient, exactly as it should
work.
If a single office can field SPRs from all employees in the US, there's no
reason why it shouldn't be able to handle those from non-US employees, as well.
I don't know who is responsible for the current system -- probably someone who
isn't aware that Digital has a worldwide computer network -- but it should be
changed.
|
795.11 | SPRs as seen from the CSC | PEACHS::BELDIN | | Mon Oct 28 1991 10:17 | 55 |
|
From the CSC's perspective, this is what happens:
- We submit an SPR via the CHAMPS system to something called
PIPE
- PIPE has a list of 'people' (in reality, mail accounts) that
it sends mail to based on the product. Those 'people' are
supposed to get the SPR into the TIME system.
Here my knowledge of what happens breaks down, but it appears
(from experience that) - these are rated from best to worse
cases:
- it will go from TIME to a QAR database somewhere where the
specialist who submitted CANNOT read it. Hopefully, it
then gets worked and we get a response back via the same
channels. Why we cannot read an SPR that we submitted is
beyond comprehension.
- it will languish in someone's (something's) MAil until:
- customer gets irate and goes CLD (funny how they
get 'found' all of a sudden)
- we get curious as to why this call has been
sitting in my open call list for a month
- at which point we can:
- send mail to the account (heck, maybe they will
respond to a real person - hasn't happened to me
yet, though)
- get one of the PIPE people to find out who the
DRI is. We can then call and find out that that
person has been TSFO'd ;-).
- post a note a notes file and find out from the
engineering group that they never saw the SPR,
file a QAR.
I've been through all of these paths. The biggest black hole
is when the call leaves the CSC - nobody can explain that. Each
engineering group does it different - some have someone technical
recieve the SPR's, some have CSSE, some don't, some have an
admin-type person, some ?
Whatever. The lack of consistency of getting the SPR from the
field to engineering is appalling. The lack of feedback on the
problem resolution is just as bad.
Rick Beldin
Atlanta CSC
|
795.12 | SPRs as seen from Product Development | SAUTER::SAUTER | John Sauter | Mon Oct 28 1991 15:38 | 37 |
| re: .11
I can fill in part of the rest of the process, for one product. In the
case of DECforms PIPE sends non-suggestion SPRs to our release
engineer, Meg Brown. She forwards the mail to the Designated Project
Leader, currently Dave Chestnutt, who responds with the name of an
engineer in his group who will be responsible for the SPR. That
engineer investigates the problem, hopefully reproducing it exactly as
described, and takes whatever action seems necessary to fix it. If the
fix involves a code change he must verify that the latest "build" of
the product actually fixes the problem, and usually he must add a test
to the regression test system to guard against the problem recurring.
When this is done the engineer writes a sanitized answer to the SPR and
circulates it among his management, his project leader, and whoever
helped him fix the problem, including any experts in the area of the
fix. He perfects the answer based on feedback from this group. After
two days of no objections he posts the answer in our SPR data base,
which sends a copy to the release engineer, Meg Brown. Meg then
sends the response back through PIPE.
I'm not sure what happens to an SPR response after it leaves our
release engineer's hands, but it usually arrives at the appropriate CSC
and is conveyed to the customer by a specialist. Sometimes SPR
responses get lost and have to be re-sent.
Each engineering group has its own SPR data base, so there is no
reasonable way for the specialists to read them---they would have to
learn a different User Interface for each product! TIME was an attempt
to provide a single data base for all groups, but it doesn't seem to
have caught on. Usually, there is someone in the engineering group who
is known to the specialists in the CSC and can be contacted directly to
answer questions, such as the condition of an SPR. In the case of
DECforms I have been assigned that responsibility by my management, so
it is a formal part of my job.
John Sauter
|
795.13 | | TOKLAS::feldman | Larix decidua, var. decify | Mon Oct 28 1991 16:42 | 21 |
| I thought that the support centers are soon migrating to IPMT, which would
provide a single mechanism for tracking SPR's up to, but not including,
engineering (yet).
re:.12
I'm amazed that you've wired a two-day delay into your process. If I were a
customer, I'd be upset. Is there something special about your situation
that necessitates that much review? The usual SPR responses I've seen are
pretty much boilerplate: "Thank you for reporting this problem, we've found
the bug, we've fixed it in the sources, and we expect it to be in the next
release of the product. In the meantime, here's a workaround/Sorry, we don't
have a workaround." Pretty bland stuff, deserving of a proof-read, perhaps,
but not a large review. Special cases may require more review, but those
are the exception, not the rule.
Which is not to say that all the SPR's around here get instant attention;
just that I don't know of any project that has formalized a review delay into
their process.
Gary
|
795.14 | just one example | SAUTER::SAUTER | John Sauter | Mon Oct 28 1991 17:18 | 6 |
| re: .13
I think our group may be unusual in having a two-day waiting period.
Needless to say, we don't share the details of our process with
customers.
John Sauter
|
795.15 | You probably know this better than I do, but... | TLE::AMARTIN | Alan H. Martin | Thu Oct 31 1991 19:19 | 21 |
| Re .14:
Well, the customers may not know where their problem report is cooling its heels
at any particular time, but they know they haven't gotten it until they've
gotten it.
The fact that you understand the problem flow for your product to this degree
implies to me that you have some worthy goals for the quality of your product's
service offerings. I invite you to periodically review your service processes
for improvement - some day you may just think of a way to satisfy your goals
without a two-day waiting period.
And since I'm pretty sure that problem reporting processes have been a DECUS
topic in the past, and you may have a better process than some other groups, you
might also reexamine why you're not willing to share your process with
customers (especially if we're supposed to establish an atmosphere of teaming
together to address their business problems). At worst, you might think of ways
to improve things, and at best you'll discover you have nothing to be ashamed
of, and something to be proud of.
/AHM/THX
|
795.16 | | SSDEVO::EGGERS | Anybody can fly with an engine. | Fri Nov 01 1991 00:46 | 2 |
| The problem reporting process has been a DECUS topic more or less
continuously for 25 years that I know of.
|