Open main menu
Home
Random
Recent changes
Special pages
Community portal
Preferences
About Wikipedia
Disclaimers
Incubator escapee wiki
Search
User menu
Talk
Dark mode
Contributions
Create account
Log in
Editing
Burroughs Large Systems
(section)
Warning:
You are not logged in. Your IP address will be publicly visible if you make any edits. If you
log in
or
create an account
, your edits will be attributed to your username, along with other benefits.
Anti-spam check. Do
not
fill this in!
==ALGOL== {{Main|ALGOL}} {{Infobox programming language | name = Burroughs ALGOL | logo = <!-- Filename only --> | logo caption = | screenshot = <!-- Filename only --> | screenshot caption = | paradigms = [[Multi-paradigm programming language|Multi-paradigm]]: [[Procedural programming|procedural]], [[Imperative programming|imperative]], [[Structured programming|structured]] | family = [[ALGOL]] | designers = John McClintock, others | developer = [[Burroughs Corporation]] | released = {{Start date and age|1962}}<!-- If known, add |mm|dd --> | latest release version = | latest release date = <!-- {{Start date and age|196?|mm|dd|df=yes}} --> | typing = | scope = | programming language = | discontinued = Yes | platform = Burroughs large systems | operating system = [[Burroughs MCP]] | license = | file ext = | file format = <!-- or: | file formats = --> | website = <!-- {{URL|www.example.com}} --> | implementations = | dialects = | influenced by = [[ALGOL 60]] | influenced = [[Executive Systems Problem Oriented Language|ESPOL]], [[Burroughs MCP|MCP]], [[#ESPOL and NEWP|NEWP]] }} The Burroughs large systems implement ALGOL-derived [[stack architecture]]s. The B5000 was the first stack-based system. While B5000 was specifically designed to support ALGOL, this was only a starting point. Other business-oriented languages such as COBOL were also well supported, most notably by the powerful string operators which were included for the development of fast compilers. The ALGOL used on the B5000 is an extended ALGOL subset. It includes powerful string manipulation instructions but excludes certain ALGOL constructs, notably unspecified formal parameters. A DEFINE mechanism serves a similar purpose to the [[C preprocessor|#defines]] found in C, but is fully integrated into the language rather than being a preprocessor. The EVENT data type facilitates coordination between processes, and ON FAULT blocks enable handling program faults. The user level of ALGOL does not include many of the insecure constructs needed by the operating system and other system software. Two levels of language extensions provide the additional constructs: ESPOL and NEWP for writing the MCP and closely related software, and DCALGOL and DMALGOL to provide more specific extensions for specific kinds of system software. ===ESPOL and NEWP=== Originally, the B5000 MCP operating system was written in an extension of extended ALGOL called [[Executive Systems Problem Oriented Language|ESPOL]] (Executive Systems Programming Oriented Language). This was replaced in the mid-to-late 70s by a language called NEWP. Though NEWP probably just meant "New Programming language", legends surround the name. A common (perhaps apocryphal) story within Burroughs at the time suggested it came from "''No Executive Washroom Privileges''." Another story is that circa 1976, John McClintock of Burroughs (the software engineer developing NEWP) named the language "NEWP" after being asked, yet again, "does it have a name yet": answering "nyoooop", he adopted that as a name. NEWP, too, was a subset ALGOL extension, but it was more secure than ESPOL, and dropped some little-used complexities of ALGOL. In fact, all unsafe constructs are rejected by the NEWP compiler unless a block is specifically marked to allow those instructions. Such marking of blocks provide a multi-level protection mechanism. NEWP programs that contain unsafe constructs are initially non-executable. The security administrator of a system is able to "bless" such programs and make them executable, but normal users are not able to do this. (Even "privileged users", who normally have essentially root privilege, may be unable to do this depending on the configuration chosen by the site.) While NEWP can be used to write general programs and has a number of features designed for large software projects, it does not support everything ALGOL does. NEWP has a number of facilities to enable large-scale software projects, such as the operating system, including named interfaces (functions and data), groups of interfaces, modules, and super-modules. Modules group data and functions together, allowing easy access to the data as global within the module. Interfaces allow a module to import and export functions and data. Super-modules allow modules to be grouped. ===DCALGOL and Message Control Systems (MCS)=== In the original implementation, the system used an attached specialized data communications processor (DCP) to handle the input and output of messages from/to remote devices. This was a 24-bit minicomputer with a conventional register architecture and hardware I/O capability to handle thousands of remote terminals. The DCP and the B6500 communicated by messages in memory, essentially packets in today's terms, and the MCS did the B6500-side processing of those messages. In the early years the DCP did have an assembler (Dacoma), an application program called DCPProgen written in B6500 ALGOL. Later the [[Network Definition Language|NDL]] (Network Definition Language) compiler generated the DCP code and NDF (network definition file). Ultimately, a further update resulted in the development of the NDLII language and compiler which were used in conjunction with the model 4 and 5 DCPs. There was one ALGOL function for each kind of DCP instruction, and if you called that function, then the corresponding DCP instruction bits would be emitted to the output. A DCP program was an ALGOL program comprising nothing but a long list of calls on these functions, one for each assembly language statement. Essentially ALGOL acted like the macro pass of a macro assembler. The first pass was the ALGOL compiler; the second pass was running the resulting program (on the B6500) which would then emit the binary for the DCP. Starting in the early 1980's, the DCP technology was replaced by the ICP (Integrated Communications Processor) which provided LAN based connectivity for the mainframe system. Remote devices, and remote servers/mainframes, were connected to the network via freestanding devices called CP2000s. The CP2000s were designed to provide network node support in a distributed network wherein the nodes were connected using the BNAV2 (Burroughs Network Architecture Version 2) networking technology. BNAV2 was a Burroughs functional equivalent of the IBM SNA product and did support interoperation with IBM environments in both PUT2 and PUT5 transport modes. The change in external datacommunications hardware did not require any change to existing MCS (Message Control System (discussed below)) software. On input, messages were passed from the DCP via an internal bus to the relevant MCP Datacom Control (DCC) DCP process stack. One DCC process was initiated for each DCP configured on the system. The DCP Process stack would then ensure that the inbound message was queued for delivery to the MCS identified to handle traffic from the particular source device and return any response to the DCP for delivery to the destination device. From a processing perspective no changes were required to the MCS software to handle different types of gateway hardware, be it any of the 5 styles of DCP or the ICP or ICP/CP2000 combinations. Apart from being a message delivery service, an MCS is an intermediate level of security between operating system code (in NEWP) and user programs (in ALGOL, or other application languages including COBOL, FORTRAN, and, in later days, JAVA). An MCS may be considered to be a [[middleware]] program and is written in DCALGOL (Data Communications ALGOL). As stated above, the MCS received messages from queues maintained by the Datacom Control Stack (DCC) and forwarded these messages to the appropriate application/function for processing. One of the original MCS's was CANDE (Command AND Edit) which was developed as the online program development environment. The University of Otago in New Zealand developed a skinny program development environment equivalent to CANDE which they called SCREAM/6700 in the same time that IBM was offering a remote time-sharing/program development service known as CALL/360 which ran on IBM 360 series systems. Another MCS named COMS was introduced around 1984 and developed as a high performance transaction processing control system. There were predecessor transaction processing environments which included GEMCOS (GEneralized Message COntrol System), and an Australian Burroughs subsidiary developed MCS called TPMCS (Transaction Processing MCS). The transaction processing MCS's supported the delivery of application data to online production environments and the return of responses to remote users/devices/systems. MCSs are items of software worth noting β they control user sessions and provide keeping track of user state without having to run per-user processes since a single MCS stack can be shared by many users. Load balancing can also be achieved at the MCS level. For example, saying that you want to handle 30 users per stack, in which case if you have 31 to 60 users, you have two stacks, 61 to 90 users, three stacks, etc. This gives B5000 machines a great performance advantage in a server since you don't need to start up another user process and thus create a new stack each time a user attaches to the system. Thus you can efficiently service users (whether they require state or not) with MCSs. MCSs also provide the backbone of large-scale transaction processing. Around 1988 an implementation of TCP/IP was developed principally for a U.S. government customer utilizing the CP2000 distributed communications processor as the protocol host. Two to three years later, the TCP/IP implementation was rewritten to be host/server based with significant performance and functionality improvements. In the same general time frame an implementation of the OSI protocol stacks was made, principally on the CP2000, but a large supporting infrastructure was implemented on the main system. All of the OSI standard defined applications were implemented including X.400 mail hosting and X.500 directory services. ===DMALGOL and databases=== Another variant of ALGOL is DMALGOL (Data Management ALGOL). DMALGOL is ALGOL extended for compiling the DMSII database software from database description files created by the DASDL (Data Access and Structure Definition Language) compiler. Database designers and administrators compile database descriptions to generate DMALGOL code tailored for the tables and indexes specified. Administrators never need to write DMALGOL themselves. Normal user-level programs obtain database access by using code written in application languages, mainly ALGOL and COBOL, extended with database instructions and transaction processing directives. The most notable feature of DMALGOL is its preprocessing mechanisms to generate code for handling tables and indices. DMALGOL preprocessing includes variables and loops, and can generate names based on compile-time variables. This enables tailoring far beyond what can be done by preprocessing facilities which lack loops. DMALGOL is used to provide tailored access routines for [[Unisys DMSII|DMSII]] databases. After a database is defined using the Data Access and Structure Definition Language (DASDL), the schema is translated by the preprocessor into tailored DMALGOL access routines and then compiled. This means that, unlike in other DBMS implementations, there is often no need for database-specific if/then/else code at run-time. In the 1970s, this "tailoring" was used very extensively to reduce the code footprint and execution time. It became much less used in later years, partly because low-level fine tuning for memory and speed became less critical, and partly because eliminating the preprocessing made coding simpler and thus enabled more important optimizations. An applications version of ALGOL to support the accessing of databases from application programs is called BDMSALGOL and included verbs like "FIND", "LOCK", "STORE", "GET", and "PUT" for database access and record manipulation. Additionally, the verbs "BEGINTRANSACTION" and "ENDTRANSACTION" were also implemented to solve the deadlock situation when multiple processes accessed and updated the same structures. Roy Guck of Burroughs was one of the main developers of [[Unisys DMSII|DMSII]]. In later years, with compiler code size being less of a concern, most of the preprocessing constructs were made available in the user level of ALGOL. Only the unsafe constructs and the direct processing of the database description file remain restricted to DMALGOL.
Edit summary
(Briefly describe your changes)
By publishing changes, you agree to the
Terms of Use
, and you irrevocably agree to release your contribution under the
CC BY-SA 4.0 License
and the
GFDL
. You agree that a hyperlink or URL is sufficient attribution under the Creative Commons license.
Cancel
Editing help
(opens in new window)