Microsoft Year 2000 Readiness Disclosure and Resource Center

Integrate the Enterprise

The following scenarios describe the most common needs for integrating distributed applications with legacy systems:

• Terminal emulation.
• Surfing the mainframe.
• Extending across the enterprise with cross-platform, multi-tier applications.

Situation: Windows-based clients need access to host programs. The client acts as a terminal to the host. Advanced screen scrapping with HTML allows a client on the intranet or Internet to act with the host as though it were an IBM 3270 terminal.

Recommended Solution: Third party packaged connectivity software and scripting languages.

Figure 3   Access to mainframe data and programs can be transparent to a user, whether over the Internet, intranet, or from a traditional client/server application.   (If your browser does not support inline frames, click here to view Figure 3 in a separate page.)

In the simplest case, Windows-based clients are tied to a host through the client support of terminal emulation. Terminal emulation, the most basic form of integration, requires that 100% of the legacy program is running on the back end computer with the client only emulating terminal protocols.

Terminal emulation techniques have evolved to support more sophisticated capabilities, typically by branching in one of three directions:

• protocol-specific script languages.
• programmatic support for screen reading and writing, known as screen scraping.
• support for higher level object and API interfaces.

Script languages

Using script languages with emulation software, programmers can add flexibility and control that goes beyond simple terminal emulationùin fact, the client can drive the emulation interface. Script languages typically send a string of commands or text, wait for a response, and then branch depending on the output returned to the screen. Script language commands are interpreted at run time rather then being precompiled, which offers a trade-off of flexibility over performance. High Level Language Application Programming Interface (HLLAPI) and Extended HLLAPI (EHLLAPI) are two examples of script languages that can be used with terminal emulation software, such as Wall Data's Rumba.

One of the most popular script languages for IBM environments is REXX. It offers more power than the protocol-specific script languages like HLLAPI because they were originally designed as general-purpose languages for system administration. Interpreters for REXX scripts are available on multiple platforms, including Windows, MVS, and OS/400.

An essential element of these script languages is file transfer. For example, a REXX program can issue a special copy command to request that a file be downloaded from the mainframe to the user's hard drive.

Screen scraping

The next level of terminal emulation is screen scraping, which you can see in Figure 3. In a session with an IBM host, screen scraping allows data to be sent to, and read from, specific locations on the screen. The advantage of screen scraping is this: it allows clients to interact with host programs that simply expect data to be filled in at field locations on the screen.

A client program, through Visual Basic for example, can create its own user interface, and, through screen scraping, present host data to a user in an entirely different, graphical way than was originally conceived by the host programmer.

Figure 4   Microsoft Internet Explorer with ActiveX Controls from other vendors, such as Attachmate and Wall Data, can employ HTML to screen scrape a 3270-based application in a browser.   (If your browser does not support inline frames, click here to view Figure 4 in a separate page.)

Companies can also provide screen scraping through browsers such as Microsoft Internet Explorer. Links to specific mainframe or AS/400 programs are accessed using HTML. These kinds of solutions are currently available from Wall Data and Attachmate, as seen in Figure 4.

Object interfaces

Terminal emulator products typically come with a proprietary interface that a programmer using C uses to access buffers, command arguments, and so forth. These interfaces tend to be used infrequently because they are vendor-specific, complex, and designed for use by a systems software developer. On the other hand, an increasing number of tools and developer products come with object-oriented interfaces for client execution of high-level services to reach legacy data. Typically these products abstract the underlying emulation cards and network protocols so that a developer isn't concerned with the specifics of the connection hardware. This table describes the some of these solutions and gives the Web site URL where more information is available.

