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

Conference kernel::csguk_systems

Title:	CSGUK_SYSTEMS
Notice:	No restrictions on keyword creation
Moderator:	KERNEL::ADAMS

Created:	Wed Mar 01 1989
Last Modified:	Thu Nov 28 1996
Last Successful Update:	Fri Jun 06 1997
Number of topics:	242
Total number of notes:	1855

44.0. "NEW RSDS NOTIFY SCREEN" by KERNEL::ARCHER (Graham Archer Devices Diagnosis) Tue Jun 27 1989 11:53

 Hi everyone,
 
     I'm sure you are all aware of the problems we have with the current
     RSDS notify screen, the Field offices also have problems with it too.
     With regard to this, a meeting was held between Mick Magee,
     Alan Morris (London) and myself.     
     Between us we have come up with a draft RSDS notify screen which
     is included here.
     I took the inputs from the earlier notes conference (note 37)
     and some of them have been incorporated, together with requests
     from the field as to what they need.

     The result of our efforts is shown below. Please feel free to
     comment on it, whether it is o.k. or could be improved and in what
     way etc.
     The areas marked with a "*" would have to be completed by the diagnosis
     engineer. Other fields would be completed by Response. Please ignore
     the numbers in front of the lines, they are not important.

     So what do you think?

     Regards 

     Graham
 




1  Call Logged: dd-mmm-yy at hh:mm:ss                     
2  RDC Log No:______ 
3  System Type: _____   
4  Serial Number:_____________               Branch Log No:______
5  Call type: ___        
6  Contact Name:XXXXXXXXXXXXXXXXXXXXXXXXXXXXXX 
7  Phone Number:XXXXXXXXXXXXXXXXXXXX                     
8  Company Name:XXXXXXXXXXXXXXXXXXXXXXXXXXXXXX     
9  Address:XXXXXXXXXXXXXXXXXX


10 Postcode:XXXXXXXX



11 Cost Centre :XYZ                              
12 Service Operation:XXXXXXXXXXXXXXXX
13 Call Passed To (Diag Eng):XXXXXXXX 
14 Response Problem summary__________________________________________(History)

16*Call to be logged / Information only
17*Failing Device:________________________ Option Serial No
18*Engineer Reqd (Yes/No/?):___   When:___________________________________
19*Service Operation Action:______________________________________________
20*Customer Impact (C:)___________________________________________________   
21*Skill Required (S:)____________________________________________________
22*Parts Requirement FRU (P:)_____________________________________________
23*Trouble Statment (T:)__________________________________________________
__________________________________________________________________________
__________________________________________________________________________
__________________________________________________________________________
__________________________________________________________________________
24*Most Probable Cause:___________________________________________________
25*Frequency/Time of Failure:_____________________________________________
26*Other Possible Causes:_________________________________________________
27*Previous History:XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
                    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

T.R	Title	User	Personal Name	Date	Lines
44.1	A field for SDD please....	KERNEL::MCGAUGHRIN	what a marvellous delivery!	`Wed Jun 28 1989 16:39`	29
	Graham, The proposal as it stands looks good, certainly an improvement on the current screen. I would, however like to see an extra field added, if this is possible. There will be a need in the near future to flag whether a call has been as a result of Vaxsimplus. It would be very helpful if a field could be made available. The field would be used to identify whether Vaxsimplus, initially mailed the system manger, and prompted him to log the fault. Also, if this being the case, then there will be a need to input the Event Code that Vaxsimplus has called out. Both of these are important to the development of SDD, and are required to monitor FRU Call Outs, and ultimately the movement of parts from logistics. A possible suggestion ....... * Vaxsimplus (Y/N)___ Event Code ____________ Look forward to hearing from you... Regards Ian
44.2	2P worth...	KERNEL::ROE		`Wed Jun 28 1989 19:25`	15
	Graham, two thoughts, 1. What added value does line 16 give that's not given by line 18? 16Call to be logged / Information only 18Engineer Reqd (Yes/No/?):___ When:___________________________________ 2. lines 22 and 24 are surely equivalent? I don't believe we'll call out a FRU if it's not the most probable cause! 22Parts Requirement FRU (P:)_____________________________________________ 24Most Probable Cause:___________________________________________________ Regards, Mike
44.3	???????	KERNEL::ADAMS	Venus on Remote Control	`Fri Jun 30 1989 22:33`	11
	This topic has already been raised in note 37 and its replies. The proposal therein was arrived at after consultation with Ian Martin, and at a late stage, the Comms group. Pete Alvis is already working those proposals with the RSDS software developers. Has anyone approached him and/or Exceptions re any further changes. I understand, from talking to Pete, that making changes to what goes to the branch, is not an easy matter, anyway.
