Publication Date: 16 February 1996
System Version: GCCS 2.1/Update 4
Web Page Created: 26 March 1996
Purpose. The purpose of the Global System Problem Report (GSPR), DISA Form 291, is to provide feedback to system developers about any problems experienced in GCCS. The form provides information similar to the Incident Report (IR) used in WWMCCS. The following instructions are provided for your use.
1. Block I.a. OPERATING ENVIRONMENT INFORMATION. This block is used to identify the site experiencing the problem and the GCCS System Release under which the problem occurred.
b. Item 2: Control Number - This will be assigned by Hot Line/Incident Control Center (ICC) personnel upon receipt of the problem report. (See para 2.a., Block I.b., Item 8, below for information concerning site identification of problem reports.)
c. Item 3: System Release Identifier - This field MUST contain the identifier of the GCCS release within which the problem occurred. The format is G followed by the numerical release identifier (e.g., G1.).
d. Item 4 & 5: - n/s for GCCS.
e. Item 6: Subsystem and Release - If the problem is with an operating system (Solaris, DOS, UNIX), enter the operating system name and the release identifier (maximum 15 characters).
f. Item 7: Suspect Component - If Item 6 has been entered, note the component within the operating system suspected to have caused the problem (optional).
2. Block I.b. APPLICATION SOFTWARE INFORMATION. This block is used to identify the application package in operation at the time the problem occurred.
b. Item 9: CSCI/System Name - This field is used to identify the Computer Software Configuration Item (CSCI) of the application, if known, or its common name (e.g., APPLIX, DART, GSORTS, JMCIS).
c. Item 10: Release Identifier - Enter the release identifier of the application identified in Item 9 (e.g., 3.4.1 for DART, 2.1.2.1 for JMCIS).
d. Item 11: Subsystem and Release - Some CSCIs have subsystems with unique release identifiers. If appropriate, provide this information here. (Optional).
e. Item 12: Publisher, Vendor, or Developer - If known, enter the organization or agency responsible for maintenance of this product. (Optional).
3. Block II. GENERAL INFORMATION. This block is used to record specific information regarding the nature of the problem and the product within which the problem occurred.
b. Item 14: Date of Problem - Enter the date the problem was first discovered. Please use the format DD Mon YY (e.g., 12 Mar 94).
c. Item 15: Date of Report - Enter the date of GSPR completion. Please use the format DD Mon YY (e.g., 12 Mar 94).
d. Item 16: This Problem... - THIS IS IMPORTANT INFORMATION. Check whether the problem can be duplicated at will or was a single/random occurrence which cannot be duplicated at will. Also check whether this problem first appeared in the software identified in a previous release.
e. Item 17: Report Class - Check PR for a problem report, CR for a change request.
f. Item 18: Report Category - Check A if the software does not function according to supplied documentation and the documentation is correct; B if the software does not function according to supplied documentation and the software is correct; or C if the software functions according to supplied documentation but a design deficiency exists. Note that a design deficiency may not result in a directly observable operational symptom but possesses the potential for creating further problems. (Category C problems should be reported as Change Requests).
g. Item 19: Life Cycle Phase - Site-submitted GSPRs should be marked O (Operational), unless the site is acting in a Beta test capacity, in which case they should be marked T (Testing).
h. Item 20: Product Category - Guidance for what GCCS systems fall into which categories will be forthcoming.
i. Item 21: Product Type - Guidance for what GCCS systems fall into which product types will be forthcoming.
4. Block III. ORIGINATOR/POINT OF CONTACT INFORMATION. This block identifies the problem report originator or a designated POC for this problem. It must include the person's name, organization, complete mailing address, and a telephone number at which this person can be reached for clarification of the problem, additional information required to resolve the problem, and/or feedback to the originator/POC concerning the resolution of the problem. All items are self-explanatory.
5. Block IV. PROBLEM DESCRIPTION. This block is used to provide a short (maximum 60 character) statement as to the nature of the problem (Item 31: Title) and a complete, concise, detailed description of the problem, the circumstances under which the problem occurred, and any other information which may be useful in the resolution of this problem (Item 32: Description).
6. Block V. SUPPLEMENTAL MATERIAL. This block is used to identify any supporting documentation submitted with the problem which may assist in the resolution of this problem. Material may include dumps, listings, screen captures, data files, or any other material which may provide the analyst further information which may be useful in recreating the situation in which the problem occurred or which may provide objective support to information detailed in the problem description.
b. Item 34: Classification - Enter the appropriate security classification of each item. Items up to Top Secret may be submitted. Classified material MUST be appropriately controlled and submitted through proper channels. It is recommended that classified supplement material be marked with the reference number of the problem report to which it pertains, and that item 35 of the GSPR be annotated with some means of identifying the classified material when it arrives at the ICC.
c. Item 35: Medium/Identification/Description Information - Supplemental material may be submitted via hard or soft copy. This item is free text and should be used to document media type (e.g. hard copy, floppy disk, TAR tape); identification of the item (e.g. file name, job number); format (e.g. ASCII, WordPerfect 5.1); and/or any other specific means of identifying the item. This helps ICC personnel ensure that all items submitted have been received and are available to the analyst for proper analysis and resolution of the problem, as well as helping the analyst keep track of all items submitted with a problem report.
7. Block VI. CONTROL INFORMATION. This section will be completed by ICC personnel upon receipt of the problem report and assignment of the control number.
8. Verification - It is the policy of the ICC to provide a return copy of newly received problem reports to the originator following entry into the database. It is also ICC policy to provide a new problem report summary sheet to the originator whenever an update is made to the database. Periodic status reports can also be generated and delivered to the sites. Procedures for implementing these policies in the GCCS community are being worked and will be implemented at the earliest opportunity.
9. Submission - GSPRs can be submitted in a number of ways:
MAIL - Mail to: Incident Control Center Product Assurance Department 45335 Vintage Park Plaza Sterling VA 20166-6701 FAX - FAX to: Product Assurance Department/ICC (703) 735-8766 or DSN 653-8766 E-MAIL - PerFORM PRO data files (.fil) may be E-mailed to: steinbel@cc.ims.disa.mil starnese@cc.ims.disa.mil rederj@cc.ims.disa.mil NOTE: For those with DISA LAN connectivity, the GSPR is 1291.frl under W:\FORMS\DISAFORM
1. Problems of a critical nature (Priority 1) should be reported immediately to the GCCS Operational Support Center (GOSC):
2. The GOSC may also be contacted as above for general user assistance (How do I ....) questions.
3. For non-critical systemic problems, sites should complete a GSPR according to the guidance in this document and forward it to the ICC via one of the above described methods.