Vendor Name	Solution Description	Web Site
Attachmate	EXTRA! product Family. ODBC drivers for DB2 and SQL/DS that are not tied to specific 3270 emulation card products; Visual Basic and OLE custom controls to provide high-level access to legacy computers, providing functions such as login, file transfer, wait for text, and so forth.	http://www.attachmate.com/
Intersolv	Virtual Data Warehouse contains a variety of middle-ware driversùcalled SequeLink driversùthat support multiple types of connectivity to back end databases. In turn Virtual Data Warehouse's development tools and end-user products operate similarly across environments.	http://www.intersolv.com/
Vmark Software	HyperStar Object Messaging Middleware that has implemented ODBC and high-level services on top many vendors' 3270 emulation cards and LAN protocols.	http://www.vmark.com/
Wall Data	Rumba Objects provide OLE controls to create 3270 or UNIX terminal windows, file transfer, application pasting, and printing. These objects come in separate versions for S/370 mainframes, AS/400s, and UNIX systems.	http://www.walldata.com/

Varieties of additional tools provide varying degrees of object-orientation for legacy data access. The tools include products such as Smalltalk environments, code generators, report creators, visual design toolkits, team development, and "business object" creators, and so forth. Many of these products provide a call-level API to achieve similar functionality for C and C++ programmers. Two good sources for information about these products is from programmer catalogs such as Fawcette's Component Objects and Companion Products and Hotlinx's Putting Client/Server to Work.

The Open Database Connectivity (ODBC) API, which has been layered over communication protocols to create links to legacy databases, can be accessed easily by an application developer. Many companies, such as Starware Inc.'s StarSQL, provide extremely high-performance legacy integration to Windows-based clients using ODBC and Microsoft SNA Server. Running on the client, ODBC calls are efficiently translated into IBM's Distributed Relational Database Architecture (DRDA) formatted requests for remote DB2 data.

Surfing the Mainframe

Microsoft Internet Explorer with ActiveX Controls from Wall Data and Attachmate can be used by development teams to build intranets that access a mainframe or AS/400 server as easily as accessing a Windows NT or UNIX server. A view of this relationship is available in Figure 5.

Figure 5   Accessing a maingrame or AS/400 through a browser.   (If your browser does not support inline frames, click here to view Figure 5 in a separate page.)

Using features of Wall Data Rumba ObjectX and Attachmate AcitvExtra!, developers can build browser-hosted applications that blur the lines between World Wide Web pages, enterprise systems, Intranet and client/server applications. An end user is no longer limited to accessing data only through a host display but can access it from any network terminal. Web authors and developers can offer host connectivity with much less code required than with EHLLAPI. Developers will also find that by using ActiveX, applications that access the host no longer need to run as a separate process connected through EHLLAPI, which greatly improves performance and reliability.

The advantages of using a browser with specific IBM 3270 emulation controls include:

• Point-and-click access to host computers for improved user productivity.
• Native support for TCP/IP and SNA over TCP/IP protocols for easier integration with client/server computing and intranet applications.
• A reduction in training and technical support requirements, because the organization and display of data to users takes on a consistent, uniform interface, regardless of the host system being accessed or the location of the data.
• A reduction in development costs and resources, because power users, IS professionals, and developers can quickly customize applications for mission-critical tasks.
• The preservation of existing hardware and software investments coupled with the offer of flexibility to make network changes.

• A full copy of RUMBA OFFICE 95/Windows NT with its 21 ActiveX Controls.
• Sample applications for Microsoft Visual Basic and Visual C++« development environments.
• Customizing features.
• Documentation in HTML, Windows Help, and Microsoft Word document formats.

Figure 6   Microsoft Internet Explorer with EXTRA! Objects provides a complete solution for surfing files on multiple platforms.   (If your browser does not support inline frames, click here to view Figure 6 in a separate page.)

Attachmate's EXTRA! Objects Control is another ActiveX Control for host data access, as seen in Figure 6. The control is just one of the many objects within Attachmate's EXTRA! Personal Client Product. Using these objects, a developer can easily build DCOM-compliant host data applications for an enterprise. The EXTRA! Objects Control works over a number of network protocols, including TCP/IP and IPX, and has specific advantages when used with Microsoft SNA Server, which include:

• load balancing
• hot backup
• SNA print service
• fault tolerance
• Logical Unit (LU) pooling
• 32-bit host graphics support
• 122-key keyboard support.

Figure 7   EXTRA! Objects as an Active Document in the Microsoft Office Binder.   (If your browser does not support inline frames, click here to view Figure 7 in a separate page.)

The Attachmate objects work with Active Server Pages to allow server-side scripting to host applications. The Attachmate Objects also provide drag-and-drop Active Document functionality so they can be integrated with ActiveX-compliant containers such as Microsoft Office, shown in Figure 7.

Figure 8   A graphical front end to the popular PROFS legacy application using EXTRA! Objects.   (If your browser does not support inline frames, click here to view Figure 8 in a separate page.)

EXTRA! Objects can also provide browser access to host applications. Figure 8 shows an Office version of PROFS front end to a Web server, displaying data stored on a mainframe computer.

There are several solutions available for information publishing of host data through a browser. Wall Data offers APREGGIO Live!, a Web-based, Microsoft Internet Explorer hosted publishing solution based on the Windows NT Server operating system. ARPEGGIO Live! dynamically converts legacy applications, information and databases, using HTML, for use on the Web, so organizations can take advantage of the Internet's accessibility and user base without investing any additional development resources.

The ARPEGGIO Live! Publishing Server is built on component architecture and uses many of the ActiveX Components that were developed for Wall Data's universal client software. These objects provide the interface between Web server applications and information on IBM mainframe computers and AS/400 hosts, as well as any ODBC database. Organizations install ARPEGGIO Live! on an Windows NT Server with Microsoft Internet Information Server, establish a host session connection through Microsoft SNA Server, and begin publishing dynamic, graphical information and applications live from existing legacy systems to Microsoft Internet Explorer. No programming or configuration is necessary.

Extending Across the Enterprise with Cross-platform, Multi-tier Applications

Situation: The need for cross-platformùWindows, UNIX, MVSùdistributed applications. This means:

• Passing parameters between different programming languages running on multiple platforms.
• Handling more complex processing, such as a two-phase commits between different database systems running on different operating systems.
• Enhancing legacy applications where the source code might be difficult to read or cannot be found.

Microsoft SNA Server

Many data centers today run client applications that need access to a mainframe transaction program and perform more than simple data access or return code checks. While LU 6.2 is the de facto standard for distributed transaction processing in a mainframe environment and is used by both IBM's Customer Information Control System (CICS), and IBM's Information Management System (IMS), the enterprise has evolved into a more complex environment.

The enterprise is moving away from low-level network protocol-oriented programming to business oriented application level transaction processing connectivity. A good example of this in a distributed environment is a DB2 or IMS application on the host that needs access to and update of a SQL Server table stored on a Windows NT serverùpossibly using the two-phase commit protocol to ensure referential integrity.

Microsoft SNA Server and "Cedar" provide the necessary solution. SNA Server provides the necessary host connectivity and integrates the desktop environment with an IBM host system to support line-of-business applications such as online transaction processing, decision support, intranet and Internet access, and terminal emulation. SNA Server also includes some unique functions, such as:

• Single sign-on capability, so users can employ one sign-on and password for multiple environments, such as Windows NT, AS/400, and S/390.
• Support for up to 5,000 users and 15,000 host sessions per server.
• Server-based IBM 3270 and 5250 print emulation, allowing applications running on S/390 and AS/400 applications can print to any LAN printer connected to an Windows NT Server or NetWare server.
• Shared folders gateway so PCs with no SNA client software installed can access shared folder files on an AS/400; these files appear to users as just another disk drive on a Windows NT Server.

SNA Server off loads the communications processing from a host computer and desktop PC to a Windows NT server, allowing clients to efficiently communicate with the host.

You can read more about Microsoft SNA Server on the Web site at http://www.microsoft.com/sna/default.asp.

Microsoft "Cedar"