44.4	A little more info	KERNEL::ARCHER	Graham Archer Devices Diagnosis	`Mon Jul 03 1989 10:20`	12
	Hi, Thanks for the replies. To answer the last note, yes Pete Alvis has been informed and his views considered. The level we are aiming at is to re-write the notify screen not modify it as it stands today. The next reply details where we are currently at with the proposal, Graham
44.5	RSDS Notify in Detail	KERNEL::ARCHER	Graham Archer Devices Diagnosis	`Mon Jul 03 1989 10:21`	399
	The following document provides a more detailed layout of the proposed RSDS Notify screen. I have considered everyones' inputs to come up with the new layout and I would like to take this opportunity to thank you for them. I would still welcome your thoughts and suggestions on this latest version with a view to formalising the proposal in the very near future. Regards, Graham Archer NEW RSDS NOTIFY LAYOUT -------------------------------- INTRODUCTION ------------ This document defines replacement screen displays that are required to be implemented in the RSDS Notify programme, in order to improve the quality of the information entered and the quality of the information passed to the Service Operation Centre. CONSISTANT CALL NOTIFICATION DATA --------------------------------- The proposed system will ask the Diagnosis Engineer for information about a call which will provide a concise set of facts about a call in a consistant format. DATA FORMAT ----------- This section will set out in as much detail as possible the Screen Layouts required for data input at the CSC, and Data display at the Service Operation Centre. DATA INPUT ---------- The following is the layout required for the call notification screen displayed by the RSDS Notify programme at the Diagnosis Centre. A "" before the Line indicates areas where data input by the Diagnosis Engineer is expected. DIAGNOSIS SCREEN 1 Call Logged: dd-mmm-yy at hh:mm:ss 2 RDC Log No:......... System Type:............. Serial Number:............. 3 Call type: ... 4 Contact Name:......................... Contact Phone:............... 5 CompanY Name:.............................. 9 Cost Centre :... Alt CC1:... Alt CC2:... 10 Service Location :................ 11 Service Phone (Day):................ (Night):................ 12 Service DTN (Day):................ (Night):................ 13 Assigned Engineer:.................. 14Call to be Logged or Info only (Log/Info): .... 15Engineer Reqd (Yes/No):. When:....................................... 16Service Operation Action:.............................................. 17Failing Device:........ Unit Number:.......... Serial Number:.......... 18Problem Summary:........................................ 19Customer Impact (CI:).... Reason:.................................... 20Skill Required (ES:).................................... 21Parts Required (PR:).................................... 22Trouble Statement (TS:)................................................ 23....................................................................... 24....................................................................... 25Most Probable Cause:................................................... 26Frequency/Time of Failure:............................................. 27Other Possible Causes:................................................. 28 Notification Method Phone Contct Snd? Date Time Notifier 29 Status <______>: ____________ N dd-mmm-yyyy hh:mm __________ 30* Diagnosis <______>: ____________ N dd-mmm-yyyy hh:mm __________ 31CMD> _______ RECEIVED NOTIFICATION --------------------- The following two layouts describe the data required to be displayed at the Service Operation. Call Information Notify 14 **THIS NOTIFY IS FOR INFORMATIONAL PURPOSES ONLY 1 Call Logged: dd-mmm-yy at hh:mm:ss 2 RDC Log No:......... System Type:............. Serial Number:............. 5 Company Name:............................ 6 Address:............................ 7 ............................ 8 ............................ Postcode:........ 4 Contact Name:......................... Contact Phone:............... 9 Cost Centre :... Alt CC1:... Alt CC2:... 10 Service Location :............... 13 Asssigned Engineer:............... 15 Engineer Reqd (Yes/No):. When:....................................... 16 Service Operation Action:.............................................. 17 Failing Device:........ Unit Number:.......... Serial Number:.......... 22 Trouble Statement (TS:)................................................ 23 ....................................................................... 24 ....................................................................... 20 Skill Required (ES:).................................... 21 Parts Required (PR:).................................... 19 Customer Impact (CI:).... Reason:...................................... 25 Most Probable Cause:.................................... 26 Frequency/Time of Failure:.................................... 27 Other Possible Causes:.................................... 32 Previous History: 33 dd-mmm-yy RDC log number Problem Summary 34 -----------+--------------+------------------------------------------ 35 ..-...-.. ......... ........................................ 36 " " " " " " " " " " " " 37 " " " " " " " " " " " " 38 Call passsed from Diagnosis at dd-mmm-yy hh:mm:ss Call Closure Notify 14 * DIAGNOSIS COMPLETE. CALL TO BE LOGGED *** 1 Call Logged: dd-mmm-yy at hh:mm:ss 2 RDC Log No:......... System Type:............. Serial Number:............. 5 Company Name:............................ 6 Address:............................ 7 ............................ 8 ............................ Postcode:........ 4 Contact Name:......................... Contact Phone:............... 9 Cost Centre :... Alt CC1:... Alt CC2:... 10 Service Location :............... 13 Asssigned Engineer:............... 15 Engineer Reqd (Yes/No):. When:....................................... 16 Service Operation Action:.............................................. 17 Failing Device:........ Unit Number:.......... Serial Number:.......... 22 Trouble Statement (TS:)................................................ 23 ....................................................................... 24 ....................................................................... 20 Skill Required (ES:).................................... 21 Parts Required (PR:).................................... 19 Customer Impact (CI:).... Reason:...................................... 25 Most Probable Cause:.................................... 26 Frequency/Time of Failure:.................................... 27 Other Possible Causes:.................................... 32 Previous History: 33 dd-mmm-yy RDC log number Problem Summary 34 -----------+--------------+------------------------------------------ 35 ..-...-.. ......... ........................................ 36 " " " " " " " " " " " " 37 " " " " " " " " " " " " 38 Call passsed from Diagnosis at dd-mmm-yy hh:mm:ss LINE NUMBER DESCRIPTION ----------------------- The following information gives further explanation of the lines described in the RSDS notify . Line: 1 Call Logged: dd-mmm-yy at hh:mm:ss This line should accurately display the time the call was logged with the response group. Currently, in the existing Notify screen this field has the name "Time:" although no day or date is specified. Line: 2 RDC Log No:......... System Type:............. Serial Number............. This line is made up from three existing fields. RDC log no. comes from the "Log Num" field. System type comes from the "CPU type" field and Serial Number comes from the "System ID" field. Line: 3 Branch Log no:......... Call Type:... These fields remain unchanged from the existing RSDS notify screen. Line: 4 Contact Name:......................... Contact Phone:............... These fields remain unchanged from the existing RSDS notify screen. Line: 5 Company Name:.............................. This line comes from the "Company" field in the existing notify screen. Line: 6 Address: This field is currently not used on the existing notify screen. The field should accurately display the full address relevant to the Company name. Lines 7 and 8 are reserved for this also, Line 8 has the added provision of Post code. ( NB: Address information used to be supplied in the previous version of RSDS.) Line: 7 see Line: 6 Address: Line: 8 see Line: 6 Address: Line: 9 Cost Centre: ... Alt CC1:... Alt CC2:... This line is made up from the following existing fields. Cost Centre is derived from the "Serv CC:" field. Alt CC1 and Alt CC2 remain unchanged from their use in the existing notify screen. Line: 10 Service Location This line is new. It identifies the town that the Service Operation resides, i.e. Basingstoke, London, Warrington etc. This info could be derived for the Cost Centre field. Line: 11 Service Phone (Day):................ (Night):................ This line relates to fields used in the existing notify screen. Service Phone replaces the text "Br Phone" in the existing notify screen. Line: 12 Service DTN (Day):................ (Night):................ Service DTN replaces the text "BR DTN" in the existing notify screen. Line: 13 Assigned Engineer: .................. This line remains unchanged from the existing notify screen. Line: 14 Call to be Logged or Info only (Log/Info):.... This line is new. This line will be completed by the diagnosis engineer. The response can either be "Log" or "Info". This line will appear differently when recieved at the Service Operation. The purpose of this line is to inform the Service Operation whether the Diagnosis is complete, or whether it is for informational purposes only.When recieved at the Service Location the first line of the Notify will clearly state whether the Notify is giving Diagnosis or Status Information. Line: 15 Engineer required (Yes/NO):. When:....................................... This line remains unchanged from the existing notify screen. Line: 16 Service Operation Action This line replaces the "Branch Action" field. Its meaning remains unchanged. Line: 17 Failing device:........ Unit Number:..........Serial number.......... This line is changed from the existing Notify screen. Currently this field has the format "Fail Device: sys - Is Not: ". The new line has three fields to be completed by the diagnosis engineer. Line: 18 Problem Summary This line remains unchanged from the existing notify screen. It is also used as a history field, see line 31. Line: 19 Customer Impact (CI:).... Reason:...................................... This line is new. Its purpose is to allow the Diagnosis engineer to provide the level of Customer impact, (High,Med,Low) and the reason why this is so. Line: 20 Skill Required (ES:).................................... This line is new. Its purpose is to allow the Diagnosis engineer to provide the Technical skill level of the Engineer required to attend to the Call. Line: 21 Parts Required (PR:).................................... This line is new. Its purpose is to allow the Diagnosis engineer to provide Part numbers or the type of Spares kit Required to remedy the fault. Line: 22 Trouble Statement (TS:)................................................ This field replaces the "Technical Findings" field currently in use. Its purpose is to allow for accurate trouble statement information to be entered. Line: 23 See Line: 22 Line: 24 See Line: 22 Line: 25 Most Probable Cause. This line remains unchanged from the existing notify screen. Line: 26 Frequency/Time of Failure: This line remains unchanged from the existing notify screen. Line: 27 Other Possible Causes This line remains unchanged from the existing notify screen. Line: 28 Notification Method phone contct snd? Data time Notifier This line and functionality remain unchanged. Line: 29 Status <______> _____________ N dd-mmm-yy hh:mm __________ This line and functionality remain unchanged. Line: 30 Diagnosis <______> _____________ N dd-mmm-yy hh:mm __________ This line and functionality remain unchanged. Line: 31 CMD> This line and functionality remain unchanged. Lines 32-37 Previous History These lines are changed from the existing Notify received by the Service Location. The new Notify will not only include up to three previous calls identified by the Problem Summary,(current situation), but will also list the date the call was logged together with the RSDS log number. Line 38 Call Passed from Diagnosis at dd-mmm-yy hh:mm:ss This line is new. It signals the end of the notify text and specifys the time the call was handed over from the CSC to the Service Location. Reference --------- An example of the current RSDS notify received at the branch is included here for reference purposes. %%%%%%%%%% DIGITAL DIAGNOSTIC CENTER 30-JUN-1989 12:58 %%%%%%%%%% Diagnosis Notification, sent by: WIBREW Log Num : R64826 Serv CC: 7A3 Alt CC1: Alt CC2: Branch Log : System ID: 00366 CPU Type: 1170 Link Log Num : R64826 Call Type: CM Maint Serv: Time: 11:39 Contact Name : PHILIP GRANT Contact Phone : 44-325-469131X201 Company : FARMWAYS City: DARLINGTON Br Phone(Day): 44-532-588154X2220 (Night): 44-256-57133 Br DTN (DAY) : 7845-2220 (Night): Passed to : Assigned Engineer: WIBREW Prob Summary: CPU CACHE and RA81 DU0 Engineer Reqd (Y/N/?): Y When : ASAP Branch Action: Please vcall cust with eta Fail Device : CPU - Is Not: Frequency/Time of Failure: during the night Technical Findings: CI: BIG, TS: system crash and cache dissabled on reboot suspect M8143/M8144 CPU, also T4 and resrv inst traps, Ra81 Du0 went offline and CMD timouts, also looks like some corrupt files on disk Probable Cause: 11/70 cpu problem Other Causes: Previous History: LA36 SN:WFD7536 NOT WORKING RM03 DR0 & DR1 BOTH SHOWING 1 ERROR
44.6	some further thoughts	KERNEL::WIBREW		`Mon Jul 03 1989 23:19`	11
	The DIAGNOSIS SCREEN should be of a size that it can be displayed on a VT screen in full, the proposed format looks like it may be a little too large to fit. It would make it a whole lot easier if the layout of customer and branch details were in the same format as the DDC>INFO screen, at the moment its all too easy to contact the branch when you really wanted to contact the customer. Steve W...
44.7	In time, all things are possible.	KERNEL::ADAMS	Venus on Remote Control	`Tue Jul 04 1989 10:32`	11
	A note on percieved timescales for RSDS developement. From ATS to the current (ATS based ) Notify = 2 years approx. Today + 2 years = Beyond the RSDS lifetime. i.e. By then, new call handling systems will be in place, hopefully combining RSDS/CFSU/CTSC/CHAMP/SMART into one universal system used throughout the company.

Conference kernel::csguk_systems

44.0. "**NEW RSDS NOTIFY SCREEN**" by KERNEL::ARCHER (Graham Archer Devices Diagnosis) Tue Jun 27 1989 11:53

44.0. "NEW RSDS NOTIFY SCREEN" by KERNEL::ARCHER (Graham Archer Devices Diagnosis) Tue Jun 27 1989 11:53