011

PRIMUS Processing Guide
4310 8497-011
(SUPERCEDES 3789 6750, A-SERIES NETWORKING PRIMUS PROCESSING GUIDE)
Effective:
8/28/2002
Approved for use by 8/30/2002 Ralph Farina (signature on file)

Date
Note: This document will be due for review & re-approval two years following the effective date above.
Paul Dowell Tredyffrin Net2 385-4187 Manager: J. Keeley Plant: Tredyffrin
UNISYS PROPRIETARY
This document, including the information contained herein is confidential and proprietary to Unisys Corporation, and shall not be used or reproduced for any purpose except with the written consent of Unisys Corporation.
Printed 08/30/2002 11:19 a8/p8 Only the on-line copy of this document is controlled. All printed copies are for reference only On-line document located:
PRIMUS PROCESSING GUIDE
43108497
Document Change Control History

Rev 010 010 010 011 State Draft 1 Draft 2 APPROVED Nature of Change Document initiated Corrections & additions Clarified More Information on page 12 Prepared By Edward Lawrence Edward Lawrence Edward Lawrence Paul Dowell Date 11/20/01 12/12/01 12/14/01 8/28/02
Please forward any comments / suggestions / revisions relating to this document to your support team representative.
Page ii of 7
Unisys Confidential
4310 8497
PRIMUS PROCESSING GUIDE Table of Contents
I. INTRODUCTION.............................................................................1 II. UCF FLOW - ROLE OVERVIEW ........................................................2 III. INITIATOR ..................................................................................3 A. Introduction ...................................................................................................3 B. Preparing to Enter a UCF...............................................................................3 C. Entering a UCF..............................................................................................3 Ref: RSS-260 Tracker Process & Procedures Guide Sect 7.4...............3 D. Delivering the UCF Materials.........................................................................3 IV. INBOUND TECHNICIAN.................................................................4 A. Introduction ...................................................................................................4 B. UCFs.............................................................................................................4 V. PRESCREENER..............................................................................5 A. Introduction ...................................................................................................5 B. Contacts:.......................................................................................................5 Ref: RSS-260 Tracker Process & Procedures Guide Sect 6..................5 C. UCFs:............................................................................................................5 Ref: RSS-260 Tracker Process & Procedures Guide Sect 7.7...............5 UCF Status [/Progress Code].....................................................................6
IN TRANSIT or MORE INFORMATION................................................................6
Ref: RSS-260 Tracker Process & Procedures Guide Sect 7.8.2............6 Ref: RSS-260 Tracker Process & Procedures Guide Sect 7.8.3............6
IN TRANSIT / 1B..................................................................................................7 PRESCREEN......................................................................................................7
VI. 0INBOUND COORDINATOR...........................................................9 A. Introduction ...................................................................................................9 B. UCFs.............................................................................................................9 Ref: RSS-260 Tracker Process & Procedures Guide Sect 7.5...............9 UCF Status/Progress Code........................................................................9
OPEN / 1..............................................................................................................9 MORE INFORMATION / 7C...............................................................................10
VII. PRODUCT SPECIALIST...............................................................11 A. Introduction .................................................................................................11 B. UCFs...........................................................................................................11 Ref: RSS-260 Tracker Process & Procedures Guide Sect 7.5.............11 Status/Progress Code..............................................................................11
OPEN / 1X.........................................................................................................11 MORE INFORMATION / 7C...............................................................................11 OPEN / 2............................................................................................................12
C. 00Contacts..................................................................................................15 VIII. 0OUTBOUND COORDINATOR.....................................................16 A. Introduction .................................................................................................16 B. Contacts......................................................................................................16 C. UCFs ..........................................................................................................16 Status/Progress Code..............................................................................16
IN TRANSIT / 1B................................................................................................16 OPEN / 2M.........................................................................................................16 ERROR / anything..............................................................................................17
Unisys Confidential
Page iii of 7

