Conference kernel::csguk_systems

    
    	my thoughts:
    
    	we use template files in the same was as the "P" description
    	for branch action.
    
    	we have consistency of updates by using a "technical" template
    	that will contain all the techie details, and an "action"
    	template that will contain all the action/escallation details.
    
    	no duplicate P's or C's just the above two descriptions that 
    	expand with the call. 
    
    	Brian 

I have just been looking in the bug hold queue to see what is going on, call 
91943 is a good example of a call hard to read. Contains loads of updates for
no good reason. I think the bottom line is we don't really know what is going
on. (I had to read through 19 descriptions to find this out).

This could be put down to one or two updates exluding any from outside the 
group.
                      <<< Note 175.1 by KERNEL::ANTHONY >>>


    	>my thoughts:
    
    	>we use template files in the same was as the "P" description
    	>for branch action.
    
    	>we have consistency of updates by using a "technical" template
    	>that will contain all the techie details, and an "action"
    	>template that will contain all the action/escallation details.

Not quite sure what you mean by the action template, can you give an example?
What I had in mind was just a simple history of all the actions as in the
example I gave. I would like keep this as short as possible to avoid wasting 
time (bearing in mind I will probably be scanning most calls that come
into the bug_hold queue to see what is going on)

    	>no duplicate P's or C's just the above two descriptions that 
    	>expand with the call. 

Don't think it will be feasable to have a single P if several people look at
the call for size reasons. Also it helps to look at the call and see in a glance
who has done some work. (I think P description should be only used for technical
anlysis, if you have just put the dump up, or spoken to the customer should
just add to the a description.)


What does everyone else think?

    *A*
    I have already discussed this briefly with Brian Anthony before reading
    this note. I totally agree with description type 'A' being used by
    every specialist that gets involved with the call and updating it with
    date/time and a description of what they have done.
    *C*
    Description type 'C' should not be used by us at all; they cannot be
    modified and just help to clutter the call.
    *P*
    Haven't made my mind up on this yet as to whether we should have one
    'P' description or multiple. The way I believe some of us use 'P'
    descriptions (in SYSTEMS) is to describe the problem/action to the
    service centre for actioning by an engineer - only one is required.
    Do we need multiple 'P' descriptions if we have mutiple ENTRIES in the
    'A' description. These, by default will describe the problem and the
    findings to date.
    
    NB

    You've got me confused Dave. In .0 you say you want us to create a
    separate P description for each chunk of work done. In .2 you complain
    that you had to wade through 19 descriptions to see what was going on
    with a call. If we follow your suggestion in .0 we aggravate the problem
    you complain of in .2. 
    
    I agree with the use of the A description although it's a change to
    its intended use. It's intended use is for action plans rather than
    actions taken.
    
    I disagree with the use of many P descriptions. There should be only one 
    and we should add to it at the bottom. I would add a rider to that to
    say that if after much work the call is sent to the service office for
    an engineer to so to site then we should create a second P description
    for the normal template file so the resource controller dosn't have to
    fight his way past our drivel to get to the stuff he wants.
    
    C descriptions can be a pain - especially when they get bunged on the
    wrong call. I wouldn't miss them if we didn't use them.
    
    roland

>    You've got me confused Dave. In .0 you say you want us to create a
>    separate P description for each chunk of work done. In .2 you complain
>    that you had to wade through 19 descriptions to see what was going on
>    with a call. If we follow your suggestion in .0 we aggravate the problem
>    you complain of in .2. 
  
The call I complained about had 3 a descriptions, bout 12 c descriptions and
2 p descriptions,(of which one was a comment, the other a diagnosis 
notification) - neither of these 2 would count in my definition of a p 
description. (in fact probably hardly any of the other 15 either)

Let me clarify what I think should go onto p descriptions. I only mean detailed
analysis, such as stack contents bits of source code etc. Say you take a call
and do some work on it by dialing in. The tape gets sent in and Jt looks at it
then jt gets me to look at it.  If each of us put our analysis it will make it 
easy to see who has done what. It is unlikely that more than 3 or 4 people will
analyze any particular crash dump so shouldn't get out of hand.

NOw if we all update the same description it will get unwieldy and may well
blow the limits for nice descriptions. Also you may want to add to your bit at
a later stage and if we are all overlapping it could get even more confusing...

Can I suggest that we keep it a bit flexible here, if you do a considerable 
amount  of work you create a new description, if you are adding a little extra
information to an existing update you just extend the existing one.

(If someone asks me to look at a call I would always create a new p description 
so that I can see I have been there before...)

>    I agree with the use of the A description although it's a change to
>    its intended use. It's intended use is for action plans rather than
>    actions taken.

Good point, the end of it will be current action plan, the bits before the
previous action plans/actions take. THE SERVICE WISH SHOULD CONTAIN A SUMMARY
of the current action plan.

>   I disagree with the use of many P descriptions. There should be only one 
>    and we should add to it at the bottom. I would add a rider to that to
>   say that if after much work the call is sent to the service office for
>   an engineer to so to site then we should create a second P description
>   for the normal template file so the resource controller dosn't have to
>   fight his way past our drivel to get to the stuff he wants.

Ah well done. I forgot about the diagnosis notifications. I will add to my
suggestion that we have yet another type of description purely for this. DN
seems the obvious choice. But I think things with d at the start may be customer
readable. I will check this out. 

So to summarise my proposals now.

