DCALGOL(ID:1958/dca001)

Data Communications ALGOL 


Data Communications ALGOL. A superset of Burroughs Extended ALGOL used for writing Message Control Systems. The DCALGOL language is native to the Unisys A-Series mainframe.

Hardware:
Related languages
ALGOL 60 Revised => DCALGOL   Augmentation of

Samples:
References:
  • Burroughs B6700 Data Communications Extended ALGOL (DCALGOL) Information Manual, 5000052 (Nov. 1970) view details
  • Lyle, Don M. "A hierarchy of high order languages for systems programming" pp73-78 view details Abstract: The programming of systems software in higher level languages has been a subject of much interest and debate. At Burroughs the debatability of the issue has long since ceased to exist since both the operating system and the compilers for the B5500 were successfully implemented in variants of ALGOL 60. The low manpower requirements and the ease of maintenance and modification have caused all concerned with the project to accept this approach without question. This technique has the added benefit of producing more reliable software due to the greatly reduced number of lines of code required. When the decision to produce a successor to the B5500 was made, there was no controversy over the use of high level languages but considerable debate over how high a level the languages should be. B5500 ESPOL (Executive System Problem Oriented Language), the operating system implementation language, contained many ?unsafe? constructs, for example, the ability to directly address memory through a subscripted reference to an array known, strangely enough, as MEMORY. This allowed coding errors to produce undesirable side effects on the system. Examination of the algorithms used in most operating systems indicated that surprisingly few routines actually require such ?unsafe? tools leading to the conclusion that the proper approach to the coding of the overall systems software might be a hierarchical set of systems programming languages with varying degrees of ?safety.? DOI Extract: B6700 DCALGOL as a Systems Programming Language
    B6700 DCALGOL as a Systems Programming Language
    B6700 DCALGOL (Data Communications ALGOL) was originally intended as a slightly less safe superset
    of B6700 Extended ALGOL for the purpose of writing that portion of the systems software dealing
    with the data-communications interface to remote terminals and computers. The language contains
    many constructs dealing with handling of remote stations such as polling frequency, automatic dialup,
    etc. It is beyond the scope of this paper to deal with this aspect of the language, therefore,
    we will concentrate on those features with which the programmer may exercise control over the
    central system.
    It was previously stated that one of the constraints upon the facilities allowed in B6700 Extended
    ALGOL was that an ALGOL program was not permitted to detrimentally affect other concurrently
    executing programs not created by itself. The design constraint placed upon DCALGOL was that a
    DCALGOL program is not permitted to detrimentally affect the operation of the operating system
    (alias Master Control Program or MCP).
    As mentioned above, the original conception of DCALGOL was that this language was a vehicle to
    control a data-communications subsystem. It has since been realized that the facilities embodied
    within the language provide a powerful, safe and convenient tool for more general systems programming.
    The basic differences between DCALGOL and Extended ALGOL, other than those intended specifically
    for data-communications, include:
    1. Messages
    Messages may be thought of as a variable length string of characters whose meaning
    lies in the eyes of the beholder. Messages passed to the Data Communications Processor
    (an outboard processor of the B6700 CPU) have a fixed format in the first six
    words (36 characters), but messages passed between asynchronous processes may have
    any format whatever. An example of a message declsration and assignment is:
    MESSAGE MESSAGETOCONTROLLER;
    2.
    REPLACE MESSAGETOCONTROLLER BY "COMPILE MY/JOB USING COBOL";
    Messages may reside in save (non-overlayable) memory if realtime response is required.
    The ALLOCATE statement assigns a fixed number of words of save memory for a given
    message. The statement
    ALLOCATE(MESSAGETOCONTROLLER, 8);
    reserves eight words for the message to be subsequently placed in MESSAGETOCONTROLLER.
    Messages form the atomic elements of Queues.
    Queues
    Queues contain messages. A message may be placed in a queue at either the queue head
    or queue tail. Since queues may be passed as parameters to procedures, coroutines or
    asynchronous processes, such routines may communicate via messages. A queue may be
    thought of as a non-symmetrical, two-dimensional array in which each row might be of
    a different length. Messages may be added to a queue head or tail via the INSERT
    statement. One form of the INSERT statement is:
    INSERT (MESSAGETOCONTROLLER, CONTROLQ, BOOL) ;
    - 75 -
    IV.
    In the above statement MESSAGETOCONTROLLER is linked into the queue, CONTROLQ, at
    either the head or tail depending upon the value of the boolean expression, B00L,
    true or false respectively.
    The number of messages contained in a queue grows when an INSERT statement is executed
    and shrinks when a REMOVE statement is executed.
    3 ? Remove Function
    4.
    5.
    The simplest form of the REMOVE function is:
    SIZE := REMOVE(SaID, QID);
    in which the message, NSGID, is removed from the queue, QID. The message size is
    returned as the result. A possibly more useful form of the REMOVE construct is:
    SIZE := REMOVE(ARRAYID, QID);
    in which the top message in the queue, QID, is removed and placed in the array row,
    ARRAYID, and the message size is returned as the result.
    Queues may be interrogated as to their depth, concatenated to form a larger queue,
    split to form smaller queues, etc.
    Operator Communication Facilities
    The DCALGOL language contains two "known" queues. The first is a queue of messages by
    which a DCALGOL program may communicate with the operating system in exactly the same  
    way as the machine operator may communicate with the system. This is known to the
    compiler as OPERATORQ. The second is the queue by which the operating system communicates
    with the operator. The depth of this queue is an installation option and is
    specified by either the maximum number of messages retained or the maximum duration of
    retained messages. This queue is known to the system as MCPQ.
    Using these two queues, a DCALGOL program may monitor activities taking place within
    the system (such as jobs initiated independent of itself), perform scheduling,
    priority assignment and even abort jobs in the system of which it does not approve.
    In thls way a DCALGOL program may assume complete control of the system, with the
    same "power" as the human operator, subservient to the control of the B6700 MCP.
    The capability of DCALGOL is illustrated by the current implementation of the B6700
    Remote Job Entry system. Written entirely in DCALGOL and providing remote sites with
    the full capabilities of the central site, the RJE software consists of under 2300
    lines of DCALGOL source code.
          in [ACM] SIGPLAN Notices 6(10) October 1971 Proceedings of the SIGPLAN symposium on Languages for system implementation 1971, Lafayette, Indiana, United States; October, 1971 view details
  • Sammet, Jean E. "Brief survey of languages used for systems implementation" view details Extract: DC Algol
    DC ALGOL [is] a systems programming language in which users can
    write a DC ALGOL operating system to run under the MCP. DC ALGOL is specifically designed to facilitate the implementation of message control systems for data communications networks. DC ALGOL has
    facilities which make it "unsafe" for other jobs in the stream, but has no facilities to affect the MCP.
          in [ACM] SIGPLAN Notices 6(10) October 1971 Proceedings of the SIGPLAN symposium on Languages for system implementation 1971, Lafayette, Indiana, United States; October, 1971 view details