Using COMTI to Connect NT and IBM Mainframes

COM to the rescue s

Since Microsoft first introduced Component Object Model, COM has become an important technology that software developers depend on to develop object-oriented client/server applications in Windows NT networks. COM can shorten the software development cycle by reusing existing component objects and can deliver distributed computing services to clients by linking objects running on different servers.

In response to industrywide COM acceptance and use, Microsoft has developed several useful tools to integrate COM technology with third-party products and legacy systems. One of these tools is COM Transaction Integrator (COMTI—formerly code-named Cedar) for IBM CICS and Information Management System (IMS). COMTI can easily integrate Microsoft Transaction Server (MTS) and mainframe transaction programs (TPs).

COMTI ships with SNA Server 4.0 and lets MTS invoke and execute CICS and IMS TPs in IBM mainframes as if these TPs were COM components. With MTS and a mainframe's transaction support, COMTI can ensure high reliability in mission-critical applications. COMTI can deliver mainframe data to NT and Web applications without requiring you to rewrite mainframe applications and convert your mainframe SNA infrastructure to IP. COMTI can speed NT application development and preserve mainframe resources. If you're a systems administrator managing a mixed NT-and-mainframe network, learn about and use COMTI in your company's client/server application development. In this article, I'll describe COMTI's functionality, security, and high availability. I'll walk you through configuring the COMTI service, and I'll show you how COMTI integrates MTS and mainframe TPs.

Why COMTI?
Let's start with a business example. Imagine a bank is developing a client/server network and replacing dumb terminals with NT workstations to let employees use GUI- and browser-based applications for information access and exchange and to improve work efficiency. However, customer account data resides on an IBM mainframe. The bank runs a COBOL application under CICS in the mainframe to serve banking transactions such as balance checking, deposits, withdrawals, and transfers. The bank can't convert its existing customer account database and application to an NT server database and application because of time and cost constraints.

Although terminal emulation software lets PCs access the mainframe, the software's function is similar to that of the old text-based terminal. The bank decides to develop a client application running in the IP-based NT network that provides a GUI and Web interface to access the mainframe application. The client application will accept a request from a PC's GUI and Web page, feed the request into the COBOL application in the mainframe, let the mainframe process the request, receive the result from the mainframe, and deliver the result to the PC's GUI and Web page. In this way, the bank can take advantage of the existing mainframe resource and doesn't need to rewrite its mainframe application.

The software running in the NT network must also support transaction processing to guarantee the reliability of banking transactions. Without a development and integration tool between the client and mainframe applications, however, developing this client software from the ground up would be very difficult. The bank would need to write sophisticated internal communication between the two applications—for example, for data conversion, protocol conversion, and transaction coordination. COMTI can address this business need.

COMTI Functionality
COMTI can automatically create a COM component from the COBOL data declaration of the mainframe application, which means COMTI generates a component that describes methods and data parameters for the COBOL application. (A method is a function or procedure that acts on an object.) In the bank's case, if the COBOL application includes a program of account-balance checking with three input and output parameters—name, account number, and balance—the COMTI component will contain the method of balance checking with the same three parameters, but in a data format that NT can understand. You can use the COMTI Component Builder to create the component simply by inputting the COBOL program to the COBOL Wizard in Component Builder.

COMTI works closely with MTS and SNA Server, as Figure 1 shows. You can use COMTI Management Console and Component Builder to add the COMTI component to an MTS package. The client application, such as a Visual Basic (VB) program or Active Server Pages (ASP) in Internet Information Server (IIS), can invoke a method of the COMTI component in MTS and include the data parameters in the method. COMTI sends the invoked method to the COBOL application in the mainframe via SNA Server's Advanced Program-to-Program Communications (APPC) Logical Unit (LU) 6.2 connection to the mainframe. Because the mainframe treats the SNA server as a peer mainframe node, the COBOL application handles the request as if it were a request from another mainframe. The COBOL application returns the result to the SNA server. The SNA server forwards the result to COMTI, which sends it to the client application. Using SNA Server's IP-to-SNA gateway function, the client application can communicate with the mainframe program without becoming involved with the underlying network protocol conversion.

