Interlinking UNIX and MVS
Colt S. Johnson Generally, traditional mainframe shops have not participated as fully in the "Internet revolution" as have organizations that are running an Open Systems-compliant or other UNIX-like operating system. This is due mainly to the design of the mainframe network environment. Most of these environments are highly proprietary, which makes it difficult to acquire or develop an appropriate TCP/IP stack. Additionally, mainframe shops tend to be heavily transaction-processing oriented. Acquiring TCP/IP stacks for mainframes is becoming more common, however, as more and more vendors are developing them. Using a commercial product, TCPaccess from Interlink Computer Sciences, we have been able to connect our IBM mainframe to our internal internet and offer selected internet applications to our users. The Interlink product line includes a physical translation device, an IBM-hosted TCP/IP stack, and IBM-hosted internet applications. This article describes how the IBM network is connected to an Open Systems type network using these products, and how the resulting applications look to the user. The Problem A typical Open Systems-compliant network consists of a UNIX machine, running internet applications that use the sockets protocol to send TCP/IP-framed packets to other machines over an Ethernet broad-band bus. While this configuration might be typical, it is hardly required. Each "layer" in the OSI Model (see the sidebar "SNA and OSI Compared") can have many variations. The only requirement is that components that interface to a specific layer must be able to "pretend" that they are talking to a similar layer on the other end. The IBM mainframe network is not nearly as diverse. Like the Open Systems model (OSI), the IBM network architecture, called Systems Network Architecture (SNA), partitions network functionality into multiple, layered protocols. But unlike the OSI model, SNA, because it is proprietary, assumes a specific implementation for each of these layers. Although each SNA layer is similar in function (see Figure 1) to the corresponding OSI layer, they are not compatible. This incompatibility is most obvious in the physical layer. You cannot simply plug an Ethernet cable into an IBM network bus; they are physically incompatible. Although it may be less obvious, the higher (software) layers are equally incompatible. Thus a TCP/IP stack (or at least suitable translation software) must be added to the SNA stack before internet applications can run on the IBM host. Also, once you have a physical connection and an appropriate stack, you cannot just recompile the internet applications and run them. There are fundamental differences in certain operating system services, particularly in file allocation, that require special handling at the application level. Interlink addresses these problems by providing a physical translation device, an IBM-hosted TCP/IP stack, a Berkeley-style sockets API for that stack, and IBM-hosted versions of certain internet applications, including ftp and telnet. The Product The core Interlink TCP/IP product is called SNS/TCPaccess. It provides code for host-to-host TCP/IP protocol and all the common TCP/IP client utility applications, including telnet for remote login, ftp for file transfer, and Simple Mail Transfer Protocol (SMTP) for electronic mail. (I will discuss only the telnet and ftp implementations in this article.) Interlink accomplishes the physical and electrical layer interface with their 3762 Controller. This box accepts the SNA bus and tag cabling on the IBM side and Ethernet (coaxial) cabling on the UNIX side. The 3762 controller comes preconfigured. If needed, reconfiguration (via the front panel) is very straightforward. Although physical installation of the box is as easy as attaching the appropriate cables, the mainframe system programming staff will need to perform the software installation on the mainframe. Several vendors provide mainframe TCP/IP packages, complete with the necessary hardware. We chose Interlink because they also supply a software toolkit (their "Programmer's Toolkit") to interface our Customer Information Control System (CICS) directly to our other UNIX applications. This toolkit allows our CICS programmers to develop networked applications without becoming "network professionals." Additionally, for those who have more particular programming needs, Interlink also supplies a Berkeley Socket interface to its network suite, allowing direct communication between mainframe programs and C programs in UNIX. telnet The Interlink adaptation of telnet runs in two modes: server mode and user mode. In server mode, networked UNIX users (or any network user running TCP/IP) can log into the mainframe and access applications that any mainframe user would normally access. In user mode, mainframe users go the other way and access networked UNIX hosts and applications. User telnet is UNIX terminal emulation from the mainframe and is invoked via the mainframe telnet command. The user can simply enter telnet or can type telnet followed by command line arguments that control the user session. The command line arguments are clearly explained in the SNS/TCPaccess User's Guide. In addition to the command line arguments, there are also several commands for session control once in the telnet program. The most important one is the connect command to connect your telnet session to a UNIX host, thus starting a session. This command takes the form of CONN host. Hostnames are specified, as with any hostname, either by a defined name in the hosts table that matches an IP address, or the actual IP address itself. Server telnet provides remote access from networked UNIX machines to mainframe application programs. Access to full-screen mode from a remote host is done through the telnet command that exists in any UNIX TCP/IP software package. You can use the telnet command from your UNIX prompt to connect to the mainframe IP address. Once connected, you'll be able to perform mainframe terminal emulation. Note: You will have to turn on 3270 data stream mode to access full screen applications. This is usually done through an implementation of telnet known as tn3270. So far, I have assumed you are connecting a mainframe to a UNIX host. It is important to note that any networked box running TCP/IP can connect to the mainframe through telnet. Because telnet was designed to supply terminal emulation in a full duplex, character-oriented environment, it is not always a natural fit to mainframe terminals, which expect to communicate half duplex, page by page. User mode can sometimes become awkward receiving screen data from UNIX. For example, as the screen would normally scroll by, the mainframe telnet screen pauses after each full screen. The user must press Enter to receive the next pending UNIX screen. When using telnet to execute a mainframe from a UNIX terminal, however, normal mainframe terminal screen behavior is provided, that is, half-duplex locked-keyboard operation. Even so, telnet is not totally invisible when used with certain mainframe applications that perform their own screen management. For example, if you invoke ISPF with telnet in batch mode, because telnet is not aware of the ISPF environment, certain ISPF display features, such as split-screen operation, will not work. All in all, however, telnet provides features that most users who need access to the mainframe will require. ftp The Interlink ftp applications allow users to initiate transfers either from the mainframe side or the UNIX side. Transfers can also be scripted for automatic operation in UNIX and built into job control language for automatic operation on the mainframe. In addition to the standard ftp commands, the Interlink adaptation includes site extensions, which allow for space allocation of mainframe datasets and many other parameters relating to the creation of a dataset on the mainframe. Another Interlink adaption to ftp is the ability to move files directly to and from mainframe tape subsystems. This gives you the ability to backup entire UNIXsystems utilizing the mainframes high capacity tape management system. To invoke ftp either from the mainframe or UNIX, the user simply enters the ftp command followed by any command line arguments desired for session control. Figure 2 shows an example of a UNIX ftp session for copying a file from UNIX to the mainframe. The open command is given the IP Address of the mainframe and connects the UNIX session to the mainframe. The user command, together with the userid and password, logs the UNIX user on as a mainframe user. The site command specifies to place the UNIX file in a dataset on mainframe disk volume "VOL99," allocate the dataset using the CYLINDERS type specifier, and to allocate five primary cylinders via the SPACE parameter. The lcd command changes the UNIX working directory to /ftp. This is the directory in which the UNIX file exists. The put command then copies the file data.txt to the mainframe dataset HOST.DATA.TXT. This dataset will be allocated as part of the transfer step due to the previous site command. Finally, the close command terminates the ftp session and the quit command exits ftp. These commands can be issued individually from the ftp user prompt or can be scripted to be executed automatically. Conclusion My experience with the Interlink package has been very positive. Although the IBM mainframe environment is different enough from the UNIX environment that certain mainframe attributes are never completely invisible to the other end, this package has allowed us to supply effective internet services to our users. I have focused on the TCP/IP stack and some of the implementation issues in the telnet and ftp applications; however, you should keep in mind that the Interlink package also includes support for SMTP (Simple Mail Transport Protocol), an implementation of the sockets interface and NFS(Network File Systems). I chose not to discuss these features because many sites already have some kind of internet mail interface, and because only some sites will be interested in developing on the sockets interface. I hope the coverage of ftp and telnet will give you a feel for how effectively the existing internet protocols can be adapted to the mainframe world.
About the Author
Colt Johnson earned a B.S. in Mathematics from Liberty University. He is currently Network and Communications Manager for J. Crew Group, Inc. in Lynchburg, VA in the areas of MVS/ESA, UNIX, and MS-DOS. During the past 13 years, he has done extensive systems work in the areas of PCs, telecommunications, UNIX, IBM Mainframe, and C programming, as well as cross-platform system integration. He can be reached at 6479549@mcimail.com.
|