DCOM Explained
by Rosemary Rock-Evans
Digital Press
ISBN: 1555582168   Pub Date: 09/01/98

Previous Table of Contents Next


In the CICS environment, programs can communicate with each other using an EXEC CICS Link or straight LU6.2 (non-linked model). When a link is used, IBM’s Mirror Transaction handles the protocol and creates a communication area (COMMAREA), which it passes to the program being linked to. At runtime, Cedar sends the appropriate LU6.2 data stream to the CICS Mirror Transaction. The requested CICS program is then executed and receives its input parameters in the COMMAREA. The mainframe TP Monitor processes the input parameters, places any output into the COMMAREA, and issues an EXEC CICS RETURN.

In a non-linked connection, the modules use only the LU6.2 protocol to communicate directly with each other. At runtime, Cedar sends the appropriate LU6.2 data stream to send inputs to the mainframe TP Monitor. The TP Monitor receives the inputs, processes them, and uses the APPC verb set to send the outputs.

The IMS environment provides two ways to pass parameters between programs—implicitly or explicitly. Cedar currently supports only implicit passing. When passing parameters implicitly, a program uses the IMS message queue to access parameters, and IMS handles the LU6.2 protocol behind the scenes. The IMS TP monitor does GETs for the input parameters, processes them, and does INSERTs for the output parameters. (When passing parameters explicitly, a program uses the APPC/MVS API verbs to access the parameters and interact directly with LU6.2.)

Any Other Functions?

We saw in the last chapter on MS RPC that the software handled sessions, synchronization, network calls, “marshalling,” transmission, and the buffers. Cedar’s role is to act as a “broker” between DCOM and CICS so that all these aspects are “converted.” Thus, for example, Cedar provides conversion software so that arguments are marshalled in the form expected by CICS. Similarly, where CICS handles sessions in one way, Cedar acts as the broker to coordinate the sessions between CICS and DCOM. Thus, effectively, Cedar also provides equivalent functionality to MS RPC through its links with CICS and IMS.

Why Not Use DCOM on MVS?

I have already mentioned a number of times that DCOM will be provided on other platforms by companies such as Software AG, Digital, and HP. The MVS version of DCOM is provided by Software AG, and the developer is right to ask the question—why not use Software AG’s DCOM to communicate with the mainframe?

The answer is that Cedar and Software AG’s DCOM are alternative approaches to connectivity, providing different solutions, depending on the requirements of the purchaser. Software AG’s DCOM implementation on the MVS mainframe uses DCE RPC code to communicate with Microsoft’s MS RPC on Windows NT.

“Programs” on the mainframe must be COM components, and if existing programs are to be used, they will need to be “wrapped.” Furthermore, on MVS, the developer must have the POSIX compliant version of MVS and be using TCP/IP. Thus, if you are happy to “wrap” your existing programs and use the POSIX compliant version of MVS, then you should use DCOM. By using DCOM you will get all the benefits of the DCOM approach as the programs on the mainframe will look exactly like components and behave like components.

But, if you do not want to go to the trouble of wrapping your existing programs, prefer a nonintrusive solution with no DCOM on the mainframe, and want to continue to use LU6.2 and CICS, then Cedar is the obvious choice. We will be saying more about wrapping in the chapter on other platforms.

In Summary

This is a short chapter, but an exceptionally important one for mainframe users. Microsoft’s entire development of Cedar was driven by customers’ demand for connectivity to the mainframe. Very few companies can afford to redevelop the systems they have on their mainframe and so called legacy hardware.

There is still a vast number of machines out there with operating systems such as MVS, VME, and VMS all running key core applications, all supporting vast databases of crucial data. These applications also work. To call them legacy applications is an insult—as one of my colleagues once said, they should be called “heritage,” not “legacy.”

Although vendors of software may not have caught on to this, few if any customers want to remove these systems, few if any have any real need to remove them. But they do want to reuse the data stored and updated by those systems and they do want to add new functionality which may cross system and hardware boundaries. Middleware is there to help the developer do this. By using middleware, applications and hardware platforms can be linked together to add new functionality to existing working systems. The fact that Microsoft has added Cedar to make this easier for the customer is a step in the right direction. I will have more to say about this when we look at support for other platforms.


Previous Table of Contents Next