Joss variant for remote computing 

for TELetype Computing

BBN JOSS variant

Developed to facilitate online programming as part of BBN's foray into creating subsidiary companies. The offshoot company itself was called TELCOMP, and operated in the area of Mass around BBN labs

Version 1 on the PDP-6 had no on-line storage for either programs or data (PDP-6 because JOSS-II was PDP-6). TELCOMP programs were normally input via a paper tape reader on a Teletype (such as the ASR-33) which would be connected to a PDP via a modem and acoustic telephone line. Data could be read from the paper tape reader or from the Teletype keyboard. Output was either printed to the Teletype or sent to the paper tape punch.

Used as part of the UCL Timeshare System, mentioned in Conversational Systems

Used by BBN by Feurzeig et al to do the research that led to the esatablishment of LOGO. (Although LOGO was ultimately implemented in LISP)

TELCOMP Commands (largely JOSS II)
A TELCOMP program was made up of numbered lines, each line referred to as a Step.
Steps were grouped into Parts. Each line contained one instruction.

DEMAND Read input from the teletype
DO PART Execute all of the steps in a numbered part
DO STEP Execute a single line
DONE Stop execution of current part and return to caller
IF Condition, suffixed to any instruction
FOR Loop, suffixed to any instruction
PLOT Type output to the teletype in the form of a graph
PRINT Print output to the teletype
READ Read input from the paper tape reader
SEND Send output to the paper tape punch
SET Assign a variable to the value of an expression
STOP Stop execution completely
TO PART Go to a specified part
TO STEP Go to a specified line
TYPE emulate input for stored code
; Comment, suffixed to any line
FORM A specification for formatted output