ca - crash dumps summary in canasta style *1
a  - actions taken/action plan *1
dn - (or whatever it is called) *? (one per branch notification)
p  - problem analysis * ?

also 
c - for comments by ccd etc.
s - when closing the call (I don't normally bother with these!)

Also note that I have started using the opt sup field on some calls. This is to
remind me of calls that I have 'looked at' and when I last looked at them. If
other people want to use the field let me know and I will use something else. 
(I am just trying to keep an 'eye' on calls coming into the group so I have some
idea of what calls may be coming my way.)


dg.

    
    	I'm still thinking about all this!!
    
    	but re: -1
    
        dn - (or whatever it is called) *? (one per branch notification)
    
    	We can't make this change alone.  The P description is used
    	together with the notification template by all the groups
    	in the building (or at least it should be!)
    
    	I think we'll upset a lot of branch people if we change this
    	notification process.  
    
    	Brian

    ref -1
    
    Brian,
    
    	OpenVMS & COMMS  do NOT use the current notification template format 
    despite being requested to do so. I appreciate this leads to confusion
    but [as the saying goes] "you can lead a horse to water but you can't
    make it drink" 
    
    	Norm

The details of how we do it and what we call it don't really matter. What I
am trying to do is make it easy to tell what sort of info is on a description.
In particular seperate the diagnosis notification from the technical anaysis.
What we call the description types don't really matter.

If the branch and other groups use/expect p for dianosis notificiation lets
use another type for detailed crash anaysis. (eg there is already a ts for 
trouble statement, or could invent a new code - how about ta or td for 
technical analysis or technical details.)


fyi you can see all the current description types by show table (19) in nices.
It is no big deal to add a new one.

dg.

    TD or TA would be ok by me. 

    
    How about defining what sort of information should go into each type
    of description that we wish to use, and then adding to each one, with
    dates & times, if the call passes to another specialist.
    
    eg.
    
    P Desc   Any details SPECIFIC to the problem.
    A Desc   Actions taken in general  eg "Updated customer"
    C Desc   Comments  eg change of customer contact/phone # etc.
    S Desc   THE SOLUTION.
    

    re .10
    
    Brian, some of us have already been discussing this offline and the CIG
    tomorrow will hopefully come up with some further suggestions on this
    idea.
    
    DG. As I was reading your last input I thought, how about TA if its
    possible. It is quite clear (from reading on) that it is possible. This
    would be fine by me. One point though; say other groups decided to
    invent their own description codes - things could get a bit out of hand
    (does this matter). Well, may be it does. If we come up with
    sensible/easy to remember description codes, why not encourage all
    groups to use these in an attempt to get standardisation.
    
    OK Norm, yes I know - you can lead a horse ...........
    
    NB

Chaps,

	During the last unit meeting I was asked to clarify the use & meaning
of the various NICE descriptors as used by the OpenVMS-Systems Group. The list 
doesn't include DS as this is used to update customer's via DSNmail.

	These are:-

NICE Description
================

	A		ACTION

			Used for initial UPDATE, additional UPDATES,
			brief bugcheck information and if a crash is
			going to be sent in for further analysis.
			If an Action Plan has been agreed with the customer
			include this in the update. If there is a STARS 
			article identifying the problem include this also.
			
			There SHOULD be only 1 'A' descriptor - please add 
			your own update to an existing 'A' DON'T generate
			a new one as this causes confusion.

			Please use Ken Robb's templates - Don't use your own 
			as this introduces inconsistency.

			----------------------------------------------------

	P		PROBLEM

			Only used when Customer Services need to take action 
			on your diagnosis. 

			There SHOULD be only 1 'P' descriptor.


			Please use Ken Robb's templates - Don't use your own
			as this introduces inconsistency.

			----------------------------------------------------
	
	TS		TROUBLE STATEMENT

			This is a "free" descriptor and there is no template
			needed. Include, for instance, bugcheck 
			information/analysis, error logs, STARS articles etc.

			There can be multiple 'TS' descriptors but if specific
			information is highlighted, in another descriptor, then
			identify which TS descriptor it relates to.

			----------------------------------------------------

	S		SOLUTION

			This is a "free" descriptor and there is no template
			needed. Use only when the request is closed.

			----------------------------------------------------

	C		COMMENT

			This is a "free" descriptor and there is no template
			needed. Use these sparingly as they cannot be modified.

			There can be multiple 'C' descriptors.

	Please feel free to comment, add suggestions etc


	Norm
    

    Consider this:-
    
    	If an action is going to be taken by the customer (shutdown & reboot
    for instance) and the request can be closed ie await further crashes,
    this ISN'T a solution. Therefore only update the A descriptor and the S
    descriptor isn't created.
    
    	What does the panel think?,
    
    		David its over to you......
    
    Norm

.13 	Yes I agree, should not use the 's' description unless there is a 
proper solution.

.12 Dont forget that there is a CA desc as well.

Cant see how there can only be one 'P' desc if the call goes to customer 
services multiple times.

Note that I have started using the RC description (this may be temporary if I 
get around to getting more meaningful type eg SU) This for suggestion updates 
- if I see a call in a wait queue and put a comment on with a suggested strategy
for dealling with the problem. (I dont use the standard types because it caused
confusion and people thought I was wanting to take the call when the tape came
in).

agree, give c desc a miss, they are a mess. Leave them for the switchbord 
callback type comments.


This late reply prompted by the change forum thing (see note 218)