z-logo
open-access-imgOpen Access
A note on Program Debugging in an On-Line Environment
Author(s) -
D. W. Barron
Publication year - 1969
Publication title -
the computer journal
Language(s) - English
Resource type - Journals
SCImago Journal Rank - 0.319
H-Index - 64
eISSN - 1460-2067
pISSN - 0010-4620
DOI - 10.1093/comjnl/12.1.104
Subject(s) - debugging , programming language , computer science , line (geometry) , operating system , algorithmic program debugging , mathematics , geometry
It is commonly asserted that one of the main benefits of an on-line system is that it simplifies the task of getting a program to work: indeed, this has become part of the gospel of multi-access. This note examines this assertion, and suggests that it is true, though not for the reasons usually given. The obvious advantages of a multi-access system are twofold: a filing system that allows programs to be stored and readily altered, and almost instant access to the machine for test runs. Anyone who has used such a system for program development will testify that these are great benefits; however, comparable benefits can be obtained at less cost. Programs on punched cards can be modified fairly easily, and a full-scale filing system can be maintained quite separately from a remote console system. The same goes for access to the machine: given a ten-minute turnround on test runs most programmers would be happy, and it is certain that many of the people in universities who ask for multi-access really want rapid turnround. Though most conventional systems provide a turnround measured in hours or even days, this should not obscure the fact that rapid turnround can be achieved without a full-scale remote console system/ ' However, supposing that we have a multi-access system available, with a filing system and instant turnround, what do we pay (in programmer convenience, not machine efficiency) for these benefits ? The most significant trade-off is that since we are communicating with the machine through a narrow bandwidth channel, we are restricted in what we get from the machine to what can be printed in a reasonable time at ten characters per second. No listings, no core dumps: with a compiler that was written for off-line use, this makes life difficult. The minimal facility necessary is the ability to record a core-dump in a file, for later examination. If on-line debugging is to be effective one needs an elaborate interrogation program which can access the core dump and

The content you want is available to Zendy users.

Already have an account? Click here to sign in.
Having issues? You can contact us here
Accelerating Research

Address

John Eccles House
Robert Robinson Avenue,
Oxford Science Park, Oxford
OX4 4GP, United Kingdom