Editing Burroughs Large Systems (section)

===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.