I began my IT career in the mainframe world. I got my first taste as a 16 year-old schoolboy on a work experience placement (changing tapes on ICL 1900 mainframes at the local hospital) and then as part of my Computer Studies degree I joined ICL, a name now consigned to the history books, where I learnt about Series 39 mainframes and VME as part of my time attached to an operating system support team. It could have been very different – I had the chance to start out with IBM, where I would have learnt about the world of OS/2, RS/6000s, AS/400s and System/390 mainframes. Nowadays I’m employed by a systems integrator, working almost exclusively with Microsoft products, so when I had the chance to attend a session about Microsoft Host Integration Server (HIS) 2004 at Microsoft’s IT Forum Highlights event, I decided to take a look at how a Microsoft infrastructure can integrate with the world of IBM zSeries mainframes and the systems network architecture (SNA) using HIS, which Microsoft claims can leverage existing host assets to integrate IBM mission-critical host applications, data sources, messaging and security systems with new solutions developed using the Microsoft Windows Server System platform.

Michael Platt (an IT Pro Evangelist for Microsoft UK) explained that it is surprisingly difficult to integrate mainframes with Windows systems because of the way they view the network and there are five levels of integration to consider:

• Network.
• Application (e.g. CICS).
• Data (DB2 is different on a mainframe to on UNIX).
• Security.
• Deployment.

Different acronyms are used by Windows and mainframe technologies and it is important to outline some terms which may help to put the rest of this post into context:

• A PC to host gateway is concerned with translation between PCs and mainframe physical units (PUs) and logical units (LUs).
• LUs may be 3270 or 5250 terminals, which originally used co-axial connections over which SNA was run. Then, in the 1980s, SNA 6.2 brought support for peer-to-peer networks. The old co-axial connections were replaced with token ring (and eventually Ethernet) LANs using a data communications and terminal controller (DTC) or dial-up synchronous data link control (SDLC) over X.25 for WANS.
• Front end processors (FEPs) relieve some of the processing from the mainframe CPU and these are examples of PUs.
• SNA gateways consolidate branch traffic for transmission across the network.

Network integration

Over time, TCP/IP has become all pervasive, moving from UNIX systems, to desktop PCs, across the WAN and eventually into the data centre, bringing some issues for IBM mainframes, which use a 1920Kb block size. TCP uses a 4Kb block size and so it has always been seen as inefficient to run TCP on a mainframe leading to various approaches that have been taken over the years:

• TN3270 is a telnet-based 3270 clear-text terminal emulation session (although SSL and TLS can be used from HIS 2004 onwards); however the mainframe still spends a lot of time performing protocol conversion so this cam be offloaded as a service that then uses native SNA to communicate with the mainframe (allowing more connections).
• The host print service was intended to resolve issues with expensive mainframe printing allowing print requirements to be offloaded to departmental printers, but mainframes use extended binary coded decimal interchange code (EBCDIC) to represent characters whilst PCs and other devices use the American standard code for information interchange (ASCII), leading to more conversion.
• Multiprotocol transport networking (MPTN), implemented as IBM Anynet provides an SNA stack for the client, allowing full application to applications communications but because it is implemented in software, it uses significant numbers of of CPU cycles, resulting in performance issues (consequently Microsoft have never offered an MPTN service for HIS).
• Data link switching (DLS) uses hardware to tunnel SNA, running TCP/IP across the network itself, but requires expensive routers. Some vendors added additional technology, whilst others never offered DLS. Microsoft’s answer is the distributed link service (also called DLS), which passes data between HIS servers using TCP/IP (UDP and native IP for performance), with SNA at either end.
• Today, IBM’s stated direction for SNA over TCP/IP is IBM enterprise extender which uses high performance routing (HPR), an extension to advanced peer to peer networking (APPN). IBM is dropping support for its 374x FEPs and encourages the use of adapters in its open services architecture (OSA), running SNA, TCP/IP, etc. as appropriate. Microsoft supports the same technology, through IPDLC, and the core network integration portion of HIS enables HIS to participate in an IBM enterprise extender environment in a branch office, in a central location, or even within the data centre, directly-connected to the mainframe using gigabyte ethernet.

Application integration

The HIS transaction integrator (TI) (formerly know as COM transaction integrator for CICS and IMS), has been enhanced to offer support for applications providing web services integration so that developers can pragmatically access the mainframe from a Microsoft .NET application. With TI, Windows developers can use the Windows-initiated processing (WIP) technology to wrap existing line-of-business processes found in IBM AS/400 systems, mainframe CICS and IMS applications, as XML web services or .NET server components. In addition to WIP, TI offers a reverse path through host-initiated processing (HIP), allowing developers to produce bidirectional and asynchronous enterprise integration solutions without using IBM MQSeries.

Data integration

HIS offers a number of data integration technologies, including:

• Industry-standard ODBC Driver for DB2.
• Component object model (COM) OLE database providers for DB2 and host file systems (mainframe and AS/400).
• .NET framework-enabled managed provider for DB2.

New to HIS 2004 is the DB2 network protocol client (DRDA AR) over which the ODBC, OLE DB and Managed Provider communicate with remote DB2 database servers, allowing these data providers to offer expanded functionality such as two-phase commit for DB2 distributed transactions over TCP/IP and connection pooling when using enterprise single sign-on.

HIS 2004 also supports asynchronous messaging through its MSMQ-to-MQSeries bridge, allowing administrators to link applications that use inter-platform message queueing, with support for MSMQ 2.0 and MQSeries (Websphere MQ) 5.1.

Security

The administration and runtime components in HIS 2004 support a new secure product configuration (with an associated configuration wizard) and are “secure by default” when installed. Only HIS administrators need administrative permissions (whereas in previous versions HIS runtime users were also required to be administrators). although there are some security considerations when upgrading from previous versions. Access request levels can be set as read, read/write, manage, or full control and control methods can be read/write or manage.

Support for enterprise single sign-on (SSO) enables seamless integration of security credentials across Windows Active Directory and IBM host systems for both users and applications, including 1:1 and Group: 1 association, with all the main IBM security systems supported. The HIS enterprise SSO provides the base infrastructure that, along with third-party software products, provides for a secure password management solution including Windows-initiated and host-initiated password synchronisation.

As mentioned previously, with HIS 2004, the telnet 3270 service has been enhanced to offer secure sockets layer (SSL) and transport-level services (TLS) support. Administrators can now increase the overall security of the network when accessing mainframe terminal and printer resources over TCP/IP, including authentication of access to mainframe sessions and encryption of host data between client and server.

Deployment

HIS 2004 runs on Windows 2000, Windows XP or Windows Server 2003 and support for clustering is provided in order to scale up and out to address the volumes required by large enterprises. HIS uses its own internal domain structure as part of the SNA integration and includes SNA Manager – a Microsoft management console (MMC) snap-in provided for managing key components of HIS, which has been improved to offer better usability through refined wizards and prompts (there is also a command line interface). A centralised SNA diagnostics tool is also provided, allowing administrators to test and troubleshoot network connections and resources.

Setting up a link involves:

• Generating a new link service.
• Creating an SNA Service connection.
• Creating a new display LU.
• Assigning LUs to a configured user.
• Starting the SNA service.

It is then possible to connect to the mainframe using a 3270 client.

Establishing an advanced program-to-program communications (APPC) application connection involves:

• Creating a new APPC connection.
• Setting up the local APPC LU.
• Setting up a remote APPC LU.
• Starting the SNA Service.

HIS diagnostics can then be used to carry out an APPC test.

The future for HIS

So what about the future for HIS? As a product which started life as running on OS/2 as SNA Server, it may not be the most exciting offering in the Windows Server System, but it is functional, and organisations still buy it! On that basis, as long as there is a market, I can see Microsoft continuing to develop HIS with further support to extend the web services platform to the mainframe.

Links

HIS on the Microsoft website
IBM SNA protocols (Cisco)
Microsoft HIS whitepapers