"Cedar" saves an application developer the time and effort spent programming a specialized interface for a mainframe. As a generic proxy for a mainframe, "Cedar" intercepts object method calls and redirects those calls to the appropriate mainframe program; it 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 understood by Windows NT into the representation understood by the mainframe programs. All of the "Cedar" processing is completed on the Windows NT Server, and there is no host installation. "Cedar" uses standard communication protocols, such as LU6.2, for communicating between Windows NT and a mainframe computer.

Figure 9   "Cedar" is a Microsoft Transaction Server component that allows intranet, Internet and client'server appliations to inter-operate with mainframe programs.   (If your browser does not support inline frames, click here to view Figure 9 in a separate page.)

Figure 9 shows the "Cedar" configuration. Microsoft Visual Tools, such as Visual Basic and Visual C++, can be used to be build the client application. This application, which can also be executed from a browser, uses "Cedar" to access a transaction running on a mainframe. "Cedar" is a Microsoft Transaction Server (MTS) component; as such, it takes advantage of specific MTS features, including multiple threading, object management for improved performance, and load balancing. "Cedar" supports both CICS and IMS.

There is no "Cedar" footprint on a mainframe. "Cedar" uses standard communication protocolsùfor example, LU6.2 provided by Microsoft SNA Server 3.0ùfor communicating between the Windows NT Server computer and the mainframe computer.

The client application can run on any platform that supports DCOM. This solution does not require DCOM on the mainframe. Because DCOM is language independent, developers can build a client application using whatever languages and tools they are most familiar with, including: Visual Basic, Visual C++, Visual J++Ö, Borland Delphi, Powersoft Powerbuilder, and Micro Focus Object Cobol. That client can then easily make component invocations to a Windows NT Server running "Cedar." In the next section, specific code examples using Visual Basic will be examined and explained.

"Cedar" supports MVS version 4.3 and later, supports automation interfaces, and does not require any wrapper on the mainframe. Thus, the target customer for "Cedar" is an organization that wants to preserve the knowledge and experience of COBOL developersùand does not want to change their mainframe-programming modelùwhile taking advantage of new technologies.

Although "Cedar" can be used in simple mainframe data accessing applications, it becomes an even more powerful tool developers can use to extend transactions from the Windows NT Server environment to a mainframe. The client can reside on an intranet or Internet. Mainframe CICS and IMS programs appear as components in "Cedar" and are thus accessed through a browser as though they were any other Automation server.

Using "Cedar" and MTS, developers can easily make mainframe programs available to COM-supported clients and their Internet applications. In addition, MTS component designers can easily include mainframe applications within the scope of two-phase commit transactions. You can read more about Microsoft Transaction Server on the Web site at www.microsoft.com/transaction.

How application developers implement "Cedar"

The way in which a developer uses "Cedar" varies slightly depending upon whether a developer is starts from the Windows side or from the mainframe side of the application.

In either situation, a developer must follow five steps, regardless of development tool preference:

1. Define the application's methods and parameters. A developer uses the "Cedar" Interface Builder to define the methods and parameters for the application. This includes specifying the location and name of the mainframe transaction program. A developer should also verify the default data type mappings. The Interface Builder ships with the default mapping of Automation data types to COBOL data types.

   From the data type mapping, a developer creates the "Cedar" type library, .tlb, and COBOL data declarations for the mainframe application. To register the type library with MTS, a developer drags and drops it on the MTS icon.

