10/25/84 States Associated with TRs Three kinds of trouble reports (TRs) can be submitted by the user: problem reports, suggestions and questions. Problem reports are processed in three stages: verification, response, and resolution. Suggestions and questions are processed in one stage: resolution. For problem reports, the verification stage insures that the problem can be reproduced, and that it is an error rather than a feature of the system, etc. The response stage acknowledges that the problem exists, but make no commitment to fix the problem. The problem is added to an error file related to a specific area of the system. When a problem is acknowledged, its resolution stage makes a commitment to fix the problem in the next release, or to document it as a system limitation, and this commitment is added to the problem's error file entry. For a problem report which is not understood, not repeatable, or not really a system problem, the resolution stage asks for additional information about the problem, or explains why the reported item is not a problem. Suggestions are resolved at the time they are entered, since they do not require a response. However, if the developer choses to respond to a suggestion and the suggestion is accepted, it is added to the error file for the appropriate area of the system. For questions, the resolution stage answers the question. The following states are associated with each stage of TR processing. List of states for problem reports: entered, en the TR has just been submitted. investigating, iv TR personnel are trying to verify the report. verified, v TR personnel have reproduced problem. needs_info, ni there is insufficient information in the report to understand or isolate the problem. The response requests additional information which the submitter must supply. not_error, ner the problem is not a system error, and is probably a user error. The response explains what the user error is. error, er the problem has been noted in an error file. The error file name and error number must be given in the response. limitation, li the problem has been noted in an error file, and will be documented as a system limitation. The error file name and error number must be given in the response. change_pending, cp the problem has been noted in an error file. A fix for the problem is known and will be included in a future release. The error file name and error number must be given in the response. submitted, sub a fix for the problem has been submitted for installation in the system libraries (as oppposed to the EXL Library), and will be available in the next possible release or documentation update. deferred, df work on a normal priority problem has been deferred until resources are available. This state cannot be used for high or critical problems. It should only be used for TRs which have a minimal impact on individual users and on sites as a whole. List of states for suggestions: entered, en the report has been entered and routed to appropriate developer for a response. investigating, iv the developer is investigating the merits of the suggestion. needs_info, ni there is insufficient information in the report to understand what is being suggested. accepted, a for suggestions only, the suggestion has been accepted and will be implemented when time permits. The suggestion is noted in the appropriate error file. The response must give the error file name and error number. rejected, r for suggestions only, the suggestion has been rejected and will not be implemented. The response must give the reasons for rejection. change_pending, cp the suggestion is being implemented and will be included in a future release. submitted, sub the suggested change has been submitted for installation in the system libraries (as oppposed to the EXL Library), and will be available in the next possible release or documentation update. List of states for questions: entered, en the question has just been asked. investigating, iv the question has been routed to a developer for an answer. answered, ans the answer for the question is given in the associated transaction. needs_info, ni the question is not understood. The developer asks the submitter for specific information in the transaction associated with this state. Completion codes: A completion code is associated with each state value, as shown in the tables below, to group the state values into one of the three stages of TR processing. Completion codes for problems: STATE COMPLETION CODE entered entered investigating entered verified verified error responded limitation responded change_pending responded submitted resolved not_error resolved needs_info resolved deferred resolved Completion codes for suggestions: STATE COMPLETION CODE entered entered & resolved investigating resolved accepted resolved rejected resolved needs_info resolved change_pending resolved submitted resolved Completion codes for questions: STATE COMPLETION CODE entered entered investigating entered needs_info resolved answered resolved Notes: Developers should refer to MAB-049-01 for a more complete description of these states, including scenarios illustrating their use. ----------------------------------------------------------- Historical Background This edition of the Multics software materials and documentation is provided and donated to Massachusetts Institute of Technology by Group BULL including BULL HN Information Systems Inc. as a contribution to computer science knowledge. This donation is made also to give evidence of the common contributions of Massachusetts Institute of Technology, Bell Laboratories, General Electric, Honeywell Information Systems Inc., Honeywell BULL Inc., Groupe BULL and BULL HN Information Systems Inc. to the development of this operating system. Multics development was initiated by Massachusetts Institute of Technology Project MAC (1963-1970), renamed the MIT Laboratory for Computer Science and Artificial Intelligence in the mid 1970s, under the leadership of Professor Fernando Jose Corbato. Users consider that Multics provided the best software architecture for managing computer hardware properly and for executing programs. Many subsequent operating systems incorporated Multics principles. Multics was distributed in 1975 to 2000 by Group Bull in Europe , and in the U.S. by Bull HN Information Systems Inc., as successor in interest by change in name only to Honeywell Bull Inc. and Honeywell Information Systems Inc. . ----------------------------------------------------------- Permission to use, copy, modify, and distribute these programs and their documentation for any purpose and without fee is hereby granted,provided that the below copyright notice and historical background appear in all copies and that both the copyright notice and historical background and this permission notice appear in supporting documentation, and that the names of MIT, HIS, BULL or BULL HN not be used in advertising or publicity pertaining to distribution of the programs without specific prior written permission. Copyright 1972 by Massachusetts Institute of Technology and Honeywell Information Systems Inc. Copyright 2006 by BULL HN Information Systems Inc. Copyright 2006 by Bull SAS All Rights Reserved