Based on the distributed transaction coordinator (MS DTC) in MTS, COMTI supports the Sync Level 2 transaction function in CICS on the mainframe. COMTI in SNA Server 4.0 Service Pack 2 (SP2—which Microsoft is currently beta testing) also supports the Sync Level 2 in IMS 6.0 or later (earlier versions of IMS don't support Sync Level 2). Sync Level 2 is equivalent to two-phase commit (2PC) in MS DTC. Both transaction functions either commit or roll back each element in the transaction. The transaction coordination between the mainframe TP and MTS is transparent to users.

Listing 1 describes the basic programming logic that the VB client application uses to communicate with the mainframe TP through COMTI. The logic involves four major steps: get an object context reference, create an object instance for the COMTI component, invoke the method with input and output data parameters, and commit the transaction if everything worked (otherwise abort it).

COMTI System Preparation
COMTI doesn't require you to install new software in the mainframe, but the mainframe must run MVS 4.3 or later, CICS 3.3 or later, and IMS 6.0 or later if the TP requires Sync Level 2 support. You need to install SNA Server 4.0 on an NT 4.0 server. In the SNA server, you need to define an APPC LU pair—a local LU and a remote LU and the APPC mode for the pair. The APPC mode specifies such control information as maximum packet size and concurrent sessions. To let MTS's MS DTC and the mainframe's Sync Level 2 transaction work together, you need to enable the SyncPoint feature in the SNA server and specify the COMTI server name as SyncPoint's client in the advanced property list of the local APPC LU of the SNA server.

You must install MTS 2.0 from the NT 4.0 Option Pack first on the machine on which you intend to install COMTI. Because COMTI is a component of SNA Server 4.0, you have two optional places to host COMTI: on the SNA server or on a remote NT server or workstation. If you run a small NT network or your SNA server's load is light, you can install COMTI on the SNA server. Otherwise, I recommend installing COMTI on a separate machine to offload the workload from the SNA server. When you install COMTI on a remote machine, you need to install COMTI from SNA Server Client and specify the SNA server name or subdomain in the client configuration. (You can learn about the details of SNA server and client configuration in "Building Fault-Tolerant SNA Functionality," July 1998.)

COMTI Configuration
Now you're ready to configure your COMTI service. Two major steps are involved: building a COMTI component and adding the COMTI component to MTS. Let's take a close look at both steps.

Building a COMTI component. You use the COMTI Component Builder to build a COMTI component for a COBOL application. A COMTI component is a type library (i.e., .tlb) file. To create a new component, you need to specify the component program ID. The ID includes a library name, interface name, and version number, such as Cedar.Bank.1 (COMTI supplies several sample codes for a hypothetical business called Cedar Bank). This component program ID corresponds to the component X.Y.1 in Listing 1.

In the mainframe, you can choose a remote environment type such as a CICS link, to let the COBOL TP participate in the MTS transaction, and you can specify that the component supports the transaction. Then you can use the COBOL Wizard in the Component Builder to input the COBOL source code. Before you use the wizard, however, you need to use tools such as SNA Server's APPC File Transfer Protocol (AFTP) service or the download feature in terminal emulation software to download the COBOL source code from the mainframe to an NT computer.

After you input the COBOL source code, you can create a method for the COBOL program by specifying a method name, such as Cedrbank, that corresponds to MethodName() in Listing 1. Microsoft recommends that you use a method name that is the same as the corresponding mainframe program name to avoid future confusion. The COBOL Wizard will list the data declaration in the COBOL source code. After you select data parameters from the list, the COBOL Wizard will automatically convert the COBOL data parameters to NT data formats and generate the method in the component you defined. If the COBOL source code contains a table of data parameters, the COBOL Wizard will create a recordset to represent the table in the component.

In the same manner, you can create multiple methods in a COMTI component by inputting the methods' COBOL programs in the COBOL Wizard. Screen 1 displays the final Cedar.Bank.1 component, in which you can see two methods, cedrbank and getaccts, and a recordset, AcctInfo, in the left panel. The right panel lists Cedrbank's data parameters and their data-type mapping and direction between NT and the mainframe. For example, the COBOL data type of Name, PIC X(30) maps to a Windows data type String, and the data direction can be either input or output. The Component Builder lets you manually manipulate a particular NT data parameter if you want to use a parameter other than the default.

Adding a COMTI component to MTS. If you don't have an existing MTS package for the COMTI application, you need to create a new empty package in the MTS package folder in the COMTI Management Console or MTS Explorer. Screen 2 shows an empty MTS package I created called Cedar Bank. In the new MTS package, you need to specify an NT account to run the package. After you create the new MTS package, you need to create a new remote environment in the COMTI remote environments folder in the COMTI Management Console. For example, in Screen 2 I created the remote environment Accounts. In the remote environment definition, you need to specify the remote environment type (e.g., a CICS link) that the component will use, and the local and remote LU names of the APPC LU pair that you defined in the SNA server for COMTI communication with the mainframe.

COMTI in SNA Server 4.0 Service Pack 1 (SP1) or later provides a component timeout setting in the remote environment. When you have a defined timeout value of, for example, 10 seconds, COMTI will abort the transaction in 10 seconds if the mainframe can't finish the task, rather than wait for an infinite amount of time.

Now you can use the tool menu in the Component Builder to add the COMTI component you created to MTS. As Screen 3 shows, you can add the component simply by selecting the MTS package and remote environment that you previously defined. Screen 3 shows that the COMTI component Cedar.Bank.1 will be in the MTS package Cedar Bank and will go through the remote environment Accounts to access the mainframe. The tool menu offered by the new Component Builder in SNA Server 4.0 SP1 is an improvement over the old procedure, which requires several manual steps.

As you see in Screen 3, the COMTI Management Console uses the Microsoft Management Console (MMC). The COMTI Component Builder is a standalone utility. I hope Microsoft can provide an MMC snap-in in a future version of Component Builder, so you can configure COMTI from one management console.

COMTI Security
Security is always important when you use COMTI in a production environment. COMTI security consists of two parts: COMTI component security and COMTI remote environment security. COMTI doesn't enable either security by default—you have to configure security according to your requirements.

COMTI component security. COMTI components in an MTS package use native MTS package security. MTS provides two kinds of security: programmatic and declarative. Programmatic security lets you create customized security in your application. Declarative security lets you define roles and add NT users or groups to a role in an MTS package to secure the package. Only individual users or group-member users in the package's defined role can access the package. You can assign a role defined for an MTS package to the role membership of a specific component in the package to set the security restriction at the component level. For example, I created a role called Cedar for the package of Cedar Bank, which you see in Screen 2, and assigned the Cedar role to the role membership of the COMTI component of Cedar.Bank.1. Therefore, only users and groups assigned to the Cedar role can access Cedar.Bank.1.

MTS also includes system package security to define which NT users can edit an MTS configuration—for example, by adding a new COMTI component. Only users in the role membership of the system package can manage or read the MTS configuration. (To learn more about the details of system package security, see Charles Caison, "MTS Security," May 1998.)

COMTI remote environment security. You can enable security in a remote environment to secure mainframe access with two basic security options: user level or package level. In user-level security, COMTI sends the NT user account that invokes the COMTI component in the MTS package to the SNA server for mainframe user authentication. In package-level security, COMTI sends the NT user account that runs the MTS package to the SNA server for mainframe user authentication. The SNA server uses its single sign-on (SSO) feature to map the NT user account to a mainframe user account, and logs the user to the mainframe via the mapped mainframe user credential. The sidebar "NT-Mainframe Single Sign-On," describes how to configure and use SNA Server's SSO function.

If your NT users have mainframe accounts, you can enable user-level security by mapping the NT user accounts to the corresponding mainframe accounts in the SSO database. If you don't want to create the mapping for all users in SSO, you can use package-level security by simply mapping the NT user account running the MTS package to a valid mainframe account in SSO. If you use package-level security, you might want to tightly secure the MTS package and components to avoid a security hole.

COMTI Fault Tolerance
If you run COMTI in an environment requiring high availability (e.g., 24 * 7), you can use Microsoft Cluster Server (MSCS) to implement fault tolerance for COMTI. After you have successfully installed MSCS in a cluster, you need to install MTS 2.0 on the cluster's two nodes. Because MTS 2.0 is cluster-aware, installing it automatically adds MTS's MS DTC service to the cluster resource group that contains the shared disk of the MTS transaction log. COMTI installation is not cluster-aware, but you can manually add the COMTI Resync TP service to the same cluster resource group by defining the service as a generic service. Specify UN2 as the service name for the generic service; UN2 is the service name of the COMTI Resync TP service in the Registry.

You need to stop the COMTI Resync TP service and change its startup setting from automatic to manual in Control Panel, Services on both nodes. You also need to change the Registry entry SNAServiceType under HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesUN2Parameters from 0x00000005 to 0x0000001A on both nodes. This Registry setting will prevent the SNABase service from starting the COMTI Resync TP service when CICS sends an attach message to COMTI.

You must create the same COMTI remote environment and MTS package on both nodes of the cluster, add the same COMTI component to the corresponding MTS package, and associate the component with the corresponding remote environment on both nodes. When you bring the cluster resource group online, only one node will start the COMTI and MTS services. If this node fails, MSCS will automatically fail over the cluster resource group to—and start the COMTI and MTS services on—the second node.

In addition to the fault tolerance you build for the COMTI and MTS services, you should consider a fault-tolerant system for your SNA Server service so that an APPC LU pair is always available to let COMTI communicate with the mainframe. SNA Server has a fault-tolerant mechanism and doesn't use MSCS even if you install SNA Server in COMTI cluster servers. In short, you need to install SNA Server on at least two servers in an SNA subdomain. You configure an APPC LU pair with the same alias names in each server of the SNA subdomain. (The article "Building Fault-Tolerant SNA Functionality" provides the details of SNA fault tolerance.) Then, you specify the alias names in the local and remote LU fields in the COMTI remote environment's SNA property on the two COMTI servers. In this way, the COMTI servers can always access the mainframe as long as at least one SNA server is online.

I mentioned earlier that you need to specify the client name when you enable Syncpoint on the SNA server. If you have a COMTI cluster, you need to use standard wildcard characters to define the client name to match the two server names in the cluster. For example, if the two COMTI cluster server names are COMTISRV1 and COMTISRV2, you can use either COMTISRV* or COMTISRV? as the client name in each SNA server to support the two COMTI servers.

Back to the Future
Now you know that COMTI is an easy-to-use and powerful tool that lets you integrate MTS with mainframe TPs using COM technology. With COMTI, you can quickly, reliably, and securely deliver mainframe data to NT and the Web without changing your legacy environment. Today, as more and more mainframe-based companies are moving to NT and doing business on the Internet, COMTI is becoming a valuable vehicle to carry yesterday's systems and applications into the future.