2. Write the application. A developer begins writing the application using Visual Basic, Visual C++, Visual J++, or another tool that supports referencing Automation objects. A developer adds the appropriate "Cedar" object library to the application and then references those objects. The referenced class of objects can be viewed from a standard object browser such as is available 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. A developer then invokes the object's methods as appropriate through the application.

   Here is an example of the necessary code for a Visual Basic version 5.0 application to declare and create the necessary object instance code and parameters. First, a developer sets up the array tables; these correspond to the COBOL programùLINKAGE section for linked CICS; WORKING STORAGE for non-linked CICS and IMS.

       Dim P1 As Integer
       Dim P2 As Long
       Dim P3 As Single
       Dim P4 As Double
       Dim P5 As String
       Dim P6 As Currency
       Dim P7 As Boolean
       Dim P8(10) As Long
       Dim P9(10) As String
       Dim Retval As Integer
   'code to fill in P8 array (with values that are long) goes here
       Retval = MyObject.MyMethod(P1,P2,ByValP3,P4,P4,P5,ByValP6,P7,_
                  ByVal P8, P9)

   These variables will correspond to host variables, as seen in Figure 10, which "Cedar" will generate:

   LINKAGE SECTION.
   01	DFHCOMMAREA.
   	05 P1	PIC S9(4) COMP.
   	05 P2	PIC S9(9) COMP.
   	05 P3	COMP-1.
   	05 P4	COMP-2.
   	05 P5	PIC X(10).
   	05 P6	COMP-2.
   	05 P7	PIC S9(4) COMP.
   	05 P8	PIC S9(9) COMP	OCCURS 10 TIMES.
   	05 P9	PIC X(10)	OCCURS 10 TIMES.

   
   Figure 10   How "Cedar" handles parameter passing between different platforms and languages.   (If your browser does not support inline frames, click here to view Figure 10 in a separate page.)

   In addition to writing the application, a developer writes the server program based on the COBOL data declaration generated by the "Cedar" Interface Builder. A developer can write the server program as a mainframe program using COBOL, or write the server program on a Windows NT platform using a product such as Micro Focus COBOL and then move the program to the mainframe. The server must be on the mainframe at run time in order to execute with "Cedar."

3. Test the application. Once the application is written, it must be tested. A good way to test this in a distributed, cross-platform development environment is to test the mainframe code using another mainframe program. The "Cedar" component should also be checked independently to ensure that it is working as expected. The application should be tested end-to-end using the controlling object to drive the "Cedar" proxy and execute the mainframe transaction program. If transactions are enabled, a developer can first execute without transactions and, once successful, execute as part of a transaction. The same procedure can be followed for testing security: first execute without security and then again with security enabled.

4. Deploy the application's components. During development and testing, the "Cedar" type library was registered for "Cedar" and MTS on the test Windows NT computer. If the Automation server is running on a different computer, then the "Cedar" type library must be registered on that computer as well. In addition, MTS requires that the appropriate "Cedar"-created components be registered on any client. The export function in the MTS Explorer helps build the package required for client deployment.

   The client application is then deployed, along with any Help files that might be related to run-time errors that can occur on the mainframe server. The mainframe transaction program is then put into production.

5. Maintenance. A developer needs to work with the type library (.tlb) and the Interface Builder internal file (.ibf) to make any updates. The updates will cause a new "Cedar" type library to be created. Depending upon the extent of the changes, a developer might also use the newly generated COBOL data declarations to make the appropriate changes to the mainframe program.

As noted in the Introduction, most enterprise data is still stored in VSAM format. As a result, a real integration strategy must provide a way to access this information and make it available over the intranet as well as the Internet. Some examples of why customers want this kind of capability include:

• Web-based access to VSAM files.
• Decision support systems with fast record and file downloads.
• Windows NT-to-host backups.
• Bulk data copy from VSAM to SQL Server.
• Most any three-tiered development.
• Host-based data.
• Server-based business rules.
• Thin clients.

Many large enterprise data centers have considered, or even implemented, ODBC-to-Distributed Relational Database Architecture (DRDA). ODBC/DRDA drivers require all access requests to be structured as SQL statements, which are interpreted by mainframe DB2 and the AS/400 object file system. To process a SQL SELECT statement, the SQL engine in DB2 or the OS/400 file system accesses an index of the target physical file using a logical file called a view. For the majority of host-based data, there are no SQL view files associated with the physical data files.

Unlike ODBC/DRDA drivers, "Thor" provides record-level I/O access, which is a more flexible and faster method of accessing host-based data than this current approach. The majority of data files on mainframes and AS/400s are not designed to handle SQL, but instead are indexed by COBOL and RPG applications to allow access through a logical file created by the host application. The IBM DDM RLIO protocol allows any DDM-compliant application to access these logical files allowing for fast access to record-level data in all VSAM and all AS/400 files. Without the ability to read the host application-created logical file, ODBC/DRDA requests must be processed by continually scanning the data file until the requested record is found. Because DDM provides a more direct route to the target data, "Thor" promises to significantly outperform ODBC/DRDA drivers.

"Thor" in action

Figure 11   "Thor" uses OLE DB to provide fast access to many different file types, including VSAM.

From a PC point of view, there is really only one access method for getting at non-relational host dataùvia IBM's Distributed Data Management (DDM) server software. IBM DDM servers are available and running on the most popular host operating systems, including MVS and OS/400. To allow the easiest and most efficient access to files running on MVS and the AS/400, SNA Server with "Thor" will use OLE DB to provide a complete and single solution to access multiple file types on multiple platforms.

"Thor" requires no host application source code changes. Data can be accessed on an AS/400 and MVS VSAM data sets. The native record-level I/O interface, as defined by the DDM architecture, is used for optimal performance and ease of implementation. Customers can integrate non-SQL, non-relational information with SQL and relational data stores, without first migrating the data files to a Windows NT server platform. Customers can publish host-based information using the OLE DB data provider and the Microsoft Internet Information Server (IIS) Advanced Data Connector.

This VSAM connectivity supports both fixed and variable logical record length classes, full data set navigation, file and record locking, and file and record attribute preservation. All AS/400 and VSAM file types are supported, including Entry-Sequenced Data Set (ESDS),

Key-Sequenced Data Set (KSDS), Relative Record Data Set (RRDS), Partitioned Data Sets (PDS) and members, and alternate indexes.

DCOM on a mainframe

DCOM extends COM to support communication among objects on different computersùon a LAN, a WAN, or the Internet, as seen in Figure 12. With DCOM, an application can be distributed to locations that make the most sense.

Figure 12   DCOM allows applications to be distributed on the most appropriate platforms, without changing existing source code.   (If your browser does not support inline frames, click here to view Figure 12 in a separate page.)

Because DCOM is a seamless evolution of COM, companies can leverage existing investments in COM-based applications, components, tools, and knowledge, to move into the world of standards-based distributed computing. DCOM handles low-level details of network protocols leaving developers time to focus on building on the project and business rules.

The Software AG DCOM on MVS solution requires that the MVS program be a COM component. This requires a developer to write a COM wrapper for existing mainframe programs. This solution does not require that the Distributed Computing Environment be present on a mainframe

This solution requires MVS 5.2.2 or higher; TCP/IP is already implemented; and components will be written primarily in C/C++ rather than in 4GLs. DCOM on a mainframe uses the Microsoft Interface Definition Language compiler (MIDL), which generates C during component development, so a C/C++ compiler is required.

The Software AG DCOM solution is easy to understand. The client application can be written in one of a number of languages. The COM specification itself defines a way for one object to find and communicate with another. Location of distributed objects and components is transparent to the client. Once COM is initialized, an instance is then created which identifies the server required.

Clients and servers communicate using a remote procedure call (RPC). RPC is necessary for transport because both the client and the server contain objects in their own processes. On the Microsoft client, DCOM has multithreaded capabilities to allow remote component communications, exception and callback handling, and multiple protocols. On the host, the Software AG DCOM software provides similar functions as well as concurrent use of individual component interfaces and concurrent support for multiple clients.

Once the request is received by DCOM, it is passed to the Service Control Manager (SCM) which manages services started on the host. This includes all classes, programs, and services currently running. If the required object is not running then the SCM locates it, whether it is local or remote, and starts it running.

<< 1 2 3 4 5 6 7 >>

This site is being designated as a Year 2000 Readiness Disclosure and the information contained herein is provided pursuant to the terms hereof and the Year 2000 Information and Readiness Disclosure Act.