[Search for users] [Overall Top Noters] [List of all Conferences] [Download this site]

Conference iosg::all-in-1_v30

Title:*OLD* ALL-IN-1 (tm) Support Conference
Notice:Closed - See Note 4331.l to move to IOSG::ALL-IN-1
Moderator:IOSG::PYE
Created:Thu Jan 30 1992
Last Modified:Tue Jan 23 1996
Last Successful Update:Fri Jun 06 1997
Number of topics:4343
Total number of notes:18308

11.0. "Problem description 'Crib Sheet'." by UKCSSE::PLATT (Can't help if you don't talk to me!) Fri Aug 03 1990 12:33

   ALL-IN-1 problem escalation 
   
   A large number of problems that get passed to the ALL-IN-1 CSC's and
   beyond do not have enough information supplied to allow technical work
   to begin on the problem. This also applies to some extent to notes
   entered in this conference.

   This note is intended as a crib sheet and describes the minimum
   information required in a problem report. 
   
   This information is required to help to ensure that the majority of the
   time spent by the specialists involved with the problem, is focused on
   determining the causes of the problem and engineering a solution. The
   availability of quality, clearly presented information will result in
   faster problem resolution. When compiling a problem submission please
   remember that whoever looks at the problem may not have not been
   involved with the problem at all prior to receiving the problem 'report'
   (CLD, SPR, Note, Mail etc.)   and therefore a clear and precise problem
   statement is very important.
   
   The only way anyone can respond to problems 'submitted' without the
   appropriate information is by requesting further information. This
   request-response  cycle is very time consuming and can delay obtaining a
   solution by days or even weeks. It is impossible to make any progress
   toward resolving a problem that is not adequately described.
   
   The information listed is a minimum and any extra relevant information 
   should be included. If, because of the nature of the problem, some of
   the information listed below is not available then it maybe helpful if
   the reason for it's absence is given.

   
   Minimum Information Required
   
   1.  Digital Personnel details (May not be applicable to a VAXnotes
       entry)
   
       For each Digital person who needs to be involved in any related 
       communication it is useful to know:
   
       - Name
       - VAXmail address (Plus ALL-IN-1, address if available)
       - DTN phone number
       - Office location
       - Role
   
       This list would normally include a minimum of the Technical Manager,
       Field  Support Engineer(s) and the CSC engineer(s).
    
   2.  System Configuration

       For Example:
   
       - VMS Version
       - ALL-IN-1 Version
       - Message Router Version/MAILbus
       - FMS Version
       - WPSPlus version
       - What ALL-IN-1 patches have been applied.
       - What ASSETS packages are installed.
       - Versions of all other products (Digital or non-digital) that are 
         used with or interact with ALL-IN-1.
       - CPU type (If in cluster list all CPUs)
   
   3.  Details of the impact of the problem.
       
       So that problems may be addressed in correct order of urgency it is 
       important that an assessment of the impact of the problem on the 
       customers base is included.
       
       In the absence of such information the problem will be prioritized in 
       a manner which may not truly reflect the urgency of the problem.
       
       The impact of a problem is in two parts:
   
       - Severity. How severely is the customers business impacted by the 
         problem together with some indication of the cost to both the 
         customer and Digital if the problem is not rectified.
   
       - Scope. The scope of the problem is an assessment of how much of the 
         customer base is being impacted by the reported problem. This is 
         often not reflected in the problems priority. e.g. A priority 2 
         problem that only affects 1 or 2 customers is probably less urgent 
         than a priority 3 problem that affects 10% of the customer base.
   
   4.  Customer Expectations.
       
       It is often important to know what is required to get the situation 
       under control, i.e. what are the customers expectations together with 
       details of any constraints, deadlines or action plans, set by either 
       Digital personnel or the customer, that will have an impact on the 
       situation.
   
   5.  Description of the problem.
   
       The information required is:
   
       - A description of the symptoms of the problem including:-
   
   	  o What is the problem?
   	  o What error message(s) are produced?
   	  o What areas are affected by the problem (e.g. mail, time 
            management etc.)?
   	  o What areas could be affected by the problem but are not?
   	  o When was the problem first discovered (date, time)?
   	  o Has the problem been seen since then and if so what is the 
            frequency of occurrence of the problem?
   	  o Is the problem getting better, worse or not changing since it was 
            first discovered?
   	  o What is the extent of the problem (e.g. what proportion of users 
            are affected, how many corrupt mails etc.)?
   	  o Does the problem occur if the /NOCUSTOM DCL qualifier is used?
     
         
       - A description of the process leading to the symptoms.
       - A trace log for the above process if applicable.
       - Module of failure (if known).
       - Copy of stack dump(s), where available.
       - A map of the ALL-IN-1 should be available.
       - Details of the steps required to reproduce the problem.
       - Details of any relevant customizations, including any code level 
         integration.

   6.  Details of investigation carried out
   
       Details of all investigations carried out and the results of those 
       investigations should be included. This helps to prevent duplication
       of effort.
   
   7.  Any know workarounds or solutions.
   
       If a workaround or solution to the problem was found then it should be 
       included in the problem report.
   
       
    8. Details of Change History.
    
       Was the customer's system changed in any way at around the time that 
       the problem was first noticed? As a minimum the following points 
       should be considered.
    
       - ALL-IN-1 patches installed
       - VMS Upgrades/Patches
       - Hardware upgrades/option swaps
       - Notable changes in hardware fault rates
       - Changes in the usage of ALL-IN-1 or related software
       - Layered product upgrades
       - 3rd party product upgrades
       - Customer's own applications (outside ALL-IN-1) upgraded or modified
       - ALL-IN-1 Applications modified or upgraded.
       - New products installed (Digital or non-Digital)
       - New customer written applications installed (outside ALL-IN-1)
       - New ALL-IN-1 Applications installed
       - Changes to SYSGEN or UAF parameters
       - Changes in system or ALL-IN-1 maintenance procedures
    
    9. Other Information.
       
       The 'header' information required will vary according to the tool used 
       to submit the problem but (in addition to anything listed above) 
       should contain:
    
       - Problem priority.
       - Submitters' reference number.
       - Related CLDs', SPRs' etc.
       - Related VAXnotes discussions.


   If every problem 'report' had all of this information the customers
   would see a dramatic reduction in the time it takes us, Digital, to fix
   their problems.

   Any comments are most welcome; Either mail me or pop a note in here.

   Have Fun,

   Pete Platt. ALL-IN-1 CSSE.
T.RTitleUserPersonal
Name
DateLines