Conversational Monitoring System

I do a lot of work with Web sites and people are often talking about using a CMS to make it easier to upload and place content. For them, CMS stands for Content Management System, but I thought it would be fun to revisit Conversational Monitor System – one of the first virtual machines that people really enjoyed using because of its flexibility and functionality.

Our story starts in the mid-1960s at IBM’s Cambridge Scientific Center, where CMS – then called Cambridge Monitor System – first saw the light of day running under CP-40, a VM-like control program, which then developed into CP-67. It provided a way of giving every user the appearance of working on their own computer system. So, every user had their own terminal (the system console for their system) as if they had their own processor, unit record device (what we’d call a printer, card reader, and card punch), and DASD (disk space). The control program looked after the real resources and allocated them, as required, to the users.

In 1972, when IBM released its 370-architecture machine, a new version of VM called VM/370 became available. Unlike CP/CMS, IBM supported VM/370 and CMS retained its initials, but was now known as Conversational Monitor System – highlighting its interactive nature. This commercial product also included RSCS (Remote Spooling Communication Subsystem) and IPCS (Interactive  Problem Control System), which ran under CMS.

VM itself was originally not very popular within IBM, but, through quite an interesting story, survived. VM/370 became VM/SE and then VM/SP. There was also a low-end variant called VM/IS. Then there was VM/SP HPO before we had VM/XA SF, VM/XA SP, then VM/ESA, and now z/VM.

But returning to CMS, it was popular because you could do so much with it. You could develop, debug, and run programs, manage data files, communicate with other systems or users, and much more. When you start (IPL CMS) CMS, it loads a profile exec, which sets up your virtual environment in exactly the way that you want it to be.

Two products that made CMS users very happy were PROFS and REXX. PROFS (PRofessional OFfice System) became available in 1981 and was originally developed by IBM in Dallas, in conjunction with Amoco. It provided e-mail, shared calendars, and shared document storage and management. It was so popular that it was renamed OfficeVision and ported to other platforms. OfficeVision/VM was dropped in 2003, with IBM recommending that users migrate to Lotus Notes and Domino, which it had acquired by taking over Lotus.

REXX (Restructured Extended Executor) is an interpreted programming language developed by Mike Cowlishaw and released by IBM in 1982. It is a structured, high-level programming language that's very easy to get the hang of. In fact, it was so popular, that it was ported to most other platforms. REXX programs are often called REXX EXECs because it replaced EXEC and EXEC2 as the command language of choice.

CMS users will remember XEDIT, which is an edit program written by Xavier de Lamberterie that was released in 1980. XEDIT supports automatic line numbers, and many of the commands operate on blocks of lines. The command line allows user to type editor commands. It replaced EDIT SP as the standard editor. Again, XEDIT was very popular and ported to other platforms.

CMS provided a way to maximize the number of people who could concurrently use mainframe facilities at a time when these facilities were fairly restricted. It was a hugely successful environment, spawning tools that themselves were ported to other platforms because they were so successful. I used CMS and VM a lot back in the day, and even wrote two books about VM. Like many users, I have very fond memories of using CMS and what could be achieved by using CMS.

CICS communication history

In the beginning, CICS programmers used conversational transactions – but not any more. Pseudo-conversational coding is less resource-intensive, user think time costs are eliminated, and sites can run more simultaneous transactions. On the down side, programming is more difficult, application design requires re-starting programs, it’s more difficult to debug programs, and programs require an area to store data between tasks.
 
And so we get the Communication Area (COMMAREA). It’s a terminal-based scratchpad that’s dynamic in size (0 to 32,500 bytes), and is private and chained to the terminal. The COMAREA can hold data between pseudo-conversations, has a maximum in size of 32K, can be passed from program to program, can be empty, partially full, or full, and is automatically cleaned up when not used.

However, COMMAREAs have obvious limitations, and so IBM gave us channels and containers. There are no size limitations on data in containers, the number of containers in a channel is unlimited, and there can be separate containers for input and output.
Another way round COMMAREA limitations is to use an XML (eXtensible Mark-up Language) front-end application. Associated with this are:

• Extensible Stylesheet Language Transformation (XSLT) is the recommended style sheet language of XML.
• XML namespaces – in XML, element names are defined by a developer.
• XML schema is an XML document that describes the structure and constrains the contents of other XML documents.
• XML parser is a program that is invoked by an application to process an XML document, ensure that it meets all the rules of XML as well as the syntax of the DTD or schema, making the data available to the calling application.

With the introduction of Services Oriented Architecture (SOA), programmers now use CICS Web services. A Web service is a collection of operations that are network accessible through standardized XML messaging. The Web services architecture is based on interactions between three components: a service provider, which is the platform that hosts access to the service; a service requester, which is the application that is looking for and invoking or initiating an interaction with a service; and service registry, which is a place where service providers publish their service descriptions, and where service requesters find them.

Universal Description, Discovery and Integration (UDDI) is a specification for distributed Web-based information registries of Web services. The service provider “owns” the service, creates the WSDL (Web Service Description Language – see below), publishes the WSDL, and processes the requests. The service requester “finds” the service, binds to the service, and invokes the service using the WSDL. The service registry hosts the service description and is optional for statically bound requesters.

WSDL is an XML application for describing Web services. WSDL comprises:

• Types – the data types in the form of XML schemas
• Message – an abstract definition of the data in the form of a message
• PortType – an abstract set of operations mapped to one or more end points
• Binding – the concrete protocol and data formats for the operations
• Service – a collection of related end points.

Simple Object Access Protocol (SOAP) is an XML-based protocol for the exchange of information in a distributed environment. A SOAP message is encoded as an XML document.
 
The CICS Web services assistant is a set of batch utilities that can help users transform existing CICS applications into Web services and to enable CICS applications to use Web services provided by external providers. The CICS Web services assistant comprises two utility programs:

• DFHLS2WS generates a Web service binding file from a language structure. This utility also generates a Web service description.
• DFHWS2LS generates a Web service binding file from a Web service description. This utility also generates a language structure that you can use in your application programs.

You can use Rational Developer for System z for Web services and XML development. A CICS pipeline is responsible for dealing with SOAP headers. It’s implemented as a series of programs, and can be configured by end users by using message handlers. A message handler is a program in which you can perform your own processing of Web service requests and responses.