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.

Mainframes, cloud, and trans-derivational searches

Communication is a bit of a hit-and-miss business at the best of times. Suppose I was sitting in a large comfortable leather armchair and I wrote the word ‘chair’. I would be thinking about my armchair. You might be sitting at your computer on an office chair with wheels and no arms. When you read the word ‘chair’, you might think that your office chair was what I had in mind. Perhaps a trivial example, but you get the idea.

What happens if I write a complicated sentence and it’s not immediately clear what I’m saying. You would read it and perform a trans-derivational search in your mind to try to find meaning. What is a trans-derivational search? Well, it’s a bit like going to Amazon and typing the word ‘cloud’ into the search box. Amazon will search in ‘Books’, ‘Film, Music & Games’, ‘Kindle’, ‘Electronics’, etc and display all the answers. You can then make a choice. When it happens in your mind, you do a similar search and select the search result that seems to be the best fit for the unclear sentence.

The reason I mention this is because when one person says the words ‘cloud’ and ‘mainframe’, the image in their mind may be quite different to the image in anyone else’s mind. I like to think of mainframes as interesting and powerful bits of kit that keep the business world turning. Someone else may picture rusting hardware that should have disappeared in the 1990s! It’s much the same with the word ‘cloud’. One person may envisage an outsourcing opportunity, while another may view cloud as a security nightmare – a disaster waiting to happen. You can see now just how tricky this communication stuff really is!

There are people who argue that the mainframe is a cloud already. Suggesting that both are resource that can be dynamically allocated and de-allocated on demand, and can be made available within a company with the necessary security and management controls.

Typically the users of cloud computing have x86 platforms and need to be able to get what they want when they want it – ie on demand. They use primarily Amazon, Google, or Microsoft services. And, of course, everyone is now talking about cloud with announcement of Apple’s iCloud.

Going back to the mainframe, recent surveys have shown mixed interest in cloud computing from mainframers. It seems that the closer to the coal face (or whatever the mainframe metaphor for systems people might be) people are, the less interested they are in cloud. Whereas more high-level thinkers are interested to see what advantages cloud computing offers their organization.

Same words, different mental picture. It’s that communication conundrum again.

If you do have any experience of using cloud and mainframes, I’d be interested to hear about your experience over on IT Toolbox (http://datacenter.ittoolbox.com/groups/strategy-planning/data-center-infrastructure-sp/featured-cloud-computing-in-a-mainframe-environment-4234328).

And for those of you who are IMS professionals, don’t forget the Virtual IMS user group meeting on Tuesday. Gary Weinhold and Verna Bartlett from Data Kinetics will be talking about MSU reduction due to in-memory table management with (any) IMS applications. Full details including how to register are on the Web site at www.fundi.com/meetings.htm.