OPEN / 7C.........................................................................................................17 OPEN / 2L..........................................................................................................17 OPEN / 5............................................................................................................18 OPEN / 8I...........................................................................................................18 CHANGE HOLD / 5............................................................................................18 MORE INFORMATION / 7C...............................................................................19
43108497
Notification of Flash Release to Clients....................................................19 IX. 0ACCEPTOR...............................................................................20 A. Introduction .................................................................................................20 B. UCFs...........................................................................................................20 Progress Code.........................................................................................20
IN TRANSIT / 1B................................................................................................20 2M......................................................................................................................20 6, 6CA................................................................................................................21 7C......................................................................................................................21 8I........................................................................................................................21 9.........................................................................................................................21
X. 0OUTBOUND TECHNICIAN............................................................22 A. Introduction .................................................................................................22 B. Shipments To Customers Reporting Priority A Problems.............................22 C. Other Shipments.........................................................................................22 PROGRESS CODES..........................................................................24 PROGRESS CODES..........................................................................24 A. UCF PROCESS POLICY..................................................................26 A. UCF PROCESS POLICY..................................................................26 NIO Support Team Process note.....................................................................26 B. CONTACT RESPONSIVENESS & RATING.........................................28 B. CONTACT RESPONSIVENESS & RATING.........................................28 C. SYSGEN PROCESS.......................................................................30 C. SYSGEN PROCESS.......................................................................30 D. AS DESIGNED CLOSURES.............................................................32 D. AS DESIGNED CLOSURES.............................................................32 E. 0PLE-CHG CREATION/UPDATE......................................................34 E. 0PLE-CHG CREATION/UPDATE......................................................34 1. Trouble Report PLEs...................................................................................34 Product Section..............................................................................34 Description Section.........................................................................35 Workaround Section.......................................................................36 Resolution Section..........................................................................36 Resolution Blocks...........................................................................36 Root Cause Section.........................................................................37 2. PLE Content for Support/Mark Releases New Features...............................38 Header Section..............................................................................38 Description Section.........................................................................38 Resolution Block ...........................................................................38 Page iv of 7 Unisys Confidential
4310 8497
Root Cause Section.........................................................................39 For Support Releases (SSPs) Only....................................................39 3. Summary for Entering Patch Comments.....................................................40 Patch Documentation Guidelines......................................................40 Resolved Problem Notes..................................................................40 Documentation Change Notes..........................................................40 INTERNAL NOTES...........................................................................40 GENERAL GUIDELINES FOR PATCHMANAGER AND PRIMUS.................40 PATCHMANAGER INSTRUCTIONS.....................................................41 USER DOCUMENTATION..................................................................42 F. PLE ROOT CAUSE FIELDS..............................................................44 F. PLE ROOT CAUSE FIELDS..............................................................44 INTRODUCTION.............................................................................................44 DEFECT INJECTION POINT FIELD.................................................................44 Coding/Implementation..................................................................44 Definition......................................................................................44 Design..........................................................................................44 Feasibility......................................................................................45 Inspection.....................................................................................45 Other 45 Product Attribute test......................................................................45 Product Integration........................................................................45 Qualification..................................................................................45 Release.........................................................................................45 Requirements................................................................................45 Unit test........................................................................................46 Unknown.......................................................................................46 User Documentation.......................................................................46 DEFECT GROUP FIELD.................................................................................47 Continuation Regression.................................................................47 External Supplier............................................................................47 Feature.........................................................................................47 Feature Regression.........................................................................47 Latent...........................................................................................47 Imperfect Fix.................................................................................47 Other 47 Unknown.......................................................................................47 DEFECT DETECTION POINT FIELD...............................................................48 Code Review..................................................................................48 Coding/Implementation..................................................................48 Unisys Confidential Page v of 7
PRIMUS PROCESSING GUIDE Continuation Code Review...............................................................48 Continuation Coding.......................................................................48 Continuation Regression Testing......................................................48 Continuation Unit Testing................................................................48 Customer UCF................................................................................48 Definition Document Review............................................................48 Design Prototype............................................................................48 Design Review...............................................................................48 Feasibility Review...........................................................................48 Integration Testing.........................................................................48 Interoperability Testing...................................................................48 Internal User.................................................................................48 Other 49 Prototype Definition........................................................................49 Regression Testing.........................................................................49 Requirements Review.....................................................................49 System Testing..............................................................................49 Unit Testing...................................................................................49 Unknown.......................................................................................49 DEFECT INTRODUCED IN LEVEL FIELD.......................................................50 .<release cycle>................................................................50 Unknown.......................................................................................50 DEFECT TYPE FIELD....................................................................................51 Computational...............................................................................51 Compatibility.................................................................................51 Data Structure...............................................................................51 Documentation Problem..................................................................51 Integration Conflict........................................................................51 Interface.......................................................................................52 Logical..........................................................................................52 Other 52 Performance..................................................................................52 Unknown.......................................................................................52 CAUSE FACTOR FIELD..................................................................................53 Could Not Anticipate Error...............................................................53 Education......................................................................................53 Internally or Externally Generated Requirements Change...................53 Faulty Supplier...............................................................................53 Human Communications.................................................................53 Lack of Resources..........................................................................54 Page vi of 7 Unisys Confidential
43108497
4310 8497 Other 54
Lack of Tools.................................................................................54 Oversight .....................................................................................54 Process Inadequate........................................................................54 Process Not Followed......................................................................54 Transcription.................................................................................54 ROOT CAUSE COMMENTS FIELD.................................................................55 G. CONTACT HANDLING...................................................................56 G. CONTACT HANDLING...................................................................56 1. Entering a CONTACT..................................................................................56 2. Creating a CONTACT from a UCF...............................................................56 3. Replying to CONTACTs...............................................................................56 4. Closing a CONTACT...................................................................................57
Unisys Confidential
Page vii of 7
43108497
I.
INTRODUCTION This document is organized by role. Many different individuals may play a part in the processing of a UCF during its life cycle, such as the person who enters it (Initiator), the person who answers it (Product Specialist) or the person who reviews its response (Outbound Coordinator). There is a separate section for each role. Many individuals may perform more than one of these roles. This document assumes the use of Tracker 2.1 to access PRIMUS but does not provide detailed operating instructions. To get Tracker installed on your PC, follow the Tracker Installation instructions on the Tracker home page (http://epas1.rsvl.unisys.com/os1/txt/html-tr-welcome?pla=tra), or contact your Help Desk. To obtain copies of Tracker documents, click on the Documentation link on the Tracker home page For more information regarding Tracker please refer to: Tracker 2.1 User Guide (RSS-256) and the Tracker Help text. For detailed information regarding PRIMUS operations please refer to Tracker Process & Procedures Guide (RSS-260).
Notation "uuuuuuuu" refers to a PRIMUS UCF ID (an 8-digit identifier assigned by PRIMUS) (e.g. 16151413). "pppppppp" refers to a PRIMUS PLE number. "cccccccc" refers to a PRIMUS CONTACT ID.
FOR EMPHASIS All Personnel should acquire the Tracker Manuals noted above.
Unisys Confidential
Page 1 of 57
4310 8497
II.
UCF FLOW - ROLE OVERVIEW INITIATOR Identifies problem Collects supporting evidence Documents problem by creating UCF Forwards evidence to the UCF Coordinator INBOUND TECHNICIAN Receives materials addressed to the UCF Coordinator Validates the integrity of UCF materials received Documents receipt of UCF materials Delivers UCF materials to appropriate Pre-Screener PRE-SCREENER Opens UCF Determines adequacy of UCF materials Determines team ownership of UCF Delivers UCF and materials to appropriate Inbound-Coordinator INBOUND-COORDINATOR Verifies team ownership of UCF Assigns UCF to Specialist Delivers UCF and materials to assigned Specialist SPECIALIST Evaluates reported problem Diagnoses reported problem Documents technical details of reported problem Resolves reported problem Documents problem resolution Obtains review of problem resolution OUTBOUND-COORDINATOR Reviews, administratively, problem resolution Coordinates sysgens and releases ACCEPTOR Reviews problem resolution on customer's behalf OUTBOUND TECHNICIAN Sends resolution materials to customer
Page 2 of 57
Unisys Confidential
43108497
III.
A.
INITIATOR Introduction PRIMUS is used to report each problem encountered with a UNISYS product. In order to start the process to evaluate, analyze and correct the problem, a UCF is entered into the EPAS database. You can also initiate a CONTACT to ask a question about a product or UCF. CONTACTs are like electronic mail in PRIMUS. (See Appendix H.) B. Preparing to Enter a UCF The first step in initiating a UCF is to obtain the following information: o The name of the product and component, you are submitting the UCF against o The release-level of the product you are submitting the UCF against C. Entering a UCF
Ref: RSS-260 Tracker Process & Procedures Guide Sect 7.4
To enter a UCF from scratch: o Click File New Document o Select entry activity UCF. o Select the appropriate Product & release-level. o On the Product Info Tab check that the pre-filled fields are accurate and make the appropriate selection in the other fields (Note that required fields are shaded green). o On the Description Tab enter a brief Headline and a Description of the problem. (The first letter of major words in the headline should be uppercase) If material is being forwarded then select yes in the checkbox and itemize the materials in the Material textbox. o Review the fields on the Initiator Tab and verify the information for accuracy. If any information is incorrect either correct it temporarily for this UCF or permanently by updating your USER profile.
o Click File Close o Note the UCF number assigned by Primus

NOTE: PRIMUS queues the UCF to the product PVP INTERNAL-QUEUE userid, and sets the UCF STATUS field to either PRESCREEN (if to a local plant or no supporting materials), or IN-TRANSIT (if to another plant or supporting materials).
D.
Delivering the UCF Materials For UCF's written against Tredyffrin products, the initiator should take the following actions: o Identify the UCF by marking all supporting materials with the 8-digit UCF number and the UCF reference number (if any). o Deliver the materials to an Inbound Technician. For UCF's written against products in other facilities, the initiator should take the following actions: o Identify all supporting materials by marking with the 8-digit UCF number. o Determine how the material is to be transferred to the appropriate UCF coordinator. i.e. by transferring files electronically, or via mail.
Unisys Confidential
Page 3 of 57
4310 8497
IV.
A.
INBOUND TECHNICIAN Introduction The Inbound-Technician's primary responsibility is to document the receipt and integrity of UCF materials. Note that the Inbound Technician is not required to perform any PRIMUS activity other than printing copies of UCFs. B. UCFs For each Incoming UCF, the Inbound-Technician will: o Receive incoming materials addressed to the "UCF Coordinator". These materials may arrive via Mail, FedEx, UPS or via BNA or FTP to ECCSA. o Determine the 8-digit UCF number and the UCF Reference number. o Label all media with the 8-digit UCF number and UCF Reference number. o Print a copy of the UCF. o For media which is readable by an A-Series, do the following: Print a Tape Directory and attach to the printed UCF. Load all files to the ECCSA TRANSFER directory, and verify against those documented on the UCF. o Deliver the materials received, along with the printed UCF, to the appropriate PreScreener. o Record in the Inbound-Technicians' Log: Date Inbound-Technician UCF number and Reference Number Number and type of Media Name of the Pre-Screener (Refer to the link on the NIO Home page PRIMUS Responsibility List) Product Queue (Refer to the link on the NIO Home page PRIMUS Responsibility List)
Page 4 of 57
Unisys Confidential
43108497
V.
A.
PRESCREENER Introduction The PreScreener's responsibilities include checking the assigned Product Queue (a minimum of once per day) for incoming UCFs, examining each incoming UCF to determine which technical team should work on that problem, and routing each UCF to the appropriate Inbound Coordinator. In addition, PreScreeners must check the assigned Product Queue (a minimum of twice per day) for incoming CONTACTs, and ensure that they are replied to within 4 hours of receipt if the CONTACT is rated as Emergency or Down or 24 hours of receipt if the priority is Problem or Information. (Refer to Appendices C and H). Tracker provides a utility program (MONITOR) that watches for changes within a queue that meet specified criteria (for example, when a new UCF is submitted). When the criteria is met, Tracker Monitor notifies you via a pop-up message, E-mail, audio, or by running a specified program.
(Ref. RSS-256 Tracker User Guide, lesson 12).
B.
Contacts:
Ref: RSS-260 Tracker Process & Procedures Guide Sect 6
A list of CONTACTs for a specific User or Queue may be obtained by executing a Tracker Query (PRIMUS Command): Select LC = <Queue-ID> Status <> closed For tracking purposes, CONTACTs should always be kept in the assigned Product Queue. The next person to be alerted to the CONTACT should be determined via the following process: o If the CONTACT references a UCF, and the Internal Use field in the UCF is filled in, the CONTACT should be brought to the attention of that person. o Otherwise, if the CONTACT references a UCF and the Manager field in the UCF is filled in, the CONTACT should be brought to the attention of that manager. o Otherwise, the information received with the CONTACT should be used to determine which technical team should reply to it, and the CONTACT materials should be delivered to the appropriate Inbound Coordinator. C. UCFs:
A list of UCFs for a specific User or Queue may be obtained by entering a Tracker Query (PRIMUS Command): Select Responsibility = <Queue-ID> Status <> cl,rh For each incoming UCF, the PreScreener should: o Review the contents of the UCF to determine ownership. The information in the fields should only be modified, if changes are necessary to ensure proper handling of the UCF and after careful consideration of the customer's reaction. Type: RELEASED orDEVELOPMENT Description: Product: If the product is wrong, transfer the UCF to the correct product.
Ref. RSS-260 Tracker Process & Procedures Guide Sect 7.9.
Mark: Release: Support Release: The support release must be something that is currently in the field. If the product is not yet released then should be '00'.
(continued over)
Unisys Confidential
Page 5 of 57
PRIMUS PROCESSING GUIDE Component: System Release: Support: Valid Acceptor's Queue ID. Coordinator: PreScreener's assigned Product Queue ID.
4310 8497
In addition to the actions listed above, a PreScreener should take the following actions based upon the UCF's Status and in some cases the progress code. (Refer to Appendix A for Progress Codes). UCF Status [/Progress Code] IN TRANSIT or MORE INFORMATION Materials Received
Ref: RSS-260 Tracker Process & Procedures Guide Sect 7.8.2
If the information specified in the original UCF and/or requested in order to support the original UCF is received, then the materials should be examined in enough detail to determine whether the material is adequate and which technical team should work on the UCF
Materials Adequate
If the materials are adequate for further processing then the PreScreener should run the Process UCF Materials activity to describe the materials received, and update the following fields: Progress Code: Manager: Responsibility:
Materials Inadequate
1 Appropriate Inbound Coordinator's Queue ID. Appropriate Inbound Coordinator's Queue ID.
All associated materials should be delivered to the appropriate Inbound Coordinator. If the materials are not adequate for further processing then the PreScreener should run the Process UCF Materials activity to describe the materials received, and run the activity Request More Information to describe what else is needed. Then check/update the following fields: Responsibility: Appropriate Outbound Coordinator's Queue ID. Internal Use: PreScreeners Product Queue ID Send MORE INFORMATION Request: Yes Active Response: Description of the requested materials. Progress Code: 7C Internal Use: Assigned Product Queue ID.
(The Acceptor will place the UCF back into the Queue ID found in the UCFs Internal Use field after the MORE INFORMATION request has been sent to the UCF initiator). Materials Not Received If the PreScreener does not have the materials, they should first ensure that the materials were not electronically transferred, and upon ensuring this the PreScreener should update the following fields: Progress Code: Materials Not Needed
Ref: RSS-260 Tracker Process & Procedures Guide Sect 7.8.3
1B
If no additional information is necessary, update the following fields: Material Status: Progress-Code: Responsibility: Not Needed. 2 Appropriate Inbound Coordinators Queue ID.
Page 6 of 57
Unisys Confidential
43108497 IN TRANSIT / 1B
If the UCF is not up for review (Screen Status is not REVIEW), the PreScreener should check for incoming materials on a regular basis. (PRIMUS will automatically change an IT/MORE INFORMATION UCF's Screen Status to REVIEW when the timeout period, which defaults to 45 days, expires.) If the UCF is up for review (Screen Status is REVIEW) update the following fields: Responsibility: PRESCREEN Some UCFs are received with a Status of PRESCREEN and others may go PRESCREEN after Materials have been received. In either case update the following field: Status: OPEN. Outbound Coordinator's Queue ID.
Unisys Confidential
Page 7 of 57
4310 8497
Page 8 of 57
Unisys Confidential
43108497
VI.
A.
0INBOUND COORDINATOR Introduction The Inbound Coordinator's responsibilities include checking their queue everyday for incoming UCFs, examining each UCF to ensure that it is the responsibility of their technical team, determining which specialist should work on the UCF (based on priorities and backlog), and routing each UCF to the appropriate specialist. Tracker provides a utility program (MONITOR) that watches for changes within a queue that meet specified criteria (for example, when a new UCF is submitted). When the criteria is met, Tracker Monitor notifies you via a pop-up message, E-mail, audio, or by running a specified program.
(Ref. RSS-256 Tracker User Guide, lesson 12)
The Inbound Coordinator should also keep track of how many UCFs the technical team is working on at any time. This includes reporting status of the team as a whole on the incoming UCF rate, number of UCFs open, backlog and number of UCFs closed during a given reporting period. B. UCFs
Each day the Inbound Coordinator should check their queue(s) for incoming UCFs. The actions taken depend upon the Status/Progress Code of the UCF. Refer to Appendix A for allowable Progress Codes. UCF Status/Progress Code OPEN / 1 First, the Inbound Coordinator needs to ensure that this UCF is for their team. This is done by reading the description for the UCF and looking at the accompanying materials. Accepting Team Ownership For each UCF that is deemed to be within the team's responsibility, the Inbound Coordinator should first verify the following fields and update if necessary. Class: Product: Type: Mark : Release: Support Release: Description: Verify for the correct group: Software or Documentation If the product name is incorrect, transfer the UCF to the correct product and check that the Component is correct
(Ref. RSS-260 Tracker Process & Procedures Guide Sect 7.9).
Released or Development. Must match materials supplied Must match materials supplied Correct support release for given level Correct obvious typos or errors. Do not delete the customer's text but if the description does not actually include the real problem, add this information after the customer's text. If the Headline is wrong or does not include the halt code, update the UCF. Remember that other people may be viewing this UCF later looking for duplicate problems so if the description is wrong or misleading, it is to our advantage to correct it.
Unisys Confidential
Page 9 of 57
4310 8497
Next, the Inbound Coordinator should determine if the materials supplied are adequate enough to work on the problem.
Materials Adequate
o Verify Materials are all marked on the UCF o Determine the Specialist to work on UCF o Verify and/or update the following fields: Manager: Responsibility: Internal Use: Progress Code: Check to make sure this field is set to Managers id. Specialist assigned to work on UCF. Specialist assigned to work on UCF. 1X
Give accompanying materials to the specialist assigned

Materials Inadequate
o Coordinate with the PreScreener and run the Process UCF Materials and Request More Information activities. Then check/update the following: Responsibility: Team's Outbound coordinator Send MORE INFORMATION Request: Yes Active Response: Description of the materials needed Progress Code: 7C Internal Use: Inbound Coordinator's Id Rejecting Team Ownership o Determine correct inbound coordinator using information given, talk to them to ensure team acceptance. o Deliver materials to correct inbound coordinator. o Queue UCF to correct inbound coordinator. MORE INFORMATION / 7C Materials Received If materials requested were received; o Verify and mark the materials. o Check/update the following fields: Material Status: Material: Progress-Code: Materials Not Needed If no additional information is necessary, update the following fields: Material Status: Progress-Code: Materials Not Received If the UCF is up for review (Screen Status is REV), the UCF should be queued to team's outbound coordinator. A MORE INFORMATION Timeout Response is automatically generated by PRIMUS when a UCF that is on MORE INFORMATION times out. The default value for this timeout is 30 days. It may be extended by notifying your Outbound Coordinator and request that they extend the timeout deadline. Page 10 of 57 Unisys Confidential Not Needed 2 Arrived A description of materials received. 2
PRIMUS will automatically update Status to OPEN (refer to Open section for next steps).
PRIMUS will automatically update Status to OPEN (refer to Open section for next steps).
43108497
VII.
A.
PRODUCT SPECIALIST Introduction The Product Specialist's primary responsibility is to determine a response to a UCF. This process includes the evaluation, diagnosis and resolution of the reported problem and recording each of these steps in PRIMUS. B. UCFs
Each day the Specialist should check their queue for incoming UCFs. The actions taken depend upon the Status/Progress code of the UCF. Refer to Appendix A for allowable Progress Codes. Tracker provides a utility program (MONITOR) that watches for changes within a queue that meet specified criteria (for example, when a new UCF is submitted). When the criteria is met, Tracker Monitor notifies you via a pop-up message, E-mail, audio, or by running a specified program.
Status/Progress Code OPEN / 1X When a new UCF is received, (Reminder- Check the materials received and internal text field for additional information) verify and update if necessary the following fields, if later investigation of the UCF warrants a change in any of the fields (e.g. the product component or description), please be sure to update this information in PRIMUS. Description: Correct obvious typos or errors. Do not delete the customer's text but if the description does not actually include the real problem, add this information after the customer's text. (Remember that other people may be looking at this UCF later looking for duplicate problems so if the description is wrong or misleading, it is to our advantage to correct it). Internal-Use: Your Queue Id Status: Open Progress-Code: 2 MORE INFORMATION / 7C Materials Received If materials requested were received; o Verify and label the materials. o Update the following fields: Material Status: Material: Progress-Code: Materials Not Needed If no additional information is necessary, update the following fields: Material Status: Progress-Code: Not Needed 1X Arrived Include a description of materials received. 1X
PRIMUS will automatically update Status to OPEN (refer to OP/1X section for next steps).
PRIMUS will automatically update Status to OPEN (refer to OP/1X section for next steps).
Unisys Confidential
Page 11 of 57
PRIMUS PROCESSING GUIDE Materials Not Received
4310 8497
If the UCF is up for review (Screen Status is REV), the UCF should be queued to team's outbound coordinator. A MORE INFORMATION Timeout Response is automatically generated by PRIMUS when a UCF that is on MORE INFORMATION times out. The default value for this timeout is 30 days. It may be extended by requesting your Outbound Coordinator to extend the timeout deadline. OPEN / 2 As work on the UCF proceeds, the actions taken are dependent on the status of the investigation. More Information Required (Materials Inadequate) The first step in processing the UCF is to determine if the information presented is adequate to determine the problem. If more information is required then run the Tracker Activity Request More Information, and fill in the following fields: Responsibility: Send-MI-Request: Active-Response: Progress-Code: Outbound Coordinator Queue-ID Yes Description of the needed materials/information 7C (this automatically changes when MI is accepted)
The Outbound Coordinator will accept the MORE INFORMATION request response and queue the UCF back to the specialist. UCF Does not require a Patch/Fix Update the following fields: Responsibility: Outbound Coordinator's Queue Id Closure Code: Select appropriate value. If you are considering using the As Designed Closure Code, please refer to Appendix E. Progress Code: 2L Active Response: Enter text to explain resolution of the problem Duplicate Problem
Same Customer
If this problem has already been reported by this customer, update the following fields: Answer: Closure-Code: Progress-Code: Responsibility: "This UCF is a duplicate of "uuuuuuuu. DU 8I Outbound Coordinator's Q-ID.
New Customer i) Resolved Problem
If the problem has been already corrected, but has not been reported by this customer before, enter the following fields: UCF-To-PLE: Progress-Code: Responsibility: PLE number of the resolution for the original UCF. 5 Outbound Coordinator
Check that the PLE's Resolution Block includes the level of this UCF. If not change the PLE. Locate the corresponding resolution block Resolution-for-Level: Product Level the UCF was written against ii) Unresolved Problem When the UCF is a duplicate report of a problem that is already being investigated, do the following: o If you are not the specialist presently working on this problem, determine which specialist "owns" the problem, contact them and ensure acceptance; then update the following: Internal-Use: Queue Id of the handling specialist Page 12 of 57 Unisys Confidential
43108497 Responsibility: UCF-to-PLE:
PRIMUS PROCESSING GUIDE Queue Id of the handling specialist PLE number
o If you are the specialist currently working on the problem, change the following o Check that the PLE's Resolution Block includes the level of this UCF. If not: Update the following fields in the PLE. Locate the corresponding resolution block Resolution-for-Level : written against. UCF is really a New Feature Suggestion There are some cases when a UCF is received which is actually a New Feature Suggestion. UCF Trouble Reports may not be reclassified as a New Feature Suggestion (NFS) without the agreement of the submitter. Agreement on reclassification must occur as a result of communication between engineering and the support center, who will consult with the initiator and respond to engineering (According to Unisys Policy). Once it has been agreed to make the UCF Trouble Report into a New Feature Suggestion the following steps should be taken: Notify your NFS Coordinator of the change (only a privileged user can make the change). You can have them change it or you can change it yourself (if you are privileged) by the following: o Update the following fields: Form: Active Response: e.g. a contact #. Documentation Incorrect Talk to the PI team Inbound Coordinator first to get acceptance, then deliver the materials to them. o Update the UCF and change the following fields: Class: Responsibility: Component: Documentation PI Team Inbound Coordinator The Form Number of the manual to be updated, if known. FS Enter who you talked to and any references of the conversation,
Product level the duplicate UCF was
New Problem: Creating a new PLE A PLE should be created as soon as it is determined that the UCF is reporting a legitimate problem that will require a change. Documentation-related UCFs do NOT require that a new PLE be created for each reported problem, a single PLE is used per document. If it is later found that the problem is already defined in another PLE or that no change will be necessary, the PLE may be deleted (See your Outbound Coordinator). Refer to Appendix F for more complete description of the PLE, then; o Create the PLE . o Check/update the following fields: Component: A valid component Customer Technical Bulletin: If the PLE addresses a critical problem where the use of the product is greatly impaired, or the integrity of the customers data is greatly compromised, this field is given a value of ALERT. Headline: A concise description of the problem Keyword: Enter any word, which has a strong relationship to the problem. This field is used by both the field and customers to find information on previously reported problems. If the CP2000 halted, enter 'halt <n>' as a keyword. Max size of keyword is 14 characters. Symptoms: Description of how the problem manifested itself, what brought about the failure, and any preceding events that are applicable. (Do not just copy the UCF). Internal Conditions: Provide all pertinent information that could help someone else diagnose another occurrence of the problem. This is important to help both other Unisys Confidential Page 13 of 57
4310 8497
specialists in identifying similar problems and customers to determine if they have the same problem already submitted. Technical Explanation: Describe in detail, including variable and element names as appropriate, the problem that occurred and how it has been resolved. o Create a separate resolution block area for each level currently in existence (e.g. 46, 47 & 48, etc.). Update the following fields in each resolution block: Resolution for Level: Level the UCF was written against. If UCF not written against a specific release (i.e. written against 46 and filling in 48 resolution block, then enter last support release of that product, e.g. 048.00) Resolution Status: UA.
Determine a Workaround
The next step that a specialist should take is to determine if a workaround exists. It is very important that if there is any possible workaround it be documented. This will increase our responsiveness both to our customers and for our reports. o Enter the following: Workaround-Available: YES Workaround-Type: Set the type field to PRO (procedure), IF (integrated fix) or NIF (nonintegrated fix) Workaround-Description: Enter text for the workaround o Open the associated UCF(s) and change the following: Progress-Code: Responsibility: 2M Outbound Coordinator
UCF will be queued back to the product specialist as soon as the workaround response has been sent.
Problem Resolution (Updating PLE)
Once the specialist has determined the problem, the following steps are to be taken: o Make Patch and assure correctness. o Comment Patch Note1: Make sure that the component entered in the patch comment is the same as the component on the PLE and the UCF. Note2: If this patch is for a UCF, the comment type must be PNOTE and you must enter information in the 'User-Oriented Description'. o Retrofit patch to all applicable levels. o Update the PLE and change the following fields in each Resolution Part: Resolution-Status: FIX COMPLETED. Closure-Code: SOFTWARE DEFECT PLE to CHG: Include all PRI#s (e.g. PRI-8512345) associated with this UCF and this Resolution for level. (Do NOT include PRI#s for design documents, or sysgen-specific softwares as these are not PRIMUS Visible and will cause the UCF to remain OPEN). Fixed in Release: SR Level. Must be higher than the support level the UCF was written against. o Update the Resolution Comments (Resolution Tab): List the Support level containing the fix and the date it is expected to ship. o Make sure that the component on the patch comment matches the Component field in the PLE o Update the Root Cause section of the PLE. (Refer to Appendix G). Update the following fields: Defect Injection Point: Indicates when the defect was injected. Defect Detection Point: Indicates where the defect was detected. Defect Introduced in Level: Release level in which the problem was originally Page 14 of 57 Unisys Confidential
43108497 introduced. Defect Group: Defect Type: Cause Factor: Progress-code: o Have patch reviewed Responsibility:
PRIMUS PROCESSING GUIDE The defect category. Describes the type of error Why the defect occurred. 5 Outbound Coordinator
o Edit the UCF and update the following fields:
Note: The UCF Closure Code will be inherited from the PLE, thus no need to update this field. C. 00Contacts For an overview of CONTACT handling see Appendix H. A product specialist is expected to answer CONTACTs within either 4 or 24 hours! (Ref: Appendix C) Keep in mind that Customers may see the reply entered, so be sure that the text of the reply is appropriate and does not include company confidential information. If unsure, have your Outbound Coordinator check the reply (do not queue the CONTACT). o Answer the CONTACT and update the following fields: Log-Name: Log-Responsibility: Log-Action: Log-Disposition: The full name of the person answering the CONTACT. The PRIMUS-ID of the person answering the CONTACT. The text of the reply Enter PASSED when you have finished entering the reply. The reply will only be sent when the value is entered. Enter the time (in minutes) spent on replying to this contact. The code used most often is TQ (Technical Question).
Log Time Spent: Log-Reply-Code:
Unisys Confidential
Page 15 of 57
4310 8497
VIII.
A.
0OUTBOUND COORDINATOR Introduction The Outbound Coordinator's primary function is to ensure that the information in PRIMUS documents (UCF, PLE, CONTACT, etc.) provided by the Product Specialists, is accurate, pertinent and polite. You must be a privileged user of the Product in order to perform this function. B. Contacts The Outbound Coordinator should review CONTACTs when requested by a Specialist. Only those CONTACTs which the Specialist requests a second viewpoint need be reviewed. If the CONTACT content is satisfactory, then the Outbound Coordinator may change the Log Disposition to PASSED. C. UCFs UCFs are queued to the Outbound Coordinator when Specialists have completed their updates on the appropriate PRIMUS documents. When the Outbound Coordinator reviews the UCF, they are to make sure that the responses will be acceptable to the customer. Depending on the status and progress code (refer to Appendix A for allowable Progress Codes) the Outbound Coordinator performs the following functions. In each case, the Outbound Coordinator should not queue the UCF to the Acceptor until it is ready for review (Scr Sta = REVIEW). The Outbound Coordinator should monitor the UCFs to make sure that there is not something wrong; this means being attentive to what is in their queue and what state it is in. Status/Progress Code IN TRANSIT / 1B The materials for this UCF were never received. It may be a good idea to send a CONTACT, e-mail or make a phone call before closing this UCF to ensure that materials were not sent to the wrong location. If the UCF is eligible for closure the Outbound Coordinator should update the following field: o Responsibility: If the Support field is 'DEVMME' then the outbound coordinator also does the accepting and this field should not be updated. If the support field has another Queue ID in it, then set the Responsibility field to that Queue ID.
OPEN / 2M This status/progress code shows that a work around has been made available by the Specialist and needs to be reviewed by the Outbound Coordinator. The Outbound Coordinator should: o Review the PLE. o Verify the following fields: WorkAround Available: Yes Review the WorkAround section of the PLE and make sure that the work-around is acceptable (i.e. is reasonable for the customer to do, and is written directly to the customer).
(continued over)
Page 16 of 57
Unisys Confidential
43108497
WorkAround Acceptable o Update the following UCF fields: Responsibility: If the Support field is 'DEVMME' then the outbound coordinator also does the accepting and this field should not be updated. If the support field has another queue id in it, then set the Responsibility field to that queue id. WorkAround NOT Acceptable If there are minor changes required (e.g. spelling, etc) the outbound coordinator should make them. Otherwise, the outbound coordinator should queue the UCF back to the specialist named in the Internal Use field (Responsibility = Queue Id in Internal Use field) and explain to the specialist what is wrong. ERROR / anything This status could be associated with any progress code. If you see this status on a UCF carefully review the UCF to determine what the problem is. OPEN / 7C This status/progress code designates that the Specialist wishes to request more information (MI) for the problem. The Outbound Coordinator should review the UCF Materials field to make sure the requested information is appropriate. Request Appropriate o Update the following UCF fields: Responsibility: If the Support field is 'DEVMME' then the outbound coordinator also does the accepting and this field should not be updated. If the support field has another queue id in it, then set the Responsibility field to that queue id.
Request NOT Appropriate If there are minor changes required (e.g. spelling, etc) the outbound coordinator should make them. Otherwise, the outbound coordinator should queue the UCF back to the specialist named in the Internal Use field (RES=Queue Id in Internal Use field) and explain to the specialist what is wrong. OPEN / 2L This status/progress code designates that the Specialist has provided a no-fix closure for the problem reported on this UCF. The Outbound Coordinator should first review the answer field of the UCF to make sure the response is appropriate, Answer Appropriate o Review/update the following UCF fields: Closure-Code: Must be filled in with a proper value. Progress Code: 9 Responsibility: If the Support field is 'DEVMME' then the outbound coordinator also does the accepting and this field should not be updated. If the support field has another queue id in it, then set the Responsibility field to that queue id. Answer NOT Appropriate If there are minor changes required (e.g. spelling, etc) the outbound coordinator should make them. Otherwise, the outbound coordinator should queue the UCF back to the specialist named in the Internal Use field (RES=Queue Id in Internal Use field) and talk to the specialist as to why it is being requeued.
Unisys Confidential
Page 17 of 57
PRIMUS PROCESSING GUIDE OPEN / 5
4310 8497
This status/progress code should rarely be seen on the Outbound Coordinators queue. This should only be seen for 1 day and then the status should change to CH. If the status remains OPEN the Outbound Coordinator should: o Open the PLE) o Review (and update if necessary) the following fields: Resolution Status: Make sure it is FC or FT and nothing else. (It should not be set to FD). OPEN / 8I This status/progress code designates that the UCF is a duplicate of another UCF submitted by the same customer. o Review the following fields: Answer Should contain what UCF this is a duplicate of. If the Support field is 'DEVMME' then the outbound coordinator also does the accepting and this field should not be updated. If the support field has another queue id in it, then set the Responsibility field to that queue id. o Update the following fields: Responsibility (RES)
CHANGE HOLD / 5 This status/progress code designates that the Specialist has made a patch to fix the UCF problem. The Outbound Coordinator should: o Open the PLE and verify and/or update the following fields: Internal Text Flash level (i.e.what level the patch was applied or what flash level the patch is in). If the patch is not applied, the Outbound Coordinator must fill this field in once the patch becomes applied. If the flash level is not given or not known, the Outbound Coordinator can: Review the CHGs and look at the sysnum field to determine in what flash level the patch is contained. If the sysnum field is of the form 47.189.XXXX (XXXX is any four digits) then 47.189 is the valid flash level for this patch.
Note: There may be multiple Resolution Parts (a.k.a. Resolution Blocks) in a PLE, each part may contain multiple CHGs (PRIs). The Release level for each PRI listed in PLE to CHG must match the Resolution for level for the Resolution Part.
PLE-to-Chg: The PRI numbers listed here should be validated in Patch Manager to ensure that they are at least Ready/Reviewed. Resolution Status: FIX COMPLETED or FIX IN TESTING(set by PRIMUS) Fixed In Release: The support release in which this problem is resolved in the form PRODUCT-Mark level.Support release level. Resolution Comments (Resolution Tab): The support release(s) in which this problem is resolved along with the availability of these support releases (e.g. This patch is in 48.02 which will be available 2nd qtr 2003). o Return to the UCF and update the following fields: Section: Outbound Coordinator PRIMUS ID Progress Code: 6 ( 6CA if flash release has passed system testing) Special Release Level: Flash release level (can be taken from the internal text of the PLE) Responsibility: If the Support field is 'DEVMME' then the outbound coordinator also does the accepting and this field should not be updated. If the support field has another queue id in it, then set the Responsibility field to that queue id.
Sometimes the Outbound Coordinator needs to force a UCF to close. Typically, this is done for 'B' Priority UCFs because the closure for the UCF just means that the response is scheduled to go into Page 18 of 57 Unisys Confidential
43108497
the next support release, the patch does not have to be applied. To force a UCF to close, the Outbound Coordinator needs to make all the PRI numbers in the PLE get harvested up to Primus. This is done by changing the HarvestWhen field to approved in Patch Manager. The commands are: ChangePatchAttributes <PRI-xxxxxxx TO HARVESTWHEN=APPROVED> Note: Use care when doing this. You need to ensure the patch is included in the next gen. MORE INFORMATION / 7C This means that more information has been requested for the UCF. No action is necessary until Screen Status is REVIEW which means that the MORE INFORMATION request has timed out. If it is okay for the UCF to timeout, then queue it to the acceptor (Responsibility=<Qid in support field> ). Otherwise, extend the UCF timeout period (see Tracker help text Extending the timeout).
Notification of Flash Release to Clients After receiving notification from Test Services that a Flash Release has passed testing, the Outbound Coordinator should: o Determine the list of customers to receive the Flash. This can be accomplished by creating a Queue (Ref. RSS-256 Tracker User Guide, lesson 5 ) or by using the Query Browser. In either case the Query will be: S PRO=<product-name> PRI=A SRL=<Flash-Release> o Document the availability of the Flash Release in PRIMUS by changing the progress code of the UCF(s) to 6CA o Insert canned text: "The correction for the problem reported in this UCF is now available via the Web Unisys Support page http://www.support.unisys.com. Please download the latest flash by signing on to the Unisys Support page, select LX / NX / A Series, then Fixes. Read the information regarding downloading correction and using UNWRAP, select the release level for the flash needed and follow the instructions provided. If Flash media is needed, please contact your local Support Center for assistance."
o Document the shipment of the Flash Release in PRIMUS by running the Activity Send UCF Change Notice: Active Response: "Notification of Flash Release xx.xxx sent to customer <date>. o If the Support field contains the user-id of the person who can accept the UCF-Notice, change the Responsibility field to match. o Advise the Outbound Technician of this Flash release and coordinate any subsequent requests for Flash Media.
Unisys Confidential
Page 19 of 57
4310 8497
IX.
A.
0ACCEPTOR Introduction The acceptor's responsibilities involve looking at the UCF from the Customer's Point of view. This means validating the fix, where possible, reviewing the response that goes to the customer, and accepting the response (or rejecting if necessary). You must be a privileged user of this product in order to perform this function. At any point, the Acceptor may cancel the response by selecting Scr Sta = CANCELED. However, in doing this, many fields will be reset to blanks (mostly the ones which caused the response to happen). Thus you should think carefully before doing this. For more information, see your group's Primus Rep (Guru). Typically, RETRY should be used instead of CANCEL. RETRY will not detach the attached PLEs, CHGs, etc. B. UCFs Once a day, the Acceptor should check their queue for any UCFs up for review. Tracker provides a utility program (MONITOR) that watches for changes within a queue that meet specified criteria. When the criteria is met, Tracker Monitor notifies you via a pop-up message, E-mail, audio, or by running a specified program.
The actions to take when reviewing each UCF depend on the Progress Code as follows: (refer to Appendix A for Progress Codes) Progress Code IN TRANSIT / 1B This means the UCF was never opened due to the materials never having arrived. 2M This represents that the specialist has determined a workaround for the customer's problem. The Acceptor should review the following fields: o Workaround section: Workaround Acceptable If the workaround is acceptable, the following fields should be updated: o Screen Status: o Responsibility: ACCEPTED Qid in the Internal Use field of the UCF Review for correctness and customer appropriateness.
Workaround NOT Acceptable o Screen Status: o Responsibility: REJECTED Qid in the Internal Use field of the UCF
(continued over)
Page 20 of 57
Unisys Confidential
43108497 6, 6CA
This represents a fix closure. The acceptor should: o Check PLE completeness by reviewing the following fields: Product Level: Should match the Product Level in the UCF. o Verify that the problem is fixed and closure is acceptable by either returning to the initiator of the UCF and asking them to verify the fix, or ensuring the fix with some other method (e.g. reviewing the testing performed). Closure Acceptable If the closure is acceptable, the following fields should be updated: Screen Status: Closure NOT Acceptable If the closure is not acceptable, the following fields should be updated: Screen Status: Responsibility: 7C This UCF is in need of more information. The Acceptor should: o Review the MORE INFORMATION request for customer appropriateness. Request appropriate If the Request is appropriate for the customer, the Acceptor should update the following fields: Screen Status: Responsibility: Request NOT Acceptable The following fields should be updated: Screen Status: Responsibility: o Review the timeout. o If the UCF is a A priority, the priority should be changed to a "B" priority before accepting the timeout. 8I This UCF is a duplicate UCF from the same customer. The Acceptor should: o Screen Status: 9 This represents that a no-fix closure has been supplied. The Acceptor should review the answer given for customer viability and completeness. ACCEPTED REJECTED Assigned Specialist's Qid (Qid in the Internal Use field of the UCF). ACCEPTED Qid in the Internal Use field of the UCF REJECTED Assigned Specialist's Qid (Qid in the Internal Use field of the UCF) ACCEPTED
If the UCF is for an MORE INFORMATION timeout, the acceptor should:
Unisys Confidential
Page 21 of 57
4310 8497
X.
A.
0OUTBOUND TECHNICIAN Introduction The Outbound-Technician's primary responsibility is to prepare and ship copies of flash releases, as requested via the CSC. In addition, the Outbound-Technician ships any materials associated with: UCFs being requests for More Information, and UCFs being written against other facilities. B. Shipments To Customers Reporting Priority A Problems After receiving notification from Test Services that a Flash Release has passed testing, the Outbound-Coordinator notifies clients of the availability of that Flash Release by updating the relevant UCF responses in PRIMUS. The CSC will advise clients to retrieve the Flash from the Support Web site. It may be that the CSC will ask Engineering to send a CD directly to a customer, in which case the Outbound Technician will coordinate with the Outbound Coordinator to: o Prepare the Flash Release media. o Ship the media via the corporate preferred carrier. o File a copy of the "shipper" in the Outbound-Technicians' Materials Shipped Log Book. C. Other Shipments After receiving a request to ship materials required by a customer to provide more information or implement a workaround, or ship materials associated with the initiation of a UCF against another facility, the Outbound-Technician should: o Obtain the media from the requestor. o Ship the media via the corporate preferred carrier. o File a copy of the "shipper" in the Outbound-Technicians' Materials Shipped Log Book.
Page 22 of 57
Unisys Confidential
43108497
Unisys Confidential
Page 23 of 57
PRIMUS PROCESSING GUIDE PROGRESS CODES
4310 8497
In NIO, a subset of the complete list of EPAS Progress Codes is generally used, as shown below.
0 0A 1 1B 1FSX 1X 2 2L 2M 5 6 6C 6CA 6X 7C 8I 9
Starts at this when UCF is created/harvested into EPAS Changes to this when responsibility is changed Changed to a 1 when sent to inbound coordinator Set when the PreScreener has reviewed, but still waiting materials New Feature Suggestion Reviewed Changed to a 1X when a specialist is assigned Specialist changes to a 2 when actually starts working on UCF Answer; no fix required Set to this when a workaround is provided Means it passed unit testing but not yet reviewed Outbound coordinator sets it to a 6 when ready for gen Used by development to indicate currently in the gen in progress Used to indicate to the field that the release with this fix has passed system test. Progress code for sitting in Product Hold More Information requested Duplicate UCF; only for same problem same customer Closed; set when it moves from Product Hold to Closed
Page 24 of 57
Unisys Confidential
43108497
APPENDIX A
Unisys Confidential
Page 25 of 57
PRIMUS PROCESSING GUIDE A. UCF PROCESS POLICY
4310 8497
NOTE 1: Corporate UCF Policy is defined at http://iwww.unisys.com/policies/ under MKT Product Management subject: MKT5.2 This document is poorly formatted and may be reviewed/revised at anytime.
The corporate policy regarding software UCF closures entails the following: Priority A B C Problem Response 15 days 45 days 180 days Response Workaround, closure (no fix) or fix in a release and available. Workaround, closure (no fix), or have a patch that will be in by the next SR. An acknowledgement of receipt. Closure 270 days 270 days 270 days
Priorities are established at the time of the UCF submission and will remain unchanged throughout the UCF resolution process unless a priority change is specifically requested by initiator, or agreed to by the initiator in negotiation. UCF Trouble Reports may not be reclassified as a New Feature Suggestion (NFS) without the agreement of the submitter. Agreement on reclassification must occur as a result of communication between engineering and the support center, which will consult with the initiator and respond to engineering. If the support center contacts engineering to APPEAL a UCF response, engineering must reopen the original UCF. Therefore, engineering shall retain the original material for 45 days past UCF response. NIO Support Team Process note At the October 18, 2001 Support Team meeting, we agreed on the following process. (By the way, we chose to include all UCFs, not just priority C.): Once per month, the Support Team will review and follow-up (if necessary) all UCFs that are more than 180 days old and that have not been updated in the last 30 days.
NOTE 2: NIO Service Goals may be established which are more stringent than the Corporate Policy. Please refer to the Service Goals link on the NIO Home page, or check with your Support Team representative.
Page 26 of 57
Unisys Confidential
43108497
APPENDIX B
Unisys Confidential
Page 27 of 57
PRIMUS PROCESSING GUIDE B. CONTACT RESPONSIVENESS & RATING
4310 8497
Contact Ratings are established by Global Customer Services (GCS), which is that section of the Corporation that deals directly with clients (customers). The following memo from J. Henige (Director, Product Support, EDL), details the current metrics.
From: Sent: Subject:
Henige, Jerry L Monday, January 11, 1999 07:43 FW: Automated Engineering Timeliness Ratings (Word Attachment)
As you are aware, we have been measuring how well we are doing with Contact responses by looking at the GCS Contact Ratings. The GCS reviewer can provide ratings for both Timeliness and Content. And overall, we have been doing fairly well as the ratings for both Timeliness and Content have averaged about 4.45 for EDL in 1998. However, GCS is changing the way that they rate Timeliness (we believe that the rating for Content will remain the same.) The two big changes are: 1. The Timeliness rating will take into account the Contact Priority. The top priority are Contacts with priority ratings of E (Emergency) and D (Down). The lower priority are Contacts with priority ratings of P (Problem) and I (Informational). In the past, we have largely ignored the Priority. 2. GCS is setting goals for how quickly they want a response based on the priority. The ratings are being automated to reflect these goals. For an example, they would like to see a Contact response for E and D Contacts within 4 hours. This would get an automatic rating of 5. For P and I Contacts, the goal is 24 hours. And this would get an automatic rating of 5. Slower response than these goals would get lower ratings. (See the attached document for the times for each rating.) It appears that the Timeliness rating is based on the timeliness of the first cycle. There are also some rules for stopping the clock for weekends and holidays (Christmas and New Year). Note that these rules vary by priority. See the attached document for details. In order to continue to get meet the needs of our clients (GCS) and continue to get high ratings, it is imperative that you make everyone aware of the changes in the Contact goals and the rating process. I think in general, everyone has been trying to provide a Contact response within 24 hours. But the bar has been raised for E and D Contacts. These will have to be monitored and responded to much more agressively in order to satisfy our clients. Let me know if there are any questions. Thanks for your support. Jerry
Page 28 of 57
Unisys Confidential
43108497
APPENDIX C
Unisys Confidential
Page 29 of 57
APPENDIX D C. SYSGEN PROCESS
4310 8497
o UCF is received and routed to product specialist (programmer, technical writer, etc.) who generates patches if necessary. Patches for all active streams containing the problem should be generated. o Product specialist unit tests the fix, if testing is appropriate. o Product specialist has fix reviewed according to patch review guidelines. o Each technical team has a person who is responsible for gathering all of the patches that are to go into the next sysgen. This person can differ for the different streams. Once the fix passes review, any patches should be put in the REVIEWed state and the UCFFIXED number given to this team coordinator. Update Keyword - Inspection to Completed. o The team coordinator puts the patches in the APPROVEd state and performs a FEATURE sysgen using all numbers accumulated since the last release sysgen. A target of ALL should be specified. o Testing done after this point is at the discretion of each team. It is recommended that at least some basic loading/testing should be done to verify that certain platforms have not been broken. Any affected areas not tested should be noted in the sysgen coordination meeting. o Once all patches for a team have been genned together, they will be turned over to the overall sysgen coordinator as UCFFIXED numbers to include in the next Release gen. o When deemed appropriate the overall sysgen coordinator calls a meeting of the team coordinators, normally this is handled via e-mail. They determine what patches should go into the next sysgen. o The team coordinators ensure that the appropriate patches are put into the RELEASEd state in preparation for the sysgen. o Once the sysgen is complete and Smoke Test passed, the result of the gen can be found on the released base packs (48RBASE or 49RBASE). Test services obtains it from these packs (tapes are also delivered) and begins testing. o o The patches are not applied until a release is passed by Test Services. Files are then copied to the applied base packs (48ABASE, or 49ABASE).
Page 30 of 57
Unisys Confidential
43108497
APPENDIX D
Unisys Confidential
Page 31 of 57
APPENDIX E D.
4310 8497
AS DESIGNED CLOSURES The As Designed closure code on UCF should not be used as a generic "it's working like we expect it to" response. More specific closure codes should be used to provide useful information to our customers without increasing the amount of work required to close UCFs. (e.g. Configuration Error, Documentation Reference, Operational Error or Technical Question) Configuration Error should be used when the user has an incorrect configuration of the product. Documentation Reference should be used when the documentation for the product clearly provides an answer to the UCF. In cases where the information is missing from the documentation (or is inaccurate) and Product Information agrees, the proper information should be placed in the Internal Text field of the UCF and the UCF should re-classified as a documentation UCF and transferred to Product Information. Operational Error should be used when an incorrect usage or deviation from the product's specification or operational procedure has occurred. Technical Question should be used when the UCF is actually a request for interpretation of the product's functionality. The As Designed closure code should only be used "if the design change required would contradict product standards or strategic directions". If the UCF is actually a request for a new feature/design change and the customer agrees, the UCF should be converted into a New Feature Suggestion. Use of the As Designed closure code on any UCF should mark that UCF as a requirement that must be addressed in the next release's requirements document. (Each UCF responded to with the As Designed closure code must include a detailed technical explanation of the reason for the closure. This reduces the work necessary at the requirements document stage.)
Page 32 of 57
Unisys Confidential
43108497
APPENDIX E
Unisys Confidential
Page 33 of 57
APPENDIX F E.
4310 8497
0PLE-CHG CREATION/UPDATE A Problem List Entry contains two basic pieces of information: 1. A PLE describes a unique problem or feature with a UNISYS product. While the same problem or feature may be reported on many UCFs, it is defined on only one PLE. The PLE description of the problem or feature should be accurate, thorough and provide all information that may help engineers and customers support personnel recognize the problem. 2. A PLE describes engineering's resolution of the problem or feature. This portion of a PLE also contains information about the actual correction or release that resolves the problem or implements the feature. Problem List Entries are required for all problems. Problems found by engineering personnel should be documented via a PLE (a UCF is not necessary). Problems being reported to another organization should be reported via a UCF (TYPE=DEVELOPMENT, SUBTYPE=ENGINEERING). This appendix contains three sections, they are:
1. Trouble Report PLEs 2. PLE Content for Features in Mark & Support Releases 3. Summary for Entering Patch Comments
1. TROUBLE REPORT PLES A PLE is normally created using the PLE based on a UCF entry activity Some of the PLE fields are filled in from the UCF, but all of the information described here should be checked and updated as necessary. When entering text into PLEs, please pay attention to presentation, language and spelling since customers eventually read most of what you enter. Product Section Product/Component Enter a valid product and component for the product. The product and component must match the UCF. The Resolved Problems List is sorted based on these fields so it may not be generated correctly it there are mismatches. Type Problems reported by customers and non-development internal sites will be reported via TYPE=RELEASED UCFs. These must be closed with TYPE=RELEASED PLEs. Releases under test that have not been passed by Test Services will be type Development. This includes both Mark and Flash releases. If a problem is visible outside of development plants the PLE should be TYPE=RELEASED. Form This field identifies whether the PLE is for a Trouble Report or if it is for a Feature Suggestion. Customer Technical Bulletin The CTB field identifies the type of customer technical bulletin presented by the PLE. If the PLE addresses a very critical problem where the use of the product is greatly impaired or the integrity of the customers data is compromised, this field is given a value of ALE (alert). If the PLE addresses an in depth definition of an issue or problem that needs to be brought to the customers attention, this field is given a value of NOR (normal). If the PLE reflects a problem that does not meet either of the criteria above it may be left blank. Internal USE (IU) This field should contain the PLE originator's PRIMUS user-id. Page 34 of 57 Unisys Confidential
43108497 Manager
APPENDIX F
This field should contain the PRIMUS user-id of the in-bound coordinator for this product. Description Section Headline The Headline should concisely describe the problem. This field is visible to the CSC databases and will appear in the Resolved Problems List. Keyword If the PLE is based on a UCF, all Keywords entered in the UCF will be carried over to the PLE. Keywords are an important tool used by both the field (including customers) and engineering when searching PLEs for previously reported problems. A PLE for a problem which caused a flash release to fail MUST have the keyword RELEASEKILLER. (Other examples of useful keywords are Halt <Halt Code>", <line numbers>, invalid index, etc) Internal-Keyword When you fix a bug, add to the PLE a CAUSEPRInnnnnnn, CAUSEPLEnnnnnnnn, CAUSEBASE (day one problem), or CAUSEUNKNOWN internal keyword. Remember that in PatchManager, the MarkID for each line shows the level that line was gen'ed. So, if you know what line had the bug, it is very simple to find the PRI or PLE that caused it. (see example below) Don't spend more that 15 minutes trying to determine the cause. If you know it, add the CAUSEPRI or CAUSEPLE; if you can't determine it within 15 minutes, then enter CAUSEUNKNOWN. If it's a day-one problem enter CAUSEBASE. Other internal keywords are CAUSE-ThisIsANFS, CAUSE-Microsoft, CAUSENotNeeded. Example: To find the PRI quickly for level 47.107, go to PatchManager (?on NPMDB) : pa : cycle 107 PROVIDER/STATUS/UNAVAILABLE/FOR/SHUTDOWN/PROCESSING [461CNSMGR] (JGS) 46.107.0074 PRI-9450351 Lines=267 Perform Provider Unavailable Processing For CNS Net Minus Operation LCF/FIX/IFA/FAULT/DURING/LMRELOAD [461CNSMGR] (ARMSTRONG) 46.107.0073 PRI-9453903 Lines=54 Fixes fault/dump by CNS IFA PROCESS after RELOAD LM command + Recap for internal keywords CAUSEPRInnnnnnn CAUSEPLEnnnnnnnn (if you don't know the PRI) CAUSEUNKNOWN CAUSEBASE CAUSE-ThisIsANFS CAUSE-Microsoft CAUSE-Not-Needed CAUSE-No-PLE Symptoms Enter the description of how the problem manifests itself, what brought about the failure, and any preceding events that are applicable. If it is possible for the problem to be seen in situations other than that, which is reported on the initial problem report, these scenarios should be outlined also. This field is visible to the CSC databases and appears in the Resolved Problems List. Internal-Conditions Provide all pertinent information that could help someone else diagnose another occurrence of the problem. It is important that we provide full and accurate details to assist field and support organizations in identifying already resolved problems, duplicate occurrences of problems and other instances of problems we are in the process of resolving. Examples are: Sumlog entries, Call Unisys Confidential Page 35 of 57
APPENDIX F
4310 8497
returns, stack history, parameter information, Displays seen, Configuration details under which the problem occurs, table entries and values that are applicable. This field is visible to the CSC databases but not in the Resolved Problems List. Technical-Explanation Describe in detail, including variable and element names as appropriate, the problem that occurred and how it has been resolved. This field is visible to the CSC databases but not in the Resolved Problems List. Workaround Section It is in our interest to look for ways to detour a problem. A viable detour will lessen the impact of the problem on the customer's operations and may be all that is needed to avoid WALERT, CSR and on site support situations. This section is only applicable if a viable workaround is available. The workaround details what steps can be taken to avoid the problem and must be thorough and accurate. Do not assume that the recipient has your level of product knowledge. Note: The text of the workaround will be sent to the initiator of every UCF that is attached to this PLE. Therefore, do not enter customer specific text as part of a workaround. Workaround-Available Entering a YES will cause the workaround response to be sent to every initiator of all UCFs attached to the PLE. Workaround-Type Set the type field to PROCEDURE, INTEGRATED-FIX (if a new generated object is available) or NON-INTEGRATED FIX (if it is a detour for the problem). Workaround-Description Enter the text for the workaround. This field is visible to the CSC data Bases but is not in the Resolved Problems List. Resolution Section This section consists of two parts: information that applies to the PLE resolution as a whole, followed by multiple Resolution Blocks, each of which contain information that applies to a specific software stream. Resolution-Comments Enter the release level that will include this correction and the date that it is scheduled for. (e.g. "This problem will be corrected in 006.0, scheduled to be available 4th QTR 05"). Internal-Text This field cannot be seen outside of Engineering, so it may be used for entering private comments regarding the problem. It may be used as a status report. It should contain the history and current status of the resolution of the problem, including dates. This will allow others to determine the present status of the investigation without having to contact the individual engineer. It can also be used to record any information regarding the PLE that cannot be recorded elsewhere, e.g. the specific sysgen level that contains the patch. Resolution Blocks If the problem exists in another mark level, create resolution blocks for each mark SR level and reengineer your patches to fit those mark levels. If the problem does not exist in a mark level, create resolution blocks for each mark that explicitly state this by entering 'NF' in the Resolution Status of that specific resolution block. For example, if a problem is reported against level 046 and it also exists in 047 and 048, it is your Page 36 of 57 Unisys Confidential
43108497
APPENDIX F
responsibility to identify the problem and correction in the Mark levels by way of resolution blocks. If the problem is reported against mark level 047 and it exists in 048 but not 046 there still must be a resolution block for 046, which has a resolution status of NF (No Fix required). You must also keep the development mark levels in mind and create resolution blocks for those software levels. If you know that a problem exists in a development mark level or you are not sure, create a resolution block for that mark level, with a status of UA (Under Analysis). On the other hand, if you know for sure that the problem does not exist in the development mark level, create a resolution block for that mark level with a status of NF. Each Resolution block contains the following fields: Resolution-for-Level Enter the product level of the UCF that will be attached to this PLE. It should be either in the form .<support release> (e.g. 048.1), or .<release> (e.g. 048.118). Resolution-Status Select the current status code (e.g. UNDER ANALYSIS, FIX IN DEVELOPMENT, FIX COMPLETED or NO FIX APPLIES). Send To CSC If the resolution block on the PLE is for an unreleased version of a product the field Send-To-CSC should be set to NO. This field on a resolution block of a PLE indicates that this particular resolution block should not be sent to the CSC data bases (i.e. this is for a development level of the product). The default for the Send-To-CSC field is YES, send the resolution block to the CSC data base. Closure-Code Select the appropriate closure code (e.g. SOFTWARE DEFECT PLE-to-CHG Enter the PRI number(s) of the patch(es) that correct the problem in this mark level, as specified in the RFL. For example: PRI-8512345 Fixed-in-Release Enter the identifier of the release that incorporates the correction, in the form <product>-.<support release>. For example: A99DOG-049.01. Root Cause Section Update the Root Cause section of the PLE. Refer to Appendix G for an explanation of the following fields: Defect Injection Point Defect Detection Point Defect Introduced in Level Defect Group Defect Type Cause Factor
Unisys Confidential
Page 37 of 57
APPENDIX F
4310 8497
2. PLE CONTENT FOR SUPPORT/MARK RELEASES NEW FEATURES A PLE will be entered into PRIMUS at the start of the development phase for each new feature. The following fields are significant, any fields not mentioned need not be filled in by the PLE originator. Header Section Product Use Help Product List if product is not known. Component Enter if known; this is not mandatory. Type Development unless PLE is attached to an NFS UCF. Form Feature Suggestion (FS) Internal Use set to your PRIMUS USER ID. Description Section Headline A brief description of the feature. Keyword FEATURE: SR or MARK plus any additional keywords that are relevant. Feature owners may also specify that a special keyword be used for all PLEs that are part of a certain feature. Symptoms Enter NONE unless the feature addresses a deficiency, shortcoming of the product. If it does, specify what the user experienced prior to the feature. Internal-Conditions Enter nothing unless the lack of the feature caused a problem that could be identified through a dump or log. Technical-Explanation For a MARK (SSR) release this field will be used to reference the Functional Design Specification (FDS), Functional Test Plan (FTP), Detail Design Specification (DDS) and Unit Test Plan (UTP) by name and document number. For a Support release (SSP) feature this field contains the information normally found in an FDS, FTP, DDS and UTP; or references the documents which contain this information. If documented in the PLE this section will be broken down into subsections according to the Development Process. The following sections should be included: Requirements Test Plan Functional Overview Functional Description Customer Interfaces System Software Interfaces Future Interface Standards and Conformance Issues and Risks
Please consult the Development Process Guide for a description of each of the fields Resolution Block Page 38 of 57 Unisys Confidential
43108497 Resolution-for-Level Same as Product Level. Resolution-Status
APPENDIX F
A resolution block must be created for each MARK release that will incorporate the feature.
Set to FIX COMPLETE after completion of successful code inspection. Closure Code Will be set by PRIMUS to FEATURE IMPLEMENTED after the feature is released in Patch Manager. PLE-to-CHG Supply the PRI number of the patch(es) that implement the feature (e.g. PRI-xxxxxxx). Please refer to the Patch Documentation Guidelines described later in this appendix. Fixed-in-Release This field is completed by the outbound coordinator if the feature addresses a NFS UCF; otherwise the feature owner will be responsible. The format of this field is Product-Release (e.g. CP2000-COS-043.02).
Root Cause Section The root cause section is optional for new features. If the feature was implemented as a result of a customer UCF that was originally of type trouble report, then filling in this section may be appropriate. It is left to the feature owner to make this decision. Please refer to Appendix G for a description of these fields. For Support Releases (SSPs) Only The feature owner will also provide a functional test plan to Test Services. This test plan will be carried forward to the next MARK release and become part of that release's FTP. A FDS for this feature will be created for the next Mark release. This document will supply a brief description of the feature and point to the PLE.
Unisys Confidential
Page 39 of 57
APPENDIX F
4310 8497
3. SUMMARY FOR ENTERING PATCH COMMENTS Patch Documentation Guidelines As part of software releases, two documents are provided to our customers: the Documentation Changes List (Comment Type DNOTE) and the Resolved Problems List (Comment Type PNOTE). When documenting a patch, a decision must be made as to whether or not information should be included in one of these documents. Depending on the situation, the patch documentation may be included in one of these two documents, both of them or neither of them. The Resolved Problems List contains Resolved Problem Notes (Comment Type PNOTE) which are generated from information in PRIMUS and Patchmanager. The Documentation Changes List contains Documentation Change Notes (Comment Type DNOTE) which are extracted from Patchmanager. Resolved Problem Notes A Resolved Problem Note (Comment Type PNOTE) should be created when resolving a user-visible problem which exists in software and documentation which has been Released to customers. A TYPE=RELEASED PLE is required. These notes are generated from the PLE information in PRIMUS and include some information from Patchmanager. Documentation Change Notes Documentation Change Notes (Comment Type DNOTE) should be created to document a change to a manual or a change to the user visible behavior of the system. They are generated from the patch comment information in Patchmanager. They typically document a design change, and they should be written to: 1. Document a new feature added when a PCN or new manual is not released at the same time, such as a feature being added to a kit or a support release (SSP). 2. Highlight or summarize a new feature change which is documented in a new PCN or manual and not described in the Capabilities Manual. 3. Document a user visible change in the system behavior even though this aspect of the software may not be specifically documented in the manual. Some situations require both a Documentation Change Note AND a Resolved Problem Note. A TYPE=RELEASED PLE is required in these instances since Resolved Problem Notes are generated primarily from TYPE-RELEASED PLEs. There should be a patch with the comment type of PNOTE and also a patch with the comment Type of DNOTE. These patches should be linked using CONNECTCOMMENT in Patchmanager. These notes should be written to: 1. Document a user visible change in system behavior which is the result of a problem resolution. 2. Document the user visible changes to a manual implemented as part of a problem resolution. 3. Correct an obscure or unintuitive error in a PUBLISHED MANUAL. INTERNAL NOTES An Internal Note (Comment Type INTERNAL) should be created to document a problem that is not user visible or to describe a change that does not require user visible documentation. The UCF and PLE should both be TYPE=DEVELOPMENT. Internal Notes should also be created for patches that fix problems discovered during Field Test as long as the patch will be included in the FCS version of the software and the problem doesn't exist in another level of software which is already released. The PLEs for these problems should be TYPE=RELEASED. GENERAL GUIDELINES FOR PATCHMANAGER AND PRIMUS In general, changes should be described by the symptoms that appear to the users (not the internal working of the product) and references should be to documentation that is available to the user. It is Page 40 of 57 Unisys Confidential
43108497
APPENDIX F
important that the descriptions are written in proper English, written with uppercase and lowercase, and that spelling, grammar, punctuation and formatting be correct since no overall editing or reformatting is done prior to publication. There should be no references to actual customers or customer specific environments. The Documentation Changes List and Resolved Problems List are generated directly from PRIMUS and Patchmanager and the product groups are responsible for reviewing them and making corrections. PATCHMANAGER INSTRUCTIONS Class Class FEATURE and FEATURE-FIX are assumed to be part of Development (New Release). Always use FIX for patches that fix customer reported problems. Comment Type: The comment type must be PNOTE, DNOTE or INTERNAL as described above. Headline: The Title should be concise (no longer than 65 characters), meaningful to the user, and written in uppercase and lowercase with initial caps with reserved words in UPPERCASE. There should be no ending punctuation or obscure abbreviations. For Resolved Problem Notes (PNOTEs), the Title should emphasize the problem rather than the solution. User-Oriented Description: For Documentation Change Notes (DNOTEs), the User-Oriented Description field should contain a generalized description of the changes as they appear to the user and to the user documentation. Unless it is essential in order to describe the change, explicit details for updating the manuals (page numbers, paragraph numbers, replacement text, ...) should not be put in this field. A description of the internal workings of the product is also inappropriate. For Resolved Problem Notes (PNOTEs), the User-Oriented Description field should contain a generalized description of the external symptoms of the problem that has been resolved. This description should emphasize the problem rather than the solution. A description of the internal workings of the product is inappropriate. For Internal Notes, the User-Oriented Description field should contain the word NONE. For a priority A field test problem (one which does not occur in a previous release). this field must contain a description of the symptoms of the problem as described above for Resolved Problem Notes, and the Comment Type INTERNAL should be specified. Internal Comments: The Internal Comments Technical field should contain an internal, technical description of the changes or problems and how it was resolved. Any information that will be helpful or meaningful to other analysts or programmers, including new information about past changes, should be included. This field is not published, and it is not harvested to PRIMUS. The Internal Comments Miscellaneous field should contain any special instructions or information which you feel needs to be passed on to other UNISYS personnel, but doesn't belong in any other fields in the comment. This field is not published, and it is not harvested to PRIMUS. Software Documentation: Specific manual update information and instructions for the writers should be put in the Software Documentation field. This information may include specific page numbers, paragraph numbers and replacement text, or it may contain references to design documents. The Help Text affected field should contain either the word "NONE" or "YES". These fields are not published, and it is not harvested to PRIMUS.
Unisys Confidential
Page 41 of 57
APPENDIX F Test Procedure:
4310 8497
Test Procedure field should contain a detailed description of how to reproduce the problem and either a reference to a test plan or a description of the test plan as well as results of the unit or functional tests performed. This includes the following: o A description of the network/system configuration. o A step by step procedure on how to reproduce the problem. o If it requires that a system be put under emulation and break points need be set, this section should include the procedure name and, if possible, line numbers within the procedure. o The expected results (at each step if necessary). For those cases where the problem is not reproducible, it is necessary to indicate here that it is not reproducible, and that the patch has been regression tested. For those cases where we can not simulate the configuration or network, this section should contain statements indicating that the patch was verified. Product/Component: The Product/Component field can contain values that are consistent with the Softid. For Resolved Problems Notes (PNOTEs), this field should match the corresponding fields in the PLE which must match the corresponding field in the UCF. The Documentation Changes List (DNOTEs) and the Resolved Problems List (PNOTEs) are sorted based on this field so they may not be generated correctly if there are mismatches. Fixes and features requiring patches in multiple softids should, in most instances, share comments (use CONNECTCOMMENT). If only one user visible note is required, the notes for the other patches should have a comment type of INTERNAL. If a patch is released to one product or component but the documentation belongs under another product or component, a dummy patch, which shares a comment with the original patch (use CONNECTCOMMENT), should be released to the other product or component. The comment type INTERNAL should be used to suppress the note for the original product or component. UCFS/PLES: This section should contain UCF Reference numbers which correspond to features in the form 999nnn-nnnnnn where nnn-nnnnnn is assigned by the feature owner. It should also contain PLE numbers associated with the problem in the form PLE nnnnnnnn where nnnnnnnn is the PLE number in the PRIMUS data base. Notes included in the documentation for one Mark Release SHOULD NOT be included in the documentation for the next Mark Release. For example, 48.00 notes should be SUPPRESSed in the 49.00 Release. Notes for Support Releases MUST be included in the documentation for the subsequent Mark Release. For example, 48.01 notes MUST be included in the 49.00 documentation.
USER DOCUMENTATION As part of our software releases, two documents are provided to our customers: the Documentation Changes List and the Resolved Problems List. Internal notes are not published. In addition, much of the information in PatchManager and PRIMUS is sent to the customers as part of UCF responses so care must be taken to make sure the information is ready to ship to customers. Documentation Changes List (DNOTEs) The Title and the text in the User-Oriented Description field will be extracted as is from PatchManager categorized based on the Product/Component for the patch and published in a document called the Documentation Changes List. Patches will be selected if the comment type is DNOTE. Page 42 of 57 Unisys Confidential
43108497
APPENDIX F
Resolved Problems List (PNOTEs) PLEs that are TYPE=RELEASED for problems that are resolved will be selected for publication in a document called the Resolved Problems List. TYPE=RELEASED PLEs for problems that do not occur in a previous level of the software will be excluded. For selected PLEs, the text in the Headline, and Symptoms will be extracted from PRIMUS. Also, the PRI number, the Title and any text in the User-Oriented Description field will be extracted from the CHG in PRIMUS and included with the PLE description. The Title and the User-Oriented Description from the patch comment and the text of the patch, including the patch name, are extracted from PatchManager and stored in PRIMUS as a CHG. A CHG identifier is PRI-xxxxxxx. Patches with a comment type of PNOTE will be included in this list even if there is no associated PLE in PRIMUS or the PLE was not selected. UCF Responses The following PLE text fields are included in UCF responses, which are sent to customers: Headline, Symptoms, Internal-Conditions, Technical-Explanation, Resolution-Comments, Workaround-Description .
Unisys Confidential
Page 43 of 57
APPENDIX G F.
4310 8497
PLE ROOT CAUSE FIELDS
INTRODUCTION The purpose of the Root Cause Fields in a PLE is to facilitate the collection of data regarding a problem. These data may then be subsequently analyzed at some later time with a view to improving our Processes and Product Quality We need these six RCA fields on TR PLEs Type=Released. Defect-Injection-Point, Defect-Group, Defect-Detection-Point, Defect-Introduced-in-Level, Defect-Type, Cause-Factor. Root Cause Comments is an additional field that can be used to provide explanatory text. You do not need to spend a lot of time (no more than 15 minutes) trying to determine the DefectIntroduced-in-Level field. If it is a "Day 1" problem, you can enter "BASE" as the Defect-Introducedin-Level. If you know the level, please use the actual level (e.g. 46.107.0074). If you cannot determine the level, use "UNKNOWN".
DEFECT INJECTION POINT FIELD The Defect Injection Point field indicates the stage at which the defect was injected. Choose one of the following values: Coding/Implementation The coding step translates the design into an implementation language to create source code. The error was caused by mistranslating the design into code, choosing an inappropriate data structure, or introducing some other mechanical error in the code. Also, use this value if the defect was injected while trying to resolve a defect found in one of the test phases. Examples: Code was not written to evaluate boundary conditions. An arithmetic computation was not coded correctly. The performance of the chosen algorithm is too slow. Code was written to correct a problem found in field test, but the new code created a new defect. Definition The definition step (same as functional design) describes the functionality of the product from the user's perspective and designs what it will take to provide this interface. The error was caused by a problem defining the tasks that will be performed by different users designing the user interfaces or designing the interfaces to other system components. Use this value even if no functional design document was created, but the defect is a functional defect or issue. Examples: The functional design failed to address a user requirement. The functional design described the user's security needs incorrectly. The product did not provide for international user interfaces. The customer found the product messages to be confusing. The customer performed a tasks by using a menu, only to discover that the system performed a different, unexpected task. Design Page 44 of 57 Unisys Confidential
43108497
APPENDIX G
The design step (same as detailed design) describes how the functional design will be implemented. The error was caused by a design element that was incorrect, missing or incomplete. Use this value even if no design document was created, but the defect is an implementation design flaw or issue. Examples: The design describes a static-size data structure to hold 100 entries, and the problem is that is must hold 150 entries. The relationship between two different software or modules was misunderstood. Feasibility The feasibility step (same as the proposal step) analyzes alternative solutions to each requirement and makes a recommendation of the solution or solutions to be chosen. The feasibility of completing the solution within estimated costs is evaluated. The defect was caused by a problem with the outcome of the proposal step. Examples: The proposal step failed to address a needed requirement. The proposal overestimated the speed and capacity of a device and underestimated the cost. The proposal solution did not adequately meets its associated requirement. Inspection The inspection step describes the various points this feature will be inspected. The error was caused by one of these inspections causing a change in the inspected material which later resulted in a defect. Example: At code inspection time a coding change was suggested which resulted in a defect in the code. Other None of the other values are applicable. The defect was injected in a step that is not listed. Explain the point at which the defect was injected in the Root Cause Comments field. Product Attribute test I cannot think of an example of where a defect can be injected by testing. Product Integration The product integration step combines multiple components or changes from one or multiple products. This step is not the integration test phase. Examples: A correction required patches in two products, one patch was released and the other was not released. Multiple patches within a single product were released in the wrong order or were incompatible. Qualification I cannot think of an example of where a defect can be injected by Qualification. Release The release step creates the release media (release tape) from the working file. The defect was caused by a problem in combining files to include in the release or in creating the final media. Examples: The wrong version of a file was copied onto the tape. The tape copy failed, was undetected, and resulted in the tape being shipped with a previous version of the software on the release tape. Requirements The requirements step defines and analyzes the problem to be solved and the requirements and constraints for a solution. The defect was caused by a problem in the requirements. Unisys Confidential Page 45 of 57
APPENDIX G
4310 8497
Example: A requirement was missing, incomplete, unclear or incorrect. Unit test I cannot think of an example of where a defect can be injected by testing. Unknown The point of injection is unknown. The problem was probably introduced in a Mark release. The problem appears to have been injected somewhere between the requirements and coding steps. User Documentation
Page 46 of 57
Unisys Confidential
43108497 DEFECT GROUP FIELD
APPENDIX G
The Defect Group field contains a categorization of the product defect. Generally, the field value indicates the action that was occurring for instance, implementing a feature or fixing a problem, when the defect was injected. Use the following values: Continuation Regression A previous fix introduced a defect in a previously functioning part of the product. Example: In response to a customer UCF, a fix was made to a problem. The fix caused a 'side effect' problem in a previously functioning part of the product. External Supplier Feature A feature was previously added and does not work as expected. Example 1: A feature was added in a previous mark release, but now it is found that the feature never worked as expected. Example 2: A feature is being added to the current mark release. A defect in the feature was found during system testing. Feature Regression A feature was added and has broken a previously functioning feature. Example: A feature newly added to the current mark release has broken a basic (day-one) feature of the product. Latent Imperfect Fix A fix was made previously that did not completely resolve the problem. The patch did not correct the right problem, fixed it incorrectly, or only fixed part of the problem. Other None of the other values are applicable. This category should be used infrequently. If you choose this value, you should also make an entry in the Root Cause Comments field. Example: Because of customer pressure, a new feature is introduced on a support release. Unknown It is not known how the defect being fixed was introduced.
Unisys Confidential
Page 47 of 57
APPENDIX G
4310 8497
DEFECT DETECTION POINT FIELD The Defect Detection Point field indicates the stage at which the defect was detected. Choose one of the following values. Code Review The defect was discovered while reviewing and inspecting the code. Coding/Implementation The defect was discovered during the coding process. Continuation Code Review The defect was found while reviewing or inspecting continuation (maintenance) code. Continuation Coding The defect was discovered during the continuation coding. Example: The defect was found while trying to diagnose or identify another defect. Continuation Regression Testing The defect was found while executing regression tests. Regression tests verify that all tests that previously ran successfully still run successfully. Continuation Unit Testing The defect was found while unit testing maintenance code. Customer UCF The defect was found by a customer, who submitted a UCF. Definition Document Review The defect was discovered while reviewing and inspecting the functional design document. Design Prototype The defect was discovered while prototyping ideas in the implementation design. Design Review The defect was discovered while reviewing and inspecting the implementation design document. Feasibility Review The defect was discovered while reviewing and inspecting the proposal document. Integration Testing The defect was discovered during integration testing of the product. Integration testing integrates individual units and components into the system for testing. The interfaces between pieces also are tested. Interoperability Testing The defect was discovered during interoperability testing of the product. An interoperability test exercises related or dependent products and the different pairings of their supported release levels across a network. Example: A problem was found while different vendor products were tested for compatibility with Unisys products. Internal User The defect was found by an internal user (that is, a Unisys employee who is outside of the owning group) prior to FCS. Page 48 of 57 Unisys Confidential
43108497 Other
APPENDIX G
None of the other values are applicable. The defect was found in some other step that is not listed. Explain the point at which the defect was detected in the Root Cause Comments Field. Prototype Definition The defect was discovered while prototyping ideas in the functional design. Regression Testing The defect was discovered during regression testing of the product. Regression tests verify that all tests that previously ran successfully still run successfully. You can perform regression testing during a new feature cycle to make sure nothing was broken in the existing product. Requirements Review The defect was discovered while reviewing and inspecting the requirements document. System Testing The defect was found during system testing of the product. System test verifies that the product satisfies the Ready for Field Test (RFT) and First Customer Shipment (FCS) criteria specified in all previous design documents. This phase also verifies that the product is ready for general distribution to customers. Unit Testing The defect was discovered while unit testing the code. Unit test verifies that correct outputs are generated for each combination of input data and function executed. All code paths must pass the tests. Also, use this value for a defect found while testing the functionality of the product to ensure it meets the functional design objectives. Unknown The point of detection is unknown.
Unisys Confidential
Page 49 of 57
APPENDIX G
4310 8497
DEFECT INTRODUCED IN LEVEL FIELD The Defect Introduced in Level field indicates the release level in which the problem was originally introduced. Use one of the following values: .<release cycle> If you know the cycle, always use Mark.release cycle. (e.g. 048.115). The .<Support Release> value follows the same convention used in the PLE Resolution Blocks. If the problem appears to have been a day-one problem, enter the Mark release level that is believed to have introduced the problem, or BASE.
Unknown Enter UNK if the release level cannot be determined.
Page 50 of 57
Unisys Confidential
43108497 DEFECT TYPE FIELD
APPENDIX G
The Defect Type field defines the technical nature of the defect. If the patch corrects more than one defect, categorize the major defect or defects with one of the following values: Computational The programmer chose the wrong algorithm, coded the algorithm wrong, or had a problem with machine arithmetic. Examples: Equation was insufficient or incorrect Missing computation, Operand in equation incorrect Precision loss Rounding or truncation fault, Mixed modes (integer/real, and so forth) Sign convention fault (for example, handling -0) Chosen algorithm was not efficient Compatibility The product was incompatible with another product or with a previous level of this product. Example: A product was not compatible with a data file created on an earlier release. Data Structure The data being supplied to the program was incorrect, or was manipulated incorrectly. Examples: Static tables wrong. Configuration parameters wrong or conflicting Used integer as pointer or vice versa Used wrong pointer to reference a base structure Variable uninitialized or initialized incorrectly Passed by a reference instead of by a value or vice versa Accessed or stored data incorrectly Referenced wrong variable Scaling or units of data incorrect Incorrect use of DEFINE to access data Dimensioned data incorrectly used Dimensions are wrong Scope of data incorrect; local data versus global name conflict Documentation Problem The defect is an error in end-user documentation, technical documentation, or code comments. Examples: Online help text incorrect, incomplete or misleading End-user documentation incorrect, incomplete, or misleading. Internal documentation incorrect, incomplete, or misleading. Missing, incorrect, or misleading code comments. Integration Conflict Multiple changes were combined into the same software and these changes conflicted. Example: Two patches changed the same data structure, causing a mismatch between one of the patches and the changed data structure.
Unisys Confidential
Page 51 of 57
APPENDIX G Interface
4310 8497
Wrong interface between two modules in a program, or wrong interface between one product and another product. Examples: Interrupts handled incorrectly Subroutine/library mismatch Wrong number of parameters Wrong entry point called Nonexistent entry point Logical The code to handle a condition should have been present but was missing completely, or the code is present to handle it but is wrong or incomplete. Examples: Duplicate logic Extreme (boundary) conditions handled incorrectly Scaling is wrong because it handles 10 items instead of 1000. Unnecessary function Repeated or exiting loop incorrectly Error handling incorrect Wrong error message Forgotten case or steps Misinterpretation of design Missing condition test Other None of the other values are applicable. This category should be used infrequently. Always try to describe the problem using one of the other categories before choosing this value. If used, you should explain the type of error in the Root Cause Comments field. Performance The product functions as intended but does not meet documented (or reasonable) performance requirements. Unknown The technical nature of the defect cannot be determined.
Page 52 of 57
Unisys Confidential
43108497 CAUSE FACTOR FIELD
APPENDIX G
The Cause Factor field provides a general indication of the reason the defect occurred. Although this field is a repeating field, select one of the following values to indicate the SINGLE MOST IMPORTANT factor that contributed to the defect: Could Not Anticipate Error It is unreasonable to expect that this error could have been prevented by any normal step in the process. This defect is so bizarre that it is unreasonable to expect it to have been discovered through review or testing. This category should be used sparingly. Example: There is a restriction that no more than 11 asterisks in any one command be sent through a modem; otherwise, the modem enters a test state from which it cannot escape unless a string of five plus signs are sent. The programmer implemented and tested the code on a different, supposedly compatible, modem for which no such restriction exists. The programmer must change the code to handle this new modem, but it is ridiculous to suppose that this restriction could have been discovered earlier. Education The programmer might not have understood how the existing code worked or how the new function was supposed to work. Or, the programmer might not have understood some other aspect of the development process. Example: The programmer did not realize that the compiler does not initialize arrays to zero. The program used an uninitialized array expecting it to be zero. Internally or Externally Generated Requirements Change Use these categories only when the change requirement led directly to a bad feature or a hasty implementation. If the change was reasonable, the root cause of a defect probably lies elsewhere. Some external groups, such as marketing, or some people internal to the project, such as project management, convinced the Programming group to "do them a favor" and add or change a feature to better fit the perceived needs of the customers. Or, perhaps a developer thought a feature would be a nice additional capability (that is, creeping elegance). Example: While providing on-site support for a customer, a programmer commits to providing a new feature in exchange for his or her freedom. The feature is hastily developed and released in a support release, but the feature is found to be bug-ridden. Faulty Supplier The defect was inherited from the programmers supplier. Some defect with the inputs to the programmer's process has been uncovered. This category should be used only if it is unreasonable for the normal review process to have caught this defect. Example: The developer created networking software to be compatible with an International Business Machines (IBM) network. IBM discovered a design flaw in its network. The developer, having had coded according to the original design, must now change the code to reflect the fix from IBM. Human Communications Information from others on the project or on a related project was incorrect or not received at all. This information could be from either an internal or external source. Example: The program interface of a utility was changed to require a third parameter, but the programmers using the interface were not informed.
Unisys Confidential
Page 53 of 57
APPENDIX G Lack of Resources
4310 8497
The programming team requested a certain resource but could not get it. The lack of this resource directly led to the introduction of error. Usually, the lack of resources forces programmers to work in manner they feel uncomfortable with. Example: A team was writing an Ada compiler for an Air Force contract with a firm delivery date. No one in the group knew Ada well. The programmers had asked management to hire an Ada expert to resolve language ambiguities after the programming team had argued about possible interpretations of the Ada standard. The company had a hiring freeze for which no exceptions could be made. The Programming group interpreted the standard as best they could but made an error in interpreting how a given feature should work. This cause factor could have been considered an education problem. However, the team felt that they were staffed inadequately and that there was not enough time to educate a current team member. The process change that might be suggested by this example is as follows: Ensure each development team has an expert as a member or as a consultant when starting a new project. Lack of Tools A programmer needed a hardware or software tool that was not available. Example: A large number of definitions must be updated to match a new interface. Because of the lack of migration tool, the changes were made manually. A mistake occurred, and some definitions were not updated correctly. Other The defect was introduced by some factor not covered by the list in this section. Use this category sparingly. Example: A product has a large block of code that displays full screens of information and then reads back the user's input in full screen mode. When changes are made to fix problems, inevitably it causes other problems. In short, this is an inherently complex, poorly understood, poorly designed area. The nature of the beast is that defects will occur. Oversight Usually some detail of the problem was overlooked, error cases were not handled properly, and interactions were not properly thought out. This category should be used even if the programmer felt pressured for time and did not review or test the product thoroughly for that reason. Example: The programmer thought that all values of a variable were handled by a CASE statement, but that assumption was later found not to be true. An error case was not handled properly. Process Inadequate The process that should have been followed was not documented or the process documented was incomplete, misleading, or wrong. Had the process been documented correctly, it is probable that the error would not have happened. Example: The programmer's process should have included a step in which someone checked the results of the release tape generation to ensure that the process completed successfully and that the release tape contained the newest product level. Process Not Followed A programmer knew a documented process existed but did not follow it. If the programmer adhered to the process, he or she should have completed a set process during which the programmer would have discovered the problem. Transcription A programmer introduced a typographical error in code or created some other type of error because Page 54 of 57 Unisys Confidential
43108497
APPENDIX G
of carelessness. Example: The programmer copied a block of code from one section of a program to another because the copied block was nearly identical to the code that was needed. However, the programmer failed to make all the required changes even though he or she knew the changes that were needed.
ROOT CAUSE COMMENTS FIELD An entry in the Root Cause Comments field is required. Categorizing the Injection Points, Detection Points, Defect Types, Defect Groups, and Cause Factors is useful in identifying trends, but by themselves these values do not identify specifically the factors that caused the error to occur or the action that should be taken to prevent the error from reoccurring. In the Root Cause Comments field, provide further information regarding the cause of the defect. Enter your PRIMUS userid at the end of the text. If the Defect Type was categorized as Interface (INT) and the Cause Factor was categorized as Lack of Tools (LOT), the Root Cause Comments field might read as follows: Example: Some changes were made to the interface between the ALGOL compiler and the Message Control System. Changes of this type are bound to cause interface problems unless thoroughly tested. However, because of a general lack of adequate tests in the test suite, this problem was not detected until after the product was released - DEVLZD
Unisys Confidential
Page 55 of 57
APPENDIX H G. CONTACT HANDLING
4310 8497
CONTACTs are like electronic mail in PRIMUS. CONTACTs may be used to communicate between different organizations and clients to assist in the resolution of client problems or to provide information. This appendix provides only a brief overview. For more complete information on CONTACT handling please refer to RSS-260 Tracker Process & Procedures Guide Sect 6. 1. Entering a CONTACT You may send a CONTACT to another engineering group, a support center, or a subsidiary. When a CONTACT is initially entered, two LOG-PART sections will be created, one for the initiator and one for the responder. o Click File New Document o Select entry activity CONTACT. o Select the appropriate Product. o Verify the initiator information copied from your USER document. o Select the appropriate Division (e.g. ENG for engineering, EAD for Europe-Africa Division, etc.) and for some Divisions you may select an Organization. o Select the correct Host Processor field. o Enter your request in the Headline and Description fields. o You have now entered all the mandatory fields. You may tab to the other fields and enter appropriate specific values. o If you do not wish to send this CONTACT yet, then change Log Disposition to OPEN o Close the document to save or send this CONTACT o Note the CONTACT number assigned by PRIMUS. 2. Creating a CONTACT from a UCF You may create a CONTACT based on the information in a UCF and PRIMUS will create a CONTACT with information copied from the UCF and will create two LOG-PART sections: one for your request and one for the responders reply. o Click the New Document button o Select Entry Activity CONTACT based on a UCF o Enter the ID number of the UCF, and click Proceed o Verify that the copied data are correct and enter your request/query in the Log Action field. o If you do not wish to send this CONTACT yet, then change Log Disposition to OPEN o Close the document to save or send this CONTACT o Note the CONTACT number assigned by PRIMUS. 3. Replying to CONTACTs Once you've determined the appropriate response to a CONTACT; o Open the CONTACT. o Select the Log Part tab and enter your response in the Log Action field. o Select an appropriate Log Reply Code (TECHNICAL QUESTION is used most often). o Enter the time (in minutes) spent on replying to this CONTACT in the Log Time Spent field o If everything is complete & correct, change Log Disposition to PASSED, and close the contact. Page 56 of 57 Unisys Confidential
43108497 4. Closing a CONTACT
APPENDIX H
CONTACTs initiated by a CSC or subsidiary can only be closed by that CSC or subsidiary. CONTACTs initiated by engineering can be closed by engineering To close an engineering initiated CONTACT; o Open the CONTACT o Set the Log-Disposition field, in the LOG-PART section queued to you, to CLOSED. o Close the document.
Unisys Confidential
Page 57 of 57

011

Încărcat de

Informații document

Descriere originală:

Titlu original

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

011

Încărcat de

Drepturi de autor:

Formate disponibile

PRIMUS Processing Guide

Approved for use by 8/30/2002 Ralph Farina (signature on file)

Paul Dowell Tredyffrin Net2 385-4187 Manager: J. Keeley Plant: Tredyffrin

PRIMUS PROCESSING GUIDE

Document Change Control History

PRIMUS PROCESSING GUIDE Table of Contents

PRIMUS PROCESSING GUIDE

PRIMUS PROCESSING GUIDE

4310 8497 Other 54

PRIMUS PROCESSING GUIDE

PRIMUS PROCESSING GUIDE

PRIMUS PROCESSING GUIDE

PRIMUS PROCESSING GUIDE

o Click File Close o Note the UCF number assigned by Primus

PRIMUS PROCESSING GUIDE

PRIMUS PROCESSING GUIDE

PRIMUS PROCESSING GUIDE

PRIMUS PROCESSING GUIDE

PRIMUS PROCESSING GUIDE

(Ref. RSS-260 Tracker Process & Procedures Guide Sect 7.9).

PRIMUS PROCESSING GUIDE

Give accompanying materials to the specialist assigned

PRIMUS PROCESSING GUIDE

PRIMUS PROCESSING GUIDE Materials Not Received

New Customer i) Resolved Problem

43108497 Responsibility: UCF-to-PLE:

PRIMUS PROCESSING GUIDE Queue Id of the handling specialist PLE number

Product level the duplicate UCF was

PRIMUS PROCESSING GUIDE

o Edit the UCF and update the following fields:

Log Time Spent: Log-Reply-Code:

PRIMUS PROCESSING GUIDE

PRIMUS PROCESSING GUIDE

PRIMUS PROCESSING GUIDE OPEN / 5

PRIMUS PROCESSING GUIDE

PRIMUS PROCESSING GUIDE

PRIMUS PROCESSING GUIDE

If the UCF is for an MORE INFORMATION timeout, the acceptor should:

PRIMUS PROCESSING GUIDE

PRIMUS PROCESSING GUIDE

PRIMUS PROCESSING GUIDE PROGRESS CODES

PRIMUS PROCESSING GUIDE

PRIMUS PROCESSING GUIDE A. UCF PROCESS POLICY

PRIMUS PROCESSING GUIDE

PRIMUS PROCESSING GUIDE B. CONTACT RESPONSIVENESS & RATING

From: Sent: Subject:

PRIMUS PROCESSING GUIDE

APPENDIX D C. SYSGEN PROCESS

PRIMUS PROCESSING GUIDE

PRIMUS PROCESSING GUIDE

PRIMUS PROCESSING GUIDE

PRIMUS PROCESSING GUIDE

PRIMUS PROCESSING GUIDE

PRIMUS PROCESSING GUIDE

PRIMUS PROCESSING GUIDE

PRIMUS PROCESSING GUIDE

PRIMUS PROCESSING GUIDE

43108497 Resolution-for-Level Same as Product Level. Resolution-Status

PRIMUS PROCESSING GUIDE

PRIMUS PROCESSING GUIDE

PRIMUS PROCESSING GUIDE

APPENDIX F Test Procedure: