Host Integration Server (HIS) lets you bring together resources from host servers running a variety of operating systems and serve them to clients through custom client applications, a Web browser, database connections, and terminal emulation applications. HIS is a complex product that takes careful planning and time to deploy. In this Daily Drill Down, we’ll take a look at some of the issues you’ll face when planning the resource access aspects of HIS deployment.

HIS: A bridge between systems
In a nutshell, HIS serves as a gateway between clients and back-end mainframes, AS/400 and UNIX systems, and other servers. HIS enables clients to directly access host systems through 3270 and 5250 terminal emulation software. It also provides database tools that enable clients to query a variety of data sources on the host servers. HIS supports relational database access, record file access, file transfer, and AS/400 data queue access. Clients also have file and print service access on the host servers through HIS servers.

In addition to this semidirect client access, HIS can serve as a gateway to host servers for third-party and in-house applications. HIS includes a component called the COM Transaction Integrator (COMTI), which lets developers create applications that enable Customer Information Control System (CICS) and Internet Mail Service (IMS) applications running on the host servers to participate in COM-based transactions. HIS also includes a component called the MSMQ-MQSeries Bridge to facilitate transaction processing between Windows platforms and host servers. The bridge sits between MSMQ and MQSeries, translating messages to and from the two to provide reliable bidirectional message transfer. With this feature, your developers can create applications using a variety of development tools. The applications can be stand-alone, residing on the users’ workstations, or server-based/Web-based applications that clients access through their Web browsers. By providing ODBC to host-based data, HIS enables developers to easily integrate back-end data sources in Web content.

HIS provides the network components that enable Windows 2000 Server systems running HIS to communicate with host servers. HIS builds on Microsoft’s SNA Server, enabling HIS servers to act as SNA gateways for other servers and clients. It performs protocol translation and eliminates the need for the clients to host an SNA protocol stack. Clients can continue to use their existing protocols, such as TCP/IP.

More information on HIS

For more details about the features and abilities of HIS, see the Daily Drill Down “Host Integration Server bridges the gap between Windows servers and large systems.”

Planning HIS infrastructure
There are several issues to consider when planning an HIS deployment, even in a test scenario. One of the first steps is to determine what hardware you’ll need for the HIS server, including the network connection to the host systems. In general, any computer powerful enough to run Windows 2000 Server is a reasonable platform for HIS. However, you need to adjust your production server hardware requirements based on the client load on the server, what other services (if any) the server will perform, and a handful of other factors.

Hardware considerations
You should choose a multiprocessor system for HIS servers that handle 1,500 or more clients. Naturally, the amount of RAM in the server has a tremendous impact on performance, particularly for reducing or eliminating paging. You should consider 256 MB of RAM as a bare minimum, although you can run Windows 2000 Server and HIS on less. I recommend at least 512 MB on a multiprocessor system that will handle more than 1,500 clients.

On servers that will handle fewer clients, or that will handle a large number of clients with a relatively light load (i.e., infrequent access), a single-processor server is a reasonable solution. Installing 128 MB of RAM in your test server is workable, but a production server should have 256 MB or more. Keep an eye on server performance and add memory as needed to reduce paging; also try to keep CPU utilization down to 50 percent or so. As CPU usage increases, you may need to think about moving to a multiprocessor system or balancing the load to additional HIS servers.

In addition to the HIS server itself, you also need to consider how the server will connect to the host servers. Your options depend in large part on the network infrastructure used by the host servers. Choose network hardware for the server to support the connection type offered by the server(s). In cases where multiple adapters are feasible, consider installing additional network interfaces to help reduce network load.

Finally, if the server will be performing other tasks in addition to serving as a HIS gateway, take those additional tasks into account when you develop the hardware specifications. For example, if you intend to use the server for local file and print services, adjust the amount of memory and available disk space accordingly to accommodate those services.

Before you rush out and grab a new server, however, you need to take a look at your host servers to make sure they’ll coexist with HIS. Compatibility for 3270 emulation and host print server requires any version of IBM VMS, OS/390, VSE, or VM, while 5250 and AS/400 print server compatibility requires OS/400 2R3 or System/36 5.1 with the PC Support/36 Coexistence support PRPQ installed on the server. HIS also supports any other server platform that provides SNA protocol support compatible with these OS versions.

You should also take a look at the database management system (DBMS) on the host servers to make sure the servers are compatible with HIS. If you intend to use OLE DB, the host systems must be running OS/400 V3R2 or later, or Distributed File Manager/MVS V1R2 or later. Support for DB2 through SNA requires DB2 for MVS V4R1, DB2 for OS/390 V5R1, DB2 for OS/400 V3R2, or any later version of these three. If you’ll be using direct TCP/IP access to the host servers for DB2, you’ll need DB2 for OS/390 V5R1, DB2 for OS/400 V4R2, DB2 Universal Database for Windows NT V5R2, DB2 Universal Database for AIX V5R2, or any later version of these DB2 implementations. Support for application access through COM requires MVS with at least CICS V3.3 or IMS 4.0 and MVS APPC. Support for atomic transactions requires IMS V6.0. You can also support COM applications with VSE V2.1.0 and CICS 2.1.0 or later. Connecting to the Shared Folders Gateway Service requires OS/400 V2R3 and System/36 5.1 or later and PC Support/36 Coexistence support PRPQ.

Client requirements
HIS supports a very broad range of clients, thanks to its reliance on standard protocols and technologies. HIS directly supports Windows 2000, Windows .NET, Windows XP, Windows NT, and Windows 9x clients. You can add support for Macintosh, UNIX, and VMS clients by adding third-party client software. There are no significant requirements for any of the supported platforms to add the HIS client, other than the basic requirements for the target operating system itself and enough free disk space to accommodate the client installation.

However, you should give some thought to how you’ll deploy the client software to users’ workstations. You can use the Microsoft Installer package included on the HIS CD to deploy the client, placing it on a network share to make it accessible for end-user installation. Alternatively, you can use deployment tools such as SMS or group policy to deploy it to user systems automatically. If you prefer a Web-based approach, you can deploy clients using the HIS Web Client. The Web Client is included on the HIS CD, and it’s available by download from the Microsoft Host Integration Server home page. It allows users to simply click a link on a Web page to download, install, and configure the HIS client software. I’ll cover the HIS Web Client in more detail in an upcoming Daily Drill Down in which I’ll cover actual HIS deployment.

Evaluating 3270 and TN3270 support
As I mentioned previously, HIS supports 3270 client access to host servers. It does so through 3270 logical units (LUs). An LU in HIS defines a resource on a host server and provides the means by which users gain access and use that host resource through 3270 emulation on their client systems. HIS supports display (LU2), printer (LU1 or LU3), application (LUA), and downstream LUs. When you configure HIS, you create the session definitions that link the LU number on the HIS server with the target host resource.

One step when planning an HIS deployment is to identify the resources on the host servers for which you need to create LUs on the HIS server. A session can be permanent and initiated at HIS startup or created dynamically as needed.

You also need to think about how you’ll create the LUs. When you define LUs, you can configure them individually or in an LU pool. Using a pool rather than an individual LU can reduce the number of required LUs for a group of users. When a user requests a session, HIS assigns it from the pool as long as there is a remaining LU in the pool. For example, let’s say you create an LU pool to serve 50 users with 10 LUs in the pool. This means that any 10 of the 50 users can access the resource at a given time. This is a good solution for groups that use resources infrequently because it reduces the number of LUs you need to define and manage.

Also, when you create an LU, you can assign it to a workstation instead of a user or group. Assigning an LU to a workstation ties the LU to the workstation so that anyone using that workstation has access to the LU. This can simplify resource allocation because you don’t need to create individual LUs or pools for each user or group. Any user can log on from any workstation to which an LU is assigned and still access the target resource.

Finally, think about fault tolerance and load balancing when you begin laying out your plans for configuring resource access. HIS provides failover capability for connections so that a user can easily reconnect to a resource if the existing connection fails. Think about how you’ll structure your individual LUs and pools to provide failover capability for specific resources, making sure to provide redundant connections as needed. Also, keep in mind that HIS performs load balancing when allocating LUs from pools, automatically allocating a random LU from the pool when a user requests a session. When you create the LUs in the pool, you can use different connections and servers for the target resource. So how you design and create the pool has a big impact on both fault tolerance and load balancing.

In addition to 3270 support, HIS also supports TN3270 Logical Unit for Applications (LUA) LUs. HIS supports TN3270 for display sessions, TN3287 for printer sessions, and TN3270E for extended display and print sessions.

You face many of the same considerations when planning LUA-type LUs. For example, the same fault tolerance and load balancing issues apply, so examine how your users will access the resources and create pools and LUs accordingly. In addition, you can assign an IP address or subnet to an LUA LU in much the same way you can assign a workstation to an LU. Assigning the IP address restricts access to the target resource only from the target IP, or in the case of a subnet, from workstations in that subnet. You can also use the workstation name rather than the IP address, as long as it can be resolved by DNS or WINS.

Lastly, examine your network and resources to determine where downstream connections might be needed or useful. A downstream system is one that uses an HIS server as an intermediary between it and the host server. To the downstream system, the HIS server is the host server, and HIS acts as a physical unit (PU) gateway. The HIS server takes care of the connection to the actual back-end server.

Downstream systems can help you aggregate resource access and allow HIS to act as a PU concentrator. Multiple downstream systems can connect through the same HIS server(s) to ultimately access resources on the host servers. This can help reduce administrative overhead on the host servers, because you need only configure the HIS server(s) for the connection on the host server, rather than all of the individual downstream systems. Downstream devices must be PU 2 devices or run client applications that emulate PU 2 devices. The HIS server must then have a connection in both directions—one to the host server and one to the downstream system. As you begin planning your HIS deployment, determine where downstream systems will offer benefit and plan accordingly.

APPC support
HIS supports Advanced Program-to-Program Communication (APPC) to provide network services over SNA. APPC supports 5250, TN5250, and APPC-based file transfer from host servers to clients through HIS. Peer-to-peer SNA-based networking between PU 2.1 devices is referred to as Advanced-Peer-to-Peer Networking (APPN). APPN network devices are referenced in HIS by APPC LUs, and applications running on APPN devices are called transaction programs (TPs). HIS servers appear on the APPN network as a PU 2.1 node.

A TP requires two LUs to communicate with another TP or system. When you configure HIS to support a TP, you configure a local LU on the HIS server and a corresponding remote LU on the remote host. When a 5250 client needs to access the remote host, it connects to the local LU on the HIS server, which in turn connects to the remote LU on the remote host. HIS then acts as a gateway for the client.

Supporting 5250 client sessions requires setting up the LU pair, which means creating the local LU on the HIS server and the corresponding remote LU on the remote host. As with 3270 communications, you can create individual LUs, but you’ll likely find that LU pools provide more efficient administration. They also offer the advantage of automatic load balancing and failover that I mentioned previously for 3270 sessions. When planning support for 5250 services, identify the client services and host resources, and start building a list of LU pairs you’ll need to create in order to support those connections. Also, consider the distribution of users and groups and how you need to structure the LU pairs to provide adequate performance, reliability, and failover support for resources.

HIS enables clients to access AS/400 systems over TCP/IP via support for the TN5250 protocol. Setting up support for TN5250 sessions requires creating the LU pair that will support the connection between the HIS server and remote host. As with TN3270 connections, you can specify the IP address or subnet for a TN5250 LU to restrict access to it, if you need to.

A third step you might need to take to support APPC connectivity is to plan and deploy file transfer capability and/or file sharing between clients and host servers. HIS provides APPC File Transfer Protocol (AFTP) support, an FTP-to-AFTP gateway, and a Shared Folders Gateway Service that enables clients to access host server-based resources as if they were shared on the HIS server. Supporting AFTP client connections requires you to create LU pairs to support the connection, with essentially the same considerations as when you create LU pairs for 5250 and TN5250 client sessions.

In some cases, you might want to provide host file access to clients that don’t have the HIS client installed, or you might want to provide file access using methods other than AFTP. In those situations, you can use the Shared Folders Gateway Service included with HIS to enable clients to access host-based files. To use the gateway service, you define an APPC LU on the host that references the shared resource. You then create an APPC LU on the HIS server that HIS uses to establish the connection to the remote LU. The gateway service then makes the remote shared folder and files appear as a subdirectory of its own file system so that, to the clients, the remote folders appear as if they are hosted by the HIS server. This enables users to access them through the file sharing mechanisms built into their client operating systems rather than using the HIS client. As part of your deployment planning process, analyze the folder and file resources located on host servers that you need to make available to clients, and then decide if the gateway service fits your needs. If so, plan on adding the necessary LU pairs and structuring folders and files as necessary to suit the users’ needs and capabilities.

A journey of a thousand miles
As you can see, deploying HIS isn’t something you can do on a whim or without the help of the mainframe folks. What I’ve described here are only a few of the considerations and preparations you need to make before planning an HIS deployment. There are many other issues to examine before running setup from your HIS CD, such as physical considerations and network infrastructure planning. We’ll cover these issues in upcoming Daily Drill Downs, but for now, you can get together with your mainframe colleagues to get the process started.