Related languages
BBN JOSS => TELCOMP   Evolution of
TELCOMP => FILECOMP   Augmentation of
TELCOMP => LOGO   Written using
TELCOMP => STRINGCOMP   Evolution of
TELCOMP => TELCOMP II   Evolution of
TELCOMP => Tymeshare TELCOMP   Commercialisation of

  • Myer, T. H., "Manual for Users: TELCOMP Computation Service", Bolt Beranek and Newman Inc., Cambridge, Mass. (Oct., 1966). view details
  • Clapp, Lewis "Time-Sharing System Scorecard" Computer Research Corporation 1967 view details
  • Myer, T. H. "TELCOMP manual" Cambridge, MA: Bolt Beranek and Newman 1967 view details
  • O'Sullivan, Thomas C. "Exploiting the time-sharing environment" pp169-175 view details Extract: intro
    For the past two years, Raytheon Space and Information Division at Sudbury, Massachusetts has been exploiting the time-sharing environment for the benefit of its scientists and engineers. At first, a single terminal was rented and tied into a remotely located service offered by Bolt, Beranek, and Newman in Cambridge, Massachusetts. It was felt that as usage increased, additional terminals would be added to make use of the central computer. We were wrong. Before we needed a second terminal, the users required a second type of service. As the work load increased, a second terminal was added, but by then users were asking that a third type service be added.
          in Proceedings of the 22nd national ACM conference 1967, Washington, D.C. view details
  • Greenes, R A; Pappalardo, A N; Marble, C W; Barnett, G O "Design and implementation of a clinical data management system" pp469-485 view details Extract:
    All application programs in this system are written in a high level interpretive language, a distant ancestor of which is JOSS,17 developed at the Rand Corporation in 1964. It has also been influenced by related languages such as TELCOMP and STRINGCOMP (developed by Bolt, Beranek and Newman, Inc.) and FILECOMP (specified by Medinet Division of General Electric Corp.). The MUMPS language allows the programmer to write a program, debug it, edit it, run it, and modify it concurrently at an interactive session at a console. The interpreter itself is a part of the executive system and is reentrant. The total space taken up by the time-sharing monitor, the input/output monitor, buffers, and reentrant interpreter is currently about 8,000 words of memory. The timesharing and I/O monitors have been specifically tailored to work efficiently with the interpreter. No attempt has been made to accommodate machine language user programs.

          in Computers and Biomedical Research 2(5) October 1969 view details
  • Mulholland, KA "Software to translate TELCOMP programs into KDF9 ALGOL" pp221-224 view details Abstract: A translator has been written that enables programs written in TELCOMP and dumped onto paper tape to be translated into KDF9 ALGOL programs also on paper tape. The paper describes the methods adopted in dealing with the various syntax analysis and translation problems that were encountered in writing the translator.
    External link: Online copy Extract: Introduction
    This paper describes a program written almost entirely
    in KDF9 ALGOL that will translate a source program
    written in one of the currently operational conversational
    languages TELCOMP into an object program in ALGOL
    text on paper tape ready for running. This allows the
    preparation of fault-free programs by means of conversational
    mode programming which may then be run on a
    larger, faster machine capable of accepting ALGOL.
    The translator is a two pass translator. In the first
    pass the standard functions are rendered into their
    equivalent ALGOL form or, if no equivalent exists, a
    procedure body is output on paper tape for inclusion in
    the object program.
    The various declarations real or array required by the
    object program are detected in the first pass and stored
    in a numerical form ready for output to the object
    program when the first pass is complete. To avoid
    overfilling the core store when a long program is to be
    translated each line of the source program is dealt with
    individually and then stored on magnetic tape. Extract: Aims of the program
    Aims of the program
    The primary object of the program was to accept any
    source program in TELCOMP 1 or 2 without restriction.
    The second aim was that the resulting ALGOL object
    program should be as close to normal ALGOL usage
    as would be consistent with the primary aim. Extract: The read procedure
    The read procedure
    The TELCOMP programs are run using a TELETYPE
    terminal, these terminals produce non-fixed
    parity IS0 code 8 hole paper tape. The English Electric
    KDF9 ALGOL compilers do not provide facilities to
    read mixed parity paper tape, and consequently input
    procedures were written in 'USERCODE' which is a low
    level language for the KDF9 computer. The input
    TELETYPE character code is translated to the internal
    KDF9 ALGOL basic symbol code by a directly addressable
    look-up table, operating during the transfer process.
    The look-up table is accessed by using the arbitrary
    numeric value of the input characters as a modifier
    address acting on the base address of the look-up table.
    Any odd characters, line feeds, carriage returns and
    erases are removed. The TELETYPE 'Control S'
    character is used to identify the end of a TELCOMP
    line of program.
    The TELETYPE paper tape character code has
    variations between the directly keyed program and that
    * Department of Building Science, University of Liverpool
    dumped up the line from the computer. Both codes
    have been made to produce a common sequence of basic
    The read in process is terminated by the presence
    of the word 'DUMPED' after a 'Control S' character
    which is the standard TELCOMP program terminating
    instruction. Extract: Types of instruction available in TELCOMP
    Types of instruction available in TELCOMP
    Each line of a TELCOMP program has a label. This
    is called a step number and it can lie in the range 1 to
    99.99999. This step number is followed by one instruction
    only. The instructions allowed are described in
    the TELCOMP manual (1967).
    Most of these instructions can be followed by a list of
    expressions separated by commas which are controlled
    by the instruction. These are explained as follows:
    SET A=B, C= 1 x SIN(TH), D=LN(l+E)
    These are assignment statements that when written in
    ALGOL 60 would appear thus:
    A:=B; C:=l + sin (TH); D:= In (l+E);
    The operation of the instructions DEMAND and
    READ are similar. DEMAND interrogates the user for
    the value of a variable, READ reads the variable off
    paper tape.
    The instruction:
    DEMAND A, B, C
    would appear in the object program as:

    A:=read(20); B:=read(20); C:=read(20);

    The instructions TYPE and PRINT are output
    instructions that have a high degree of flexibility via a
    FORM (or Format) statement that controls the layout
    of a line of information output via the TYPE or PRINT
    instruction. PLOT is similar although the output is in
    graphical form. And SEND is a tape punching instruction
    that can punch any binary number in the range 0-255
    on paper tape. These instructions can be matched by
    suitable ALGOL write commands except for the SEND
    facility which needs special treatment.

    DO and TO
    The instructions DO and TO are jump instructions.
    As previously stated a TELCOMP program is divided
    into steps. A group of step numbers each having the
    same whole number part is called a PART. A DO
    instruction can call either a whole PART or a part of a
    PART or a single STEP.
    The TO instruction is simpler in that control is not
    returned to the point at which the TO instruction
    occurred. Thus a TO statement can have only one
    expression following it and it is analogous to a goto
    statement in ALGOL 60.
    DONE and STOP
    DONE is an instruction that deems the current part
    number to have been done. Control is thus returned to
    the point at which the last DO statement occurred.
    The instruction STOP stops the action of the program
    entirely irrespective of the nesting of DO statements that
    may be current.
    Any of these instructions can be controlled by as many
    FOR or IF clauses as can be placed on one line. (Except
    that FOR cannot modify a TO instruction.)
    For example, the TELCOMP instruction
    TYPE A[I] IF A[I]> 1 FOR 1=1 : 1: 10, 20
    would appear as in KDF9 ALGOL as
    for I:= 1 step 1 until 10, 20 do
    if A01 [I] > 1 then
    write (device number, format statement, A01 [I])
          in The Computer Journal 12(3) 1969 view details
  • Sammet, Jean E. "Computer Languages - Principles and History" Englewood Cliffs, N.J. Prentice-Hall 1969. p.217. view details
          in The Computer Journal 12(3) 1969 view details
  • Barron, DW "Approaches to conversation FORTRAN" pp123-127 view details Abstract: This paper defines the term 'conversational programming system' in a pragmatic way by considering the facilities that the user expects to see in such a system. The difficulties of implementation are discussed, in the context of developing an outline design for a conversational FORTRAN system that makes a reasonable compromise between flexibility and efficiency. Extract: Introduction
    Conversational programming systems are enjoying a great
    vogue at present. Commercial time-sharing services are doing
    good business, and following the success of systems such as
    BASIC and of JOSS (alias TELCOMP alias JEAN) 'conversational
    FORTRAN' and 'conversational ALGOL' are being
    offered. However, these terms are not particularly well defined.
    Very often, all that is provided is a simple editing facility for
    source programs and an ability to communicate with the teleprinter
    at run-time, coupled to a more-or-less standard 'batch'
    compiler. (In one system of the author's acquaintance, the user
    of the conversational FORTRAN system is required to type
    his program as formatted card images, without the benefit of
    a TAB mechanism.)
    Another term that is used in this connection is 'incremental
    compiling', again, often without a clear definition. In this paper
    we aim to define the term 'conversational programming system'
    in a pragmatic way by considering the facilities that the user
    might expect to see. We then discuss various ways of achieving
    this for a FORTRAN-like language, including incremental
    compilation, and suggest a system that combines the external
    features that the programmer wants with reasonable internal
    efficiency. (As will be seen, this does not necessarily imply a
    fully interactive compiler.) Extract: City Conversational FORTRAN
    A few years ago a FORTRAN system was developed for student work at The City University: in order to achieve good diagnostics this system employed many of the techniques outlined in this paper, although it was intended for batch use. Unfortunately, no description of this significant piece of work was published at the time.
          in The Computer Journal 14(1) 1971 view details
  • Bull, G.M. and Packham, S.F.G., Time-Sharing Systems, McGraw-Hill, 1971 view details Abstract: The purpose of this book is to bring together all the major aspects associated with the development and evaluation of time-sharing systems, with the main emphasis on highly interactive, multi-language, general purpose time-sharing systems. All aspects of interactive time-sharing systems are covered in a single volume, including user facilities, implementation techniques, system management, and evaluation; complete documentation of an actual case study is also given
          in The Computer Journal 14(1) 1971 view details
  • Stock, Karl F. "A listing of some programming languages and their users" in RZ-Informationen. Graz: Rechenzentrum Graz 1971 266 view details Abstract: 321 Programmiersprachen mit Angabe der Computer-Hersteller, auf deren Anlagen die entsprechenden Sprachen verwendet werden kennen. Register der 74 Computer-Firmen; Reihenfolge der Programmiersprachen nach der Anzahl der Herstellerfirmen, auf deren Anlagen die Sprache implementiert ist; Reihenfolge der Herstellerfirmen nach der Anzahl der verwendeten Programmiersprachen.

    [321 programming languages with indication of the computer manufacturers, on whose machinery the appropriate languages are used to know.  Register of the 74 computer companies;  Sequence of the programming languages after the number of manufacturing firms, on whose plants the language is implemented;  Sequence of the manufacturing firms after the number of used programming languages.]
          in The Computer Journal 14(1) 1971 view details
  • Sammet, Jean E., "Roster of Programming Languages 1972" 286 view details
          in Computers & Automation 21(6B), 30 Aug 1972 view details
  • Stock, Marylene and Stock, Karl F. "Bibliography of Programming Languages: Books, User Manuals and Articles from PLANKALKUL to PL/I" Verlag Dokumentation, Pullach/Munchen 1973 615 view details Abstract: PREFACE  AND  INTRODUCTION
    The exact number of all the programming languages still in use, and those which are no longer used, is unknown. Zemanek calls the abundance of programming languages and their many dialects a "language Babel". When a new programming language is developed, only its name is known at first and it takes a while before publications about it appear. For some languages, the only relevant literature stays inside the individual companies; some are reported on in papers and magazines; and only a few, such as ALGOL, BASIC, COBOL, FORTRAN, and PL/1, become known to a wider public through various text- and handbooks. The situation surrounding the application of these languages in many computer centers is a similar one.

    There are differing opinions on the concept "programming languages". What is called a programming language by some may be termed a program, a processor, or a generator by others. Since there are no sharp borderlines in the field of programming languages, works were considered here which deal with machine languages, assemblers, autocoders, syntax and compilers, processors and generators, as well as with general higher programming languages.

    The bibliography contains some 2,700 titles of books, magazines and essays for around 300 programming languages. However, as shown by the "Overview of Existing Programming Languages", there are more than 300 such languages. The "Overview" lists a total of 676 programming languages, but this is certainly incomplete. One author ' has already announced the "next 700 programming languages"; it is to be hoped the many users may be spared such a great variety for reasons of compatibility. The graphic representations (illustrations 1 & 2) show the development and proportion of the most widely-used programming languages, as measured by the number of publications listed here and by the number of computer manufacturers and software firms who have implemented the language in question. The illustrations show FORTRAN to be in the lead at the present time. PL/1 is advancing rapidly, although PL/1 compilers are not yet seen very often outside of IBM.

    Some experts believe PL/1 will replace even the widely-used languages such as FORTRAN, COBOL, and ALGOL.4) If this does occur, it will surely take some time - as shown by the chronological diagram (illustration 2) .

    It would be desirable from the user's point of view to reduce this language confusion down to the most advantageous languages. Those languages still maintained should incorporate the special facets and advantages of the otherwise superfluous languages. Obviously such demands are not in the interests of computer production firms, especially when one considers that a FORTRAN program can be executed on nearly all third-generation computers.

    The titles in this bibliography are organized alphabetically according to programming language, and within a language chronologically and again alphabetically within a given year. Preceding the first programming language in the alphabet, literature is listed on several languages, as are general papers on programming languages and on the theory of formal languages (AAA).
    As far as possible, the most of titles are based on autopsy. However, the bibliographical description of sone titles will not satisfy bibliography-documentation demands, since they are based on inaccurate information in various sources. Translation titles whose original titles could not be found through bibliographical research were not included. ' In view of the fact that nany libraries do not have the quoted papers, all magazine essays should have been listed with the volume, the year, issue number and the complete number of pages (e.g. pp. 721-783), so that interlibrary loans could take place with fast reader service. Unfortunately, these data were not always found.

    It is hoped that this bibliography will help the electronic data processing expert, and those who wish to select the appropriate programming language from the many available, to find a way through the language Babel.

    We wish to offer special thanks to Mr. Klaus G. Saur and the staff of Verlag Dokumentation for their publishing work.

    Graz / Austria, May, 1973
          in Computers & Automation 21(6B), 30 Aug 1972 view details
  • Kupka, I. and Wilsing, N. "Conversational Languages" John Wiley, 1980 view details
          in Computers & Automation 21(6B), 30 Aug 1972 view details
  • Feurzeig, W. "The Logo Lineage" view details Extract: TELCOMP as the ancestor of LOGO
    Time sharing made feasible the economic use of remote distributed terminals and opened up the possibilities of interactive computer use in schools. We had recently implemented TELCOMP, one of the new breed of high-level interactive programming languages. TELCOMP was a dialect of JOSS, the first "conversational" (i.e., interpretive) language, developed in 1962-63 by Cliff Shaw of the Rand Corporation; its syntax was similar to that of BASIC, which had not yet appeared. Like BASIC, TELCOMP was a FORTRAN-derived language originally designed for numerical computational applications. Shortly after TELCOMP was created, we decided to introduce it to children as a tool for teaching mathematics and in 1965-66, under U.S. Office of Education support, explored its use as an auxiliary resource in eight elementary and secondary schools served by the BBN time-sharing system. Students were introduced to TELCOMP and then worked on standard arithmetic, algebra, and trigonometry problems by writing TELCOMP programs. The project strongly confirmed our expectation that the use of interactive computation with a high-level interpretive language would be highly motivating to students. Extract: LOGO based on LISP
    Incredibly, the best model for the new language (which was to be as simple as possible) turned out to be LISP, the lingua franca of artificial intelligence, often regarded (by non-LISP users) as one of the most difficult and formidable of languages. Of course, the syntax of Logo is much more familiar and accessible than that of LISP Essentially, though, Logo is LISP and is thus both an easy and a powerful language. The power is not evident in most existing microcomputer implementations, mainly because of their small memory and restricted performance.
    External link: Onlne copy at the Atari Archives
          in Ditlea, Steve (ed) "Digital Deli: The Comprehensive, User-Lovable Menu of Computer Lore, Culture, Lifestyles and Fancy by The Lunch Group & Guests" Workman Publishers: New York, 1984. view details
  • IEEE Oral history interview with Leo Beranak view details External link: online copy Extract: TELCOMP
    BERANEK: In terms of mini-computers, we were doing paid research for DEC all the time after our purchase of the first PDP-1, and we could see where the market was headed. Of course, we thought we would be leaders in time sharing, which we were the first to. We even developed a programming language called TELCOMP that to this day, some say was better than the programming language that the industry adopted, namely BASIC. Our time sharing business had several early obstacles: the telephone lines were not reliable; the available input typing machines were too slow -- they were standard teletype machines; there were no big memories; and there were no fast printers. Then GE undercut us. We were just too early. But we assembled a roomful of DEC minicomputers and we purchased better storage equipment -- first the big reel cabinets from IBM and later the big flat disks from IBM.

          in Ditlea, Steve (ed) "Digital Deli: The Comprehensive, User-Lovable Menu of Computer Lore, Culture, Lifestyles and Fancy by The Lunch Group & Guests" Workman Publishers: New York, 1984. view details
    • Usenet posting by Etienne Cherdlu

      I remember using TELCOMP back in 1969 (27 years ago). We used it, via a dial
      up line, on a PDP-7 (TELCOMP II) and later on a PDP-10 (TELCOMP III).

      I don't remember much about the machines that we used other than that we
      leased time from a company called Time Sharing Limited of Great Portland Street,
      London. I also have a note from that time about on-line storage charges. It cost
      30p (about 45 cents) per 640 byte block per month!

      The family resemblance between TELCOMP and M is just about recognizable
      especially if you were familiar with MUMPS-11. [refer code example above]

      Comparison with M:

      1. No variable declaration. No data typing (String support in TELCOMP III?)

      2. Sparse local arrays. No globals. File I/O was conventional, I think.

      3. For loop construct.

      4. TYPE command identical to MUMPS-11

      5. Part/Step numbering identical to MUMPS-11

      6. Form Input/Output feature was unique to TELCOMP.

      7. Do label+offset still exists in M today.

      external link