Doug Dedo and Greg Nelson
Microsoft Corporation
March 19, 1997
Organizations worldwide are looking for ways to better leverage major legacy applications with new technology, which typically reside on the IBM Multiple Virtual Systems (MVS) platform. The approach outlined here maximizes the strengths of the existing architecture, allows use of more efficient development languages, operating environments and methodologies, and minimizes the impact of older technology or poor design decisions made in the past. Specific technologies from multiple vendors are reviewed for leveraging host-based solutions, with the goal of making data processing easier, less expensive, more reliable, and faster.
Many mission-critical systems, ranging from accounting to sales tracking to air traffic control, were created years ago and were typically written in COBOL. According to PC Week, there are over 100 billion lines of this kind of code just in the United States—and it is not going away anytime soon. The Gartner Group estimates that 80 percent of today’s legacy applications will be in use in the year 2000. While the importance of these systems is not questioned, the problem of getting the most from legacy systems with new technology has not been easy.
Figure 1. Most legacy data is still stored in VSAM files.
Replacing or re-engineering legacy applications is not widely viewed as cost-effective because migrating them can be complex, especially for non-relational systems. Moving legacy systems to improved host-based technology has not occurred either. For example, in the early 1980s, IBM released its DB2 relational database management system (RDBMS) for the Multiple Virtual Systems (MVS) operating system. Today, many organizations that use mainframes are still dependent on IBM’s Information Management System (IMS) and Virtual Sequential Access Method (VSAM), as shown in Figure 1. During 1996, over 2 billion IMS transactions were still being processed daily, according to International Data Corp. The reality is that legacy systems, in one form or another, still provide most online transaction processing for many large organizations.
Therefore, integration is the best strategy for leveraging mainframe-based solutions with new technologies. This approach maximizes the strengths of the existing architecture, allows use of more efficient development languages, operating environments and methodologies, and minimizes the impact of older technology or poor design decisions made in the past. Using Microsoft® Windows NT® Server as the middle-tier and Microsoft SNA Server™ for host connectivity, companies can:
Figure 2. Three levels for legacy integration.
You can see in Figure 2 that there are three levels of integration, each designed to maximize data processing assets. At the most basic level are protocols and formats. Included are stable and well-defined standards, such as LU6.2, SNA, and terminal emulators. Next are multiple platforms sharing file and print services, with a single cross-platform login to ease administration of security. The highest level allows location independent data and transactions that support different hardware platforms, and allow program interoperability to provide the most open, flexible solution for legacy co-existence with Intranet, Internet, and client/server systems.
By extending legacy applications and using existing programmer knowledge with the advantages of the desktop, corporations can enjoy multiple benefits:
Microsoft and its partners understand the importance of these systems to their customers and together offer a collection of affordable, integrated solutions to make accessing legacy systems easier, less expensive, more reliable, and faster. In this paper, we also address common scenarios many organizations face and outline the technologies available to achieve this goal.
These are the specific technologies and products that are essential for successfully integrating client/server, intranet, and Internet applications with legacy systems.
Terminal emulation software provides the means for a client to interact with a host as if it were a terminal. The application is displayed the way it looks on an IBM 3270 terminal screen, with some of the advantages of graphical user interface, such as windowing, screen print, and other basic services.
Scripting languages offer developers more control over a client running in terminal emulation mode. This includes receiving return codes and downloading files from the host to the client.
Screen scraping is the next integration level and can be used by a development team to create a graphical front end using either a rapid application development (RAD) environment or a more traditional language such as C++. Functionality can be split easily between the client and the host, while providing easier use and new capabilities, such as images and scrollable lists, and the security of host-based data. There is also a new category of screen scraping technologies in which a browser can be used to interact with a host.
Object interfaces are used by programmers to execute high-level services on a client to reach legacy data. Object-oriented interfaces predominately support Microsoft VBX and OCX conventions; these object extensions are based on Microsoft Visual Basic® or ActiveX™ technologies. One of the most popular application program interfaces (API) that can be accessed easily by an application developer is Open Database Connectivity (ODBC), an API that is layered over communications protocols to create links to legacy databases, such as DB2.
Systems Network Architecture (SNA) is the foundation for efficiently integrating legacy applications and data with modern network systems and applications, to give users convenient, reliable access to host systems. Microsoft SNA Server 3.0 is one of the leading SNA gateways.
VSAM file access will be easier with a new, forthcoming component of SNA Server, currently code-named “Thor.” ”Thor” allows VSAM access from COM-based clients. It is designed to provide customers with tools to easily and efficiently integrate mainframe VSAM and AS/400 data sources with other enterprise-wide data sources using a common method—OLE DB.
Program-to-program interoperability and complex distributed processing becomes practical with a technology currently code-named “Cedar.” “Cedar” is a Microsoft project that will provide a bridge between distributed clients and mainframe-based applications. Developers can now build powerful new applications using the Microsoft Active Server to leverage existing mainframe logic and associated data without making system changes to the host or calling APIs on the client. This is possible because “Cedar” is executed from a middle-tier Windows NT Server computer.
DCOM for MVS, ported by Software AG. Based on the Windows NT source code, Software AG has released DCOM on Unix (Solaris) and most recently MVS, with plans for other platforms, including the AS/400 and other versions of UNIX. Using DCOM:
Accessing host data and applications can be implemented easily with Microsoft Internet Explorer with ActiveX Controls for host access, screen scraping, and data publishing. Using Microsoft Internet Explorer and ActiveX, corporate users can now “surf” their environments, tapping the new role of the mainframe—or AS/400 or other mid-range systems—as an Internet/intranet server. The ActiveX Controls to accomplish this are available from Wall Data Systems and Attachmate Corporation. In addition, Wall Data offers Arpeggio to provide information publishing as well as advanced screen scraping of host applications. In each case, all the complexities of enterprise information and application access are handled in the ActiveX Controls.
The following scenarios describe the most common needs for integrating distributed applications with legacy systems:
Situation: Windows-based clients need access to host programs. The client acts as a terminal to the host. Advanced screen scraping 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.
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 percent 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:
There are varieties of products that allow a client running the Windows platform to emulate a IBM 3270 terminal as the native terminal an IBM S/370 system expects. Some of the vendors who offer such solutions are Wall Data, Attachmate, and IBM.
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.
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.
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.
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.
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 mainframe or AS/400 through a browser.
Using features of Wall Data Rumba ObjectX and Attachmate ActivExtra!, 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:
The RUMBA ObjectX Software Development Kit (SDK) is included with Microsoft Internet Explorer 3.0. The SDK includes
Because all the complexities of enterprise information and application access are fully encapsulated in the RUMBA ObjectX controls, connectivity application development becomes a matter of inserting an RUMBA ObjectX control into a project. This can amount to a significant savings in time and programmer resources.
Figure 6. Microsoft Internet Explorer with ActivExtra! provides a complete solution for surfing files on multiple platforms.
Attachmate’s ActivExtra! 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 ActivExtra! 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:
Figure 7. ActiveExtra! as an Active Document in the Microsoft Office Binder.
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 ActivExtra!.
ActivExtra! 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 ARPEGGIO 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.
Situation: The need for cross-platform—Windows, UNIX, MVS—distributed applications. This means:
Recommended Solutions: Microsoft SNA Server 3.0 and “Cedar,” with DCOM on a mainframe.
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:
With SNA Server, each PC uses a standard local area network (LAN) protocol such as TCP/IP, IPX/SPX, NetBEUI, Banyan VINES IP, or AppleTalk to connect to one or more Microsoft SNA Server 3.0 computers. These Windows NT–based systems in turn are connected to mainframe and AS/400 systems using IBM SNA protocols. Tools are provided for easy system setup and centralized graphical administration, as well as support for all major PC and network operating systems, LAN types, SNA hosts, and connection types.
SNA Server offloads 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/.
”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 applications to interoperate with mainframe programs.
Figure 9 shows the ”Cedar” configuration. Microsoft Visual Tools, such as Visual Basic and Visual C++, can be used to 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 http://www.microsoft.com/transaction/.
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:
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.
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, which ”Cedar” will generate:
LINKAGE SECTION.
DFHCOMMAREA.
P1 PIC S9(4) COMP.
P2 PIC S9(9) COMP.
P3 COMP-1.
P4 COMP-2.
P5 PIC X(10).
P6 COMP-2.
P7 PIC S9(4) COMP.
P8 PIC S9(9) COMP OCCURS 10 TIMES.
P9 PIC X(10) OCCURS 10 TIMES.
05 RETVAL PIC S9(4) COMP.
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.”
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.
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:
A planned component of SNA Server addresses this need. Currently code-named “Thor,” it is an OLE DB data provider for IBM’s Distributed Data Management (DDM). ”Thor” allows access by file and by record or stream I/O interface and record level I/O, respectively, as shown in Figure 11. The stream I/O interface is useful for accessing entire host files or data set members at one time. Microsoft is using the DDM stream I/O interface to offer users access to VSAM data set members as though they were files on a Windows NT Server local drive.
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.
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 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.
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.
Many large data center IS managers will find it is not a case of choosing between ”Cedar” and DCOM; both will benefit the enterprise, because the type of application determines which makes the most sense.
The dynamic nature of DCOM means that new application features can be built that do not affect the client, eliminating software distribution and system interrupts. The components are black boxes, providing their functionality through well-defined interfaces. DCOM allows components to talk to each other, regardless of the platform or the programming language. So, components written in Visual Basic, Visual C++, or Java, for example, can all work together to provide the best solution. This also means rapid parallel development of individual components that can then be easily plugged together.
DCOM can be the best choice if the application requires:
”Cedar” is best if the application requires:
The enterprise is at a point where integration is the most viable strategy. While mainframe computers represent an essential part of the data center landscape, the promise of new and better technologies must still be addressed.
Microsoft and our partners offer a real answer to the question of how to leverage mainframe-based solutions with new technologies—one which is not based on a single vendor but instead on integrated solutions. These solutions are fully scalable to accommodate new growth, new requirements, and new technologies while at the same time provide truly open solutions that allow organizations to pick the products and vendors who best meet their current and emerging needs. We have also addressed the need for leveraging the substantial technical and business advantage IS groups represent in mainframe developers.
The bottom line: