“Cedar” is the code name for the newest Microsoft product for building distributed applications in the enterprise. Cedar makes it easier, cheaper, and faster for enterprise information systems (EIS) groups to develop applications that integrate the client/server computing environment with the mainframe computing environment. EIS groups can now use Cedar and other Active Server technologies to connect desktop clients to mainframe servers.
Specifically, Cedar makes it easy to create applications consisting of Automation clients running on the desktop or server with COBOL servers running under CICS or IMS. Cedar supports a client application running on a computer running Windows NT Server, Windows NT Workstation, Windows 95, or any other platform that supports DCOM and Automation. Cedar can also be used with Web-based clients (browsers) that connect to the Microsoft Internet Information Server (IIS). Cedar directly supports any TP that executes in CICS and is structured to use either distributed program linking or Advanced Program-to-Program Communication (APPC) verbs.
Cedar also directly supports IMS applications that are structured to use the IMS Message Queue. Because Cedar can access CICS programs, developers can extend the client application calls even further by using CICS to access any other program on the MVS mainframe.
Cedar is a generic proxy for the mainframe. As illustrated in the diagram below, Cedar intercepts object method calls from the client application and redirects those calls to the TP running on the MVS mainframe. Cedar also handles the return of all output parameters and return values from the mainframe. When Cedar intercepts the method call, it converts and formats the method’s parameters from the representation understandable by Windows NT Server into the representation understandable by the mainframe TP. Cedar uses standard communication protocols (for example, LU6.2 provided by Microsoft SNA Server version 3.0) for communicating between the computer running Windows NT Server and the mainframe TP.
All of Cedar’s processing is done on the Windows NT Server. Cedar does not require any executable code to be run on the mainframe and does not require special programming on the mainframe, on the computer running Windows NT Server, or on the client.
The way in which a developer uses Cedar varies slightly, depending on whether the developer is starting from the mainframe side or from the Windows side of the distributed application. This section presents two scenarios. In the first scenario, there is an existing TP on the mainframe, and the developer wants to enable a Windows-based application to access the TP. In the second scenario, a developer is adding a Cedar object to a new Windows-based application and there is no existing TP on the mainframe.
In many enterprises, the developer will want to connect the Windows-based application to a mainframe TP already in use by the organization. As shown in the following illustration, the existing COBOL program is the starting point for the development process.
From this starting point, the developer might follow these six general steps in building an application:
Step 1: Initial configuration
Before developing the application, the developer must be sure the following programs are installed on the computer:
Cedar includes the following components:
Step 2: Define methods and parameters
The developer acquires the COBOL copybook from the mainframe by copying it from a 3270 terminal screen or by using any available file transfer mechanism, such as the FTP/AFTP gateway provided with SNA Server. The developer then pastes the copybook into the IB. The IB analyzes the copybook and asks the developer a series of questions to define the methods and parameters and the corresponding data-type mappings. The Cedar IB supports conversion of the following COBOL data types:
| PIC S9(4) COMP integer (16-bit) | PIC X |
| PIC S9(9) COMP integer (32-bit) | PIC X with no translation |
| COMP-3 packed decimal | DATE and TIME (packed decimal) |
| COMP-2 float (8 byte) | OCCURS fixed times |
| COMP-1 float (4 byte) | OCCURS depending |
Next, the developer specifies the name and location of the mainframe TP. Finally-and only if necessary-the developer changes the default mappings between COBOL data types and Automation data types. Cedar supports the following Automation data types:
| 2 byte signed integer | Decimal |
| 4 byte signed integer | Date (8 byte real) |
| 4 byte real | Variable-length string |
| 8 byte real | Boolean |
| Currency (8 byte fixed point) | 1 byte unsigned integer |
| Arrays of any of the previous types |
When the developer is satisfied with the mappings, he or she clicks Make Typelib on the IB File menu to create the Cedar type library (.tlb). The Cedar type library is a standard object library (.tlb) that can be read by any Windows-based program and, once registered, is available for use with client development tools. The Cedar type library is automatically registered with the operating system when the developer drags the Cedar component into an MTS package.
If the developer changes any of the COBOL data types during this step, he or she then clicks Generate COBOL Declarations on the Cedar File menu. New data declarations are needed only if something has changed from the original input declarations. In this case, the developer must update the mainframe TP with any new data declarations.
Step 3: Write the application
Although this scenario assumes there is an existing mainframe TP, the developer may want to modify that program. The developer reviews the COBOL data declarations and existing COBOL program and notes any desired changes. The developer can either use COBOL to change the TP right on the mainframe or use a product like Microfocus COBOL to modify the server program on a Windows NT platform and then move the program back to the mainframe. In either case, the COBOL server program must be on the mainframe at run time in order to execute with Cedar.
Next, the developer writes the client-side of the application by using Visual Basic, Visual Basic for Applications, Microsoft Visual C++® development system Microsoft Visual J++™ development software, or another language that supports referencing of Automation objects. The developer adds the appropriate Cedar object library to the references list in the Visual Basic (or other language) project and then adds references to the object in the program.
The referenced class can be viewed from a standard object browser such as the one in Visual Basic version 5.0. The object browser shows the methods that are available for the Cedar object and the parameters for those methods. The developer simply invokes the object’s methods as appropriate throughout the application.
Step 4: Test the application
If the mainframe COBOL program is unchanged, the developer doesn’t need to retest that part of the application. If the program or data declarations are changed, however, the developer should test the new parts of the COBOL program independently from the Windows NT Cedar component. The developer starts by using another mainframe program and standard test tools to test the mainframe code. Next, the developer tests the Cedar component independently to ensure that it is working correctly. Finally, the developer tests the application end-to-end by using the controlling object to drive the Cedar proxy and execute the mainframe TP.
If transactions are enabled, the developer should first execute without transactions and, once successful, then execute as part of a transaction. The same procedure should be followed for testing security: first execute without security and then again with security enabled.
Step 5: Deploy application components
It is assumed that the mainframe TP is already deployed on production computers; therefore, no additional steps are needed for deployment. If the TP has been modified, the system administrator should follow the organization’s standard procedures for deployment.
Before deploying the client-side of the application, the system administrator must be sure that the following programs are installed on each production computer that is running Windows NT Server:
As in Step 1, the system administrator uses the individual setup programs that ship with Windows NT version 4.0, SNA Server version 3.0, MTS, and Cedar. The Cedar type library should be registered on the computer running Windows NT Server used for the development and testing discussed in Steps 3 and 4. The system administrator must now register it on any additional production servers.
In addition, MTS requires that the appropriate component created by Cedar be registered on any client deployment machine. The export function in the MTS Explorer helps build the package required for deployment. Finally, the system administrator deploys the client application and any help files that might be related to run-time errors that can occur on the actual mainframe server.
Step 6: Maintain the application
After the application has been put into production, the developer makes changes to the TP program as needed. If the changes are extensive, the developer can decide whether to open a new COBOL copybook, use the IB to update the existing COBOL copybook, or use the existing Cedar definition of the interface as the base for modification. The developer can make that choice for each specific interface.
In the previous scenario, the developer was connecting to an existing TP on the mainframe. In this second scenario, there is no preexisting COBOL program, and the developer is writing an entirely new Windows-based application.
Although the starting point-a new Windows-based application-is different, the steps in the development process are almost identical to the first scenario.
Step 1: Initial configuration
As in the first scenario, the developer (or system administrator) installs and configures Cedar and other required programs.
Step 2: Define methods and parameters
Because there is no preexisting COBOL program, the developer uses the Cedar IB to define the new methods and parameters for the application. The developer enters information into the IB about the location and name of the new mainframe TP. If necessary, the developer also changes the default data type mappings. As in the first scenario, when the developer is satisfied with the definitions, he or she creates the Cedar type library (.tlb).
Next, the developer writes the new TP based on the data declaration generated by the IB. The developer can either use COBOL to write the TP directly on the mainframe or write the program on the Windows NT platform (by using a product like Microfocus COBOL) and then move the program to the mainframe. In either case, the COBOL server program must be on the mainframe at run time in order to execute with Cedar. The client side of the application is written in the same manner as in the first scenario.
Step 4: Test the application
As in the first scenario, the developer tests each component independently to ensure that it is working correctly and then tests the entire application end-to-end.
Step 5: Deploy application components
Because the TP is new, the system administrator follows the organization’s standard procedures for deployment. The system administrator then deploys the client application and any help files that might be related to run-time errors. The mainframe TP is then put into production. The developer and the systems administrator should work together to ensure that Cedar is configured to use the production TP and not the test TP.
Step 6: Maintain the application
As in the first scenario, the developer makes changes to the application as needed. If changes to the client application require changes to the data declarations, the developer uses the IB to open the Cedar type library and update the mapping. The developer makes a new type library and generates new COBOL data declarations. Depending upon how extensive the changes are, the developer may also have to use the newly generated COBOL data declarations to make the appropriate changes to the mainframe program.
Cedar is a general tool for mapping data types and converting data between the Windows NT environment and the MVS mainframe. However, Cedar recognizes that each mainframe environment has its own unique characteristics and requirements. Therefore, Cedar is designed to interface with either of the two major environments in the market today: CICS or IMS.
In the CICS environment, programs can communicate with each other by using an EXEC CICS Link or straight LU6.2 (nonlinked 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. The advantage of this approach is that the developer does not have to code APPC API calls. In a nonlinked connection, the modules use only the LU6.2 protocol to communicate directly with each other.
If the developer selects the option in the IB to establish an EXEC CICS Link, 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 maximum size for all parameters is 32,763 bytes. The COMMAREA can contain optional meta-data or rowsets.
The mainframe TP processes the input parameters, places any output parameter values (including the return value) into the COMMAREA, and issues an EXEC CICS RETURN. This model requires the least amount of programming in the CICS program.
If the developer does not select the IB option to establish an EXEC CICS Link, Cedar sends the appropriate LU6.2 data stream to send inputs to the mainframe TP. The TP receives the inputs, processes them, and uses the APPC verb set to send the outputs. Alternatively, the TP could be written to receive the parameters, build a COMMAREA, and do an EXEC CICS LINK to another existing program. As with the Link option, developers can send and receive optional meta-data and rowsets.
The IMS environment offers two ways to pass parameters between programs: implicitly or explicitly. 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 does GETs for the input parameters, processes them, and does INSERTs for the output parameters. When passing parameters explicitly, a program uses APPC/MVS API verbs to access the parameters and interact directly with LU6.2.
Cedar currently supports only implicit passing, because it offers the most natural and transparent programming for the IMS developer. Because Cedar uses the IMS Message Queue, Cedar directly supports client integration with a large set of existing IMS/DC or IMS/TM applications. The maximum size for all parameters is 30,000 bytes. As with both CICS options, developers can also send and receive optional meta-data and rowsets.
Although Cedar can be used in simple applications that access mainframe programs, it becomes an even more powerful tool when used in the Windows NT Server environment, because developers can use it to extend transactions from that environment to the mainframe. Developers can easily describe, execute, and administer special MTS objects that access CICS TPs.
Although Cedar does not currently support transactional involvement of IMS programs, developers can access the IMS/DB database transactionally through a CICS front-end program. If the enterprise can use CICS to access IMS/DB, then Cedar can be used, with transactions, to access the IMS/DB database.
Developers using MTS in their applications can decide which parts of the application require a transaction and which parts do not. Cedar extends this choice to the mainframe as well by handling both calls that require transactions and calls that do not.
Cedar provides all the necessary functionality necessary for applications that require full integration between Windows-based two-phase commit and mainframe-based Sync Level 2 transactions. Cedar does this without requiring you to change the client application, without placing Microsoft executable code on the mainframe, and with little or no change to the mainframe TP. For example, the following diagram shows a client application that uses transactions in both Microsoft SQL Server™ and a CICS transaction program.
The client application relies on MTS and the distributed transaction coordinator (DTC) to manage the transactions transparently. The client application cannot distinguish between the Cedar component and any other MTS component reference. Note that in some applications, the client application could itself be an MTS component in another transaction. In this case, the client might need to have additional code for transaction handling.
Note The term transaction can have a different meaning depending upon the computing environment. A transaction in the MTS environment means a specific two-phase commit that is coordinated by the DTC. In contrast, a transaction in the CICS environment has a more general meaning. Any CICS program that uses APPC with another CICS program is referred to as a Transaction Program (TP). A TP can provide any type of service, including terminal emulation, data transfer, database query, and database updates.
For a TP to communicate directly with another TP using APPC, the two programs must first establish an LU6.2 conversation with each other. LU6.2 is the defacto standard for distributed transaction processing in the mainframe environment and is used by both CICS and IMS subsystems. Although a TP first appears as a transaction (in the MTS sense of the term), because it is registered with CICS or IMS as the Transaction Monitor, there are three different levels of synchronization that can occur during a LU6.2 conversation:
(Jim Gray and Andreas Reuter, Gray, Jim and Andreas Reuter, Transaction Processing: Concepts and Techniques Transaction Processing: Concepts and Techniques, San Francisco, CA: Morgan Kaufmann Publishers. 1993. P. 937.see Transaction Processing: Concepts and Techniques. San Francisco, CA: Morgan Kaufmann Publishers, 1993. P. 937.)
Of the three sync levels, only Sync Level 2 provides the same 2PC provided by an MTS transaction. Thus, the term transaction used in the CICS and IMS environment may or may not involve 2PC-it is simply synonymous with the TP itself. It is only when the term transaction is qualified by adding the term Sync Level 2 that the developer for Windows and the mainframe developer can be certain they are referring to the same thing. Cedar supports both Sync Level 0 and Sync Level 2 conversations.
Software AG recently announced a product for MVS that implements DCOM for mainframe programs. To the casual observer, it may appear that the Software AG product provides the same functionality as Cedar, but the two products have very different requirements and are aimed at two different types of customers. Software AG requires that the MVS program be a COM component and, therefore, requires the developer to write a COM wrapper around existing mainframe programs.
In addition, Software AG uses DCE to marshal parameters and, therefore, also requires DCE to be present on the mainframe. Finally, Software AG ported DCOM from their version of DCOM for UNIX and, therefore, requires the POSIX-compliant version of MVS. Thus, the target customer for the Software AG product is an organization that is either running or moving to MVS version 5.x and who is already running DCE on the mainframe. In addition, if customers are willing to write the custom code required, they can use custom interfaces and not be restricted to the subset of Automation data types, as they are with Cedar.
In contrast, Cedar supports MVS version 4.3 and later and does not require changing the mainframe programming model. Cedar provides the mainframe proxy on Windows NT Server and does all of the data conversions there. Instead of DCE, Cedar uses SNA Server-also running on the Windows NT Server-to communicate with the mainframe.
Cedar supports only Automation interfaces and does not require any wrapper code on the mainframe. Thus, the target customer for Cedar is an organization that does not want to change their mainframe programming model or does not want to invest in additional MVS products.
By providing a generic mainframe proxy that operates on a computer running Windows NT Server and works closely with the Microsoft Transaction Server, Cedar enables client applications to call COBOL programs running under-or accessible from-CICS or IMS. Developers can easily use the Cedar Interface Builder to define the target mainframe transaction program and, if necessary, to override any of the default data type mappings.
Developers do not have to learn special APIs; they simply specify a set of methods and parameters for the application they are constructing. Cedar appears to developers as a simple Automation component that they can easily add to their application project, and developers can continue building their client application by using whatever DCOM-compliant languages and tools they are most familiar with.
© 1997 Microsoft Corporation. All rights reserved.
This white paper is for informational purposes only. MICROSOFT MAKES NO WARRANTIES, EXPRESS OR IMPLIED, IN THIS DOCUMENT.
The information contained in this document represents the current view of Microsoft Corporation on the issues discussed as of the date of publication. Because Microsoft must respond to changing market conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information presented after the date of publication.
Microsoft, Visual Basic, Visual C++, Windows, and Windows NT are registered trademarks and BackOffice, the BackOffice logo, and Visual J++ are trademarks of Microsoft Corporation.
Other product and company names mentioned herein may be the trademarks of their respective owners.