TL;DR: The design considerations for the architectural extensions that distinguish System/370 from System/360 are discussed, which covers virtual storage, program control, data-manipulation instructions, timing facilities, multiprocessing, debugging and monitoring, error handling, and input/output operations.
Abstract: This paper discusses the design considerations for the architectural extensions that distinguish System/370 from System/360. It comments on some experiences with the original objectives for System/360 and on the efforts to achieve them, and it describes the reasons and objectives for extending the architecture. It covers virtual storage, program control, data-manipulation instructions, timing facilities, multiprocessing, debugging and monitoring, error handling, and input/output operations. A final section tabulates some of the important parameters of the various IBM machines which implement the architecture.
TL;DR: In this paper, a theoretical framework based on cognitive psychology on memory for text was developed to explain certain aspects of human behavior during computer program comprehension and debugging, and it was found that the difficulty in finding a program bug is a function of the bug's location in this hierarchy.
Abstract: : A theoretical framework, based upon recent studies in cognitive psychology on memory for text, was developed to explain certain aspects of human behavior during computer program comprehension and debugging. A central concept of this framework is that the information contained in a program is represented in a programmer's memory as a connected, partially ordered list (hierarchy) of 'propositions' (units of information with properties similar to those observed in research on text memory). An experiment was performed to test the hypothesis that the difficulty in finding a program bug is a function of the bug's location in this hierarchy. This experiment compared the effects of bug location, bug type (array, iteration, assignment) and specific program. Each of 48 subjects debugged two separate programs, with one type of bug at two different hierarchical levels in each program. A preliminary analysis suggested that all three factors -- program, bug type, and bug location -- significantly affected the time required to locate program bugs. Detailed analyses, however, suggested the program and bug type variables could be explained in terms of the bug location variable and the a bug's location in a program's underlying propositional hierarchy is a principal factor affecting performance in a comprehension and debugging task.
TL;DR: Techniques derived from mathematical logic promise to provide an alternative to the conventional methodology for constructing, debugging, and optimizing computer programs.
Abstract: Techniques derived from mathematical logic promise to provide an alternative to the conventional methodology for constructing, debugging, and optimizing computer programs. Ultimately, these techniques are intended to lead to the automation of many of the facets of the programming process.
TL;DR: Several metrics have been devised which, when applied to design structure charts, can pinpoint sections of a design that may cause problems during coding, debugging, integration, and modification and can provide an independent, unbiased evaluation of design quality.
Abstract: It has been recognized that success in producing designs that realize reliable software, even using Structured Design, is intimately dependent on the experience level of the designer. The gap in this methodology is the absence of easily applied quantitative measures of quality that ease the dependence of reliable systems on the rare availability of expert designers.Several metrics have been devised which, when applied to design structure charts, can pinpoint sections of a design that may cause problems during coding, debugging, integration, and modification. These metrics can help provide an independent, unbiased evaluation of design quality. These metrics have been validated against program error data of two recently completed software projects at Hughes. The results indicate that the metrics can provide a predictive measure of program errors experienced during program development.Guidelines for interpreting the design metric values are summarized and a brief description of an interactive structure chart graphics system to simplify metric value calculation is presented.
TL;DR: Firmware engineering, in analogy to software engineering, covers the specification and design of microprograms, construction techniques, debugging, testing, verification, and maintenance.
Abstract: Firmware engineering, in analogy to software engineering, covers the specification and design of microprograms, construction techniques, debugging, testing, verification, and maintenance. Here is a look at the current state of the art and coming trends.
TL;DR: The microprocessor support system as mentioned in this paper provides a total "laboratory" environment for developing and testing application software as well as for debugging the microprocessor-based application machine itself.
Abstract: The disclosed microprocessor support system provides a total "laboratory" environment for developing and testing application software as well as for debugging the microprocessor-based application machine itself. The microprocessor support system contains a time shared minicomputer equipped with a full set of peripherals which functions as the main or operating system. A data link connects this operating system with test equipment located at the site of the application machine. This test equipment consists of a field test unit which provides an interface between the application machine, a local keyboard terminal and the operating system such that an engineer at the site of the application machine has access through the field test unit to both the microprocessor-based application machine and the operating system with its sophisticated hardware and software resources to assist in developing and testing application software, as well as debugging the application machine itself.
TL;DR: XS-0 is a low-cost interactive system that serves as a self-explanatory school computer that includes a course on computer programming, a programming system for writing, editing, executing, and debugging programs interactively, and a filing system containing private and public libraries.
Abstract: XS-0 is a low-cost interactive system that serves as a self-explanatory school computer. Particular attention has been devoted to making the man-machine dialog easy to follow for the inexperienced user. The system includes a course on computer programming, a programming system for writing, editing, executing, and debugging programs interactively, and a filing system containing private and public libraries. The language offered to the user is a version of Pascal. The system is realized on a small stand-alone computer which supports a small number of graphic terminals. This hardware consists of the most cost effective components currently on the market.
TL;DR: By making event associations available at the source‐language level, debugging aids can be written in SNOBOL4 itself, using the full capabilities of that language, and a basis for the addition of other events.
Abstract: An event association facility for the SNOBOL4 programming language is described. This facility permits the execution of a programmer-defined function to be associated with the occurrence of a specified event. The events with which associations can be made are those applicable to program debugging. Associations can be made with events such as variable referencing, statement execution, program interruption, function call and return, and execution-time errors. By making event associations available at the source-language level, debugging aids can be written in SNOBOL4 itself, using the full capabilities of that language. As illustrated by several examples, this approach facilitates the implementation of simple yet powerful debugging aids written in the same language as the programs to be debugged. Event associations provide a mechanism for the unification of the existing SNOBOL4 debugging facilities, and a basis for the addition of other events. The implementation of event associations is also described.
TL;DR: A model for the operational phase of a software system which incorporates the uncertainty of error removal and the time spent in correcting errors is developed and expressions for various measures of software performance are derived.
Abstract: In this paper we develop a model for the operational phase of a software system which incorporates the uncertainty of error removal and the time spent in correcting errors. Expressions for various measures of software performance, e.g. distribution of time to a specified number of remaining errors, the expected number of errors detected and corrected in time t, and software system availability are derived. Numerical examples are used to illustrate these results.
TL;DR: A program profiling system for the language Algol 68‐R that provides deterministic information concerning the run‐time behaviour of certain AlGol language constructs is described.
Abstract: A program profiling system for the language Algol 68‐R is described. The system provides deterministic information concerning the run‐time behaviour of certain Algol language constructs. This is accomplished by preprocessing program texts prior to compilation using a syntax analyzer for Algol 68‐R.
TL;DR: The research focused on the role of general strategies in troubleshooting/debugging and how they might be represented and taught explicitly and directly in order to avoid the cost and other drawbacks of learning indirectly by observation and practice.
Abstract: : Although the need for competent technicians who can maintain and repair complex systems is increasing present methods of teaching troubleshooting/debugging remain primitive and expensive, relying on students to discover effective and efficient problem-solving methods by observation and practice in relatively unstructured environments. The goal of the present project was to identify the types of knowledge necessary and useful for competent troubleshooting/debugging and to examine how new approaches to formal instruction might influence the attainment of competence by students. In particular, the research focused on the role of general strategies in troubleshooting/debugging and how they might be represented and taught explicitly and directly in order to avoid the cost and other drawbacks of learning indirectly by observation and practice. Analysis suggests that debugging is a fundamental aspect of almost all learning and problem solving. One result of the analysis was the formulation of an information-processing model of a general troubleshooting/debugging strategy, which describes the types of reasoning processes needed, some of the factors governing selection of alternative processes in solving a problem, and an explicit control strategy.
TL;DR: A software support system for a network of minicomputers and microcomputers is described and some examples of how the SPS is used in various projects at Bell Laboratories are described.
Abstract: A software support system for a network of minicomputers and microcomputers is described. A powerful time-sharing system on a central computer controls the loading, running, debugging, and dumping of programs in the satellite processors. The fundamental concept involved in supporting these satellite processors is the extension of the central processor operating system to each satellite processor. Software interfaces permit a program in the satellite processor to behave as if it were running in the central processor. Thus, the satellite processor has access to the central processor's I/O devices and file system, yet has no resident operating system. The implementation of this system was considerably simplified by the fact that all processors, central and satellite, belong to the same family of computers (DEC PDP-11 series). We describe some examples of how the SPS is used in various projects at Bell Laboratories.
TL;DR: Some rough guidelines for quantifying the size, difficulty, budget levels, and expected results of systematic software testing are presented.
Abstract: Software testing techniques are seen as the only currently viable alternative to problems of deficient software Quality. Testing methods focus on demonstrating the correct (proper) operation of a software system, using methods that also assure a thorough search for program "errors" has been accomplished. The possible alternative organizational schemes, and some insights into the psychology of testing are presented. In addition, some rough guidelines for quantifying the size, difficulty, budget levels, and expected results of systematic software testing are presented.
TL;DR: Here is an implemented systems CAN, which understands LISP programs, and the set of rules which implement this knowledge is represented as a unification process, called META-PATTERN-MATCHING, which handles "constrained segment variables".
Abstract: Presented is an implemented systems CAN, which understands LISP programs. The system is a program debugging tool and is intended to use procedural knowledge about concrete list structures. The set of rules which implement this knowledge is represented as a unification process, called META-PATTERN-MATCHING, which handles "constrained segment variables".
Dealing with the "visual aspects" of data structures, the system CAN is useful as the programmers' assistant.
TL;DR: In this paper, the number of occurrences of negative program loops is detected and the number is recorded, thereby finding programing mistakes easily in program debugging and finding program loops generated by nonsmoking programs.
Abstract: PURPOSE:Resepctive program loops generated actually is detected, and furthermore the number of occurrence is recorded, thereby finding programing mistakes easily in program debugging.
TL;DR: CAD techniques, including fully automatic layout capabilities for VLSI devices and the application of a CMOS-SOS microprocessor and methods for debugging critical race and delay variations are described.
Abstract: This paper will describe CAD techniques, including fully automatic layout capabilities for VLSI devices and the application of a CMOS-SOS microprocessor. Methods for debugging critical race and delay variations will also be discussed.
TL;DR: ASSIST-V is a program that provides an environment for the implementation, testing, and evaluation of systems software for the IBM 360 series machines by simulating all relevant aspects of the machine's architecture.
Abstract: This paper describes ASSIST-V, a software tool designed for use in the teaching of operating systems, fie management, and machine architecture courses. ASSIST-V is a program that provides an environment for the implementation, testing, and evaluation of systems software for the IBM 360 series machines. This capability is achieved by simulating all relevant aspects of the machine's architecture. In particular, ASSIST-V simulates interrupts, I/O channels, and I/O devices, as well as all IBM 360 machine instructions. In addition, ASSIST-V provides extensive debugging and statistics-gathering aids.
TL;DR: In this article, the authors present the results of a quantitative investigation into the optimum selection of screening and debugging methods for the purpose of removing defects, and hence improving reliability, throughout the development process.
Abstract: : This report presents the results of a quantitative investigation into the optimum selection of screening and debugging methods for the purpose of removing defects, and hence improving reliability, throughout the development process. A computerized optimization model has been developed which can be used to address three problem areas; (1) Select an optimum sequence of screens for a fixed dollar expenditure, (2) Select a sequence of screens which minimizes costs in the face of a fixed desired reliability improvement, and (3) Provide quantitative for performing screening/debugging tradeoffs. In order to implement the model it was necessary to obtain data to compute test strengths and test costs. The model includes four assembly levels, five types of screens (temperature cycling constant temperature, vibration constant power and power cycling), provides for introduction of defects at each assembly level and includes the rework cycle.
TL;DR: The interactive interpreter can be used as a self-contained microprogramming interpreter or as a debugging tool to allow ECLIPSE users to develop their own microroutines.
Abstract: MICROSIM is an interactive program which simulates the Data General ECLIPSE microprogramming feature. It interprets microprograms written in the ECLIPSE microinstruction's format and produces results, error messages and complete (or specific) trace information according to the user's commands. The interactive interpreter can be used as a self-contained microprogramming interpreter or as a debugging tool to allow ECLIPSE users to develop their own microroutines.
TL;DR: A suitable programming language called MIKRO has been developed and the appropriate assembler has been implemented to allow an economical usage of these facilities, and a comfortable simulator is under construction.
TL;DR: The NCR Criterion Cobol System as discussed by the authors implements an indirect higher level language machine for 1974 ANSI Cobol in a conventional microprogrammed environment, permitting, execution of a single run unit composed of both Cobol and other language modules in a highly efficient manner.
Abstract: Higher level programming languages provide problem solvers an access to computers without requiring them to become computer experts. In the traditional environment, compilers perform the relatively complex translation from the higher level language statements into the machine instructions. The differences between the complex data structures and operations of languages and typical simple structures of machines makes this a wide chasm to bridge. The mismatch between data and operations of the languages and machines appears clearly when one considers a language such as Cobol, APL, PL/I or Snobol4. In each of these, the fundamental operations and even basic data types do not translate easily because the language design depends on no one machine. The implementor must build mechanisms ranging from full software interpreters to elaborate subroutine libraries to perform the higher level language operations on higher level language data. Despite the costs, the payoffs of using higher level languages make them worthwhile. And with the widespread use of microprogrammable processors as the base of computing systems, designers can realize the once primarily theoretical higher level language machines. 1 An interpreter for the operations of a higher level language, written in firmware rather than software becomes a higher level language machine. The NCR Criterion Cobol System implements an indirect higher level language machine for 1974 ANSI Cobol in a conventional microprogrammed environment, permitting , execution of a single run unit composed of both Cobol and other language modules in a highly efficient manner. The system consists of a microprogrammed hardware processor supporting both conventional and Cobol machine firmware in a multiple virtual machine environment, a multiprogramming virtual resources operating system, a 1974 ANSI Cobol compiler designed to run in a virtual storage environment, the necessary execution time support subsystems and routines, and Cobol symbolic debug and runtime tuning subsystems. The discussion focuses on the characteristics of the system as a Cobol environment and the structure of the Cobol virtual machine, the compiler, and the support subsystems.
TL;DR: In this article, the authors propose to simply and visually check the change of the address information timingly, by converting the content of address registers into an analog signal and by visually displaying it, in debugging or maintenance.
Abstract: PURPOSE:To simply and visually check the change of the address information timingly, by converting the content of address registers into an analog signal and by visually displaying it, in debugging or maintenance.
TL;DR: In this article, the authors propose to elevate the efficiency for program debugging, by restarting an information processing equipment automatically, and also collecting a debugging information, by setting a debugging instruction information to a debugging indicator.
Abstract: PURPOSE:To elevate the efficiency for program debugging, by restarting an information processing equipment automatically, and also collecting a debugging information. CONSTITUTION:As for a program which is executed by an information processing equipment 1 and has ended abnormally, an execution state of the program is decided by a restart deciding mechanism 2. In case when its decision effect shows that the re-execution is possible and effective, the restart deciding mechanism 2 sets a debugging instruction information for collecting a debugging information, to a debugging indicator 3. The information processing equipment 1 restarts a program by a restart instruction information in this debugging instruction information, and a debugging information collecting mechanism 4 re-execute a program, collecting a debugging information in accordance with a collecting instruction information of the debugging instruction information which has been set to the debugging indicator 3.
TL;DR: In this paper, a function capable of switching rapid feeding speeds in plurality stages was proposed to prevent dangerous state resulted upon debugging with no troubles to the machine performance by the provision of a function.
Abstract: PURPOSE:To prevent dangerous state resulted upon debugging with no troubles to the machine performance by the provision of a function capable of switching rapid feeding speeds in plurality stages.
TL;DR: In this article, a comparison between the switching state of address setting and the address state sent from CPU is made by having a continous operation of CPU until a coincidence is secured from the comparison.
Abstract: PURPOSE:To shorten the debugging time by having a comparison between the switching state of address setting and the address state sent from CPU and by having a continous operation of CPU until a coincidence is secured from the comparison.
TL;DR: The library control program (SYSM) presented here was developed to aid in the control of the software and has facilities for capturing all elements of a program, editing any element or group of elements that have been baselined to build an updated version of the program, and listing the current contents of a given element or elements.
Abstract: One of the major problems encountered in any large scale programming project is the control of the software. Invariably, such large programs are divided into many smaller elements since these are easier to code, test and document. However, such a division adds new complexity to the task of Configuration Management since the many source modules, data base elements, JCL (Job Control Language) and DATA files must be controlled with the goal of maximizing program integrity and minimizing the chances of procedural errors. Furthermore, whenever any program is released either for field test or for final production, an entire change control procedure must be implemented in order to trace, install, debug and verify fixes or extensions to the original program. These maintenance activities can account for up to 80 percent of the entire programming cost in a large, multi-year project. The library control program (SYSM) presented here was developed to aid in these processes. It has facilities for capturing all elements of a program (commonly called baselining), editing any element or group of elements that have been baselined to build an updated version of the program, adding and/or deleting elements of a program, and listing the current contents of a given element or elements. SYSM is written mainly in FORTRAN, and runs on a Hewlett-Packard HP-21MX computer with two tape drives, the vendor supplied RTE-II or RTE-III operating system, and at least 16K of user available core. It can be used to control code targeted for either the HP21MX itself, or, using the optional HP/LSI-11 link program, code targeted for a Digital Equipment Corp. LSI-11 system.
TL;DR: The role of high-level languages and real-time operating systems when minicomputers are used in the field of scientific instrumentation and comparative information is given on the advantages and disadvantages of the main high- level languages currently in use in the scientific environment.
Abstract: This review discusses the role of high-level languages and real-time operating systems when minicomputers are used in the field of scientific instrumentation. Comparative information is given on the advantages and disadvantages of the main high-level languages currently in use in the scientific environment. Information on high-level languages and real-time operating system facilities available on current minicomputers was obtained by sending a questionnaire to all major suppliers in the United Kingdom. To help to give a proper overview of the role of high-level languages and real-time operating systems, sections have been included in the paper on interrupt systems, benchmarks (speed tests), emulators, certain hardware facilities, instrumentation which already utilises minicomputers, diagnostic for and debugging of real-time programs, user groups, program packages, job control languages, interfacing, computer peripherals and microprocessors.
TL;DR: Two different approaches to the implementation of debugging aids used for efficiently tracking down both hardware and software faults during the development stage of microprocessor-based digital systems are described.
TL;DR: In this paper, the authors propose to decrease the debugging time by applying the data judged as abnormal one under a debugging function of each of the steps to each step when a program comprised of a plurality of steps having a unit of processing and judging functions is to be checked.
Abstract: PURPOSE:To decrease the debugging time by applying the data judged as abnormal one under a debugging function of each of the steps to each of the steps when a program comprised of a plurality of steps having a unit of processing and judging functions is to be checked.