1. IntroductionThe IBM AS/400 and Linux have been very successful for many years and it is increasingly important to find the best ways to integrate their usage. It should be noticed that what is described below about Linux is generally applicable also to UNIX. IBM has done a lot of work from version 3.1 of the OS/400 to improve the coexistence with the Unix and PC applications. Recently IBM has also announced that Linux will be installed as an option on the AS/400 by using a separate Logical Partition (LPAR). The following point will examine in detail how the recent changes make the integration of these two worlds easier. |
2. The AS/400 Integrated File SystemThe Integrated File System has been built in the operating system after the version 3.1 to allow an easier coexistence between the AS400 native applications and stream file oriented systems such as Linux, UNIX, DOS and OS/2. . The traditional AS/400 approach consists of fixed format records stored in database files residing in libraries (single level containers with the exception of QSYS that contains all other libraries). Normally each file (stored in the DB2 UDB database for the AS/400) has an external definition of the component fields that is automatically copied into each program that uses the file. This model is very good for business applications because it allows to identify and process each field of any database file easily, but is not very suitable for other files such as word processing documents, Web pages, Java classes and graphics. The world of Unix, Linux and PCs has been instead traditionally oriented towards the use of stream files that have not a fixed structure and are well suited for documents processing. IBM had tried in the past to use the traditional library structure also for stream files with the concept of ‘shared folders’, but they were difficult to manage and performed poorly. The IFS was then introduced to allow a better coexistence on the AS/400 of the different approaches described above. The IFS supports stream files and subdivides the space among different file systems that use different rules and conventions. For instance:
The data in each file systems can be accessed by using the traditional commands associated with them (e.g. AS/400 CL commands and programs can still be used with the QSYS.LIB file system and commands from a PC can be used to access the / file system).
However IBM has introduced a common API interface that can be used with all file system. Some examples of the new common commands are the following:
One interesting requirement is that all file paths of the new commands must be entered in the Unix style format. This is different from the traditional AS400 library system notation and includes (for original AS400 objects) a suffix that identifies the type of object. For instance the suffix is .LIB for libraries, .FILE for files and .MBR for file members. The original name for a file could be SALESLIB/CUSTFILE, but this must be referred to in the common APIs as qsys.lib/saleslib.lib/custfile.file/custfile.mbr. It should be noticed that applications stored in IFS (e.g. JAVA classes or Lotus Domino) can access data store in a different file system (e.g. database files in QSYS.LIB). It is possible to copy files between file systems, but there are some limitations that must be considered. For instance:
Many utilities have been developed to make the transfers of data between AS/400 database and stream files easier and some of them will be discussed later. |
3. The Portable Application Solution Environment (PASE)PASE is a runtime environment which facilitates porting UNIX applications to the AS/400. It is available as an optional chargeable feature beginning with V4R4 of the OS/400. PASE is not directly connected to the LINUX integration, but we mention it as an example of the trend to increase UNIX support on the AS/400. It should be mentioned however that IBM has recently announced the decision to implement Linux on the AS/400 (which allows a 64-bit scalability) in native mode on a logical partition. A PASE application is executed within an AS/400 job. It can be lauched with CL or ILE C program or using one of the AIX shells provided with PASE. PASE supports only a selected set of AIX APIs and therefore some effort is require to port applications coming from the UNIX world. IBM provides some tools to analyze the API of an application and to determine the portability. Some information can be found at http://www.as400.ibm.com/developer/porting/apitool.html PASE has been annouced by IBM only in January 2000, but already some companied have been able to port UNIX applications. We just mention J.D. Edwards and SPSS. 4. The TCP/IP communicationsThe AS/400 originally supported only the IBM System Network Architecture (SNA) with APPN/APPC communications. Different solutions were developed to allow the coexistence with other approaches such as TCP/IP or Novell IPX. For instance Microsoft developed an SNA gateway that allow translating the original SNA protocols into TCP/IP protocols. IBM decided to open its arms to TCP/IP and adopted TCP/IP as a brother to APPN/APPC after the version 3.1 of the Operating System (OS/400). The main reasons for this development are the following:
Together with TC/IP the AS/400 has developed all the related services such as DNS, FTP, LPR, PPP, SLIP, SMTP, Telnet etc. and clearly this has made the communication with Linux and Unix machines much easier. Data transfers are usually done with FTP, but some data format conversion is often needed as described below:
The above differences suggest that a direct transfer from the AS/400 database files is not normally possible. It is better to use some utility to create an intermediate file (with unpacked numerical fields and explicit decimal points) and then use FTP to transfer the intermediate file. When a logical structure of fields must be identified, it is convenient to use field separators in the stream files. Later you will find a presentation of some utilities that allow to create a file suitable for FTP transfers and that maps fields from a stream file into corresponding fields of an AS/400 database file. |
5. Sharing files with NFSNFS allows access to remote file systems, which appear to applications as if they reside on the local machine. Therefore the need to duplicate and copy files among different machines on the net is eliminated. Sun Microsystems originally developed NFS and released it in 1984. Since then Sun NFS has become a de facto standard within the Unix community. The AS/400 has included NFS support with the V3R7 release of the OS/400 and the implementation is based on Sun’s Version 2, which is one of the most commonly used. NFS uses exporting from the server to make local file systems, directories and objects available to remote systems. The server administrator must decide what local file systems (i.e. subtrees of directories and files) may be exported as well as how they will be exported. The administrator can choose which clients may access the files and how (e.g. read only). The options chosen by the server administrator are typically stored in a file called /etc/exports and then the exports can be activated by using the command exportfs. This can be done at start-up and can be included in the AS/400 start-up file QSTRUP run automatically during IPL. The clients can then add the exported file system to the local machine by using a mount command (normally on an empty directory). The exported file system can later be un-mounted by using the umount command. If the mount command is done on an AS/400 the format is as follows: MOUNT TYPE(*NFS) MFS(‘Sunset:/home/dir1’)
After mounting, client users see the mounted remote file system and files as part of their local name space. The file system appears and functions just as any other local file system would. The flow of requests over the network is usually transparent to the users. The communications with the server are handled by Remote Procedure Call (RPC), which is a high-level stateless network protocol that saves no information from client/server communications. RPC bundles up the arguments intended for a procedure call into a packet of data called a network datagram. The NFS client creates an RPC session with an NFS server by connecting to the proper server for the job and transmitting the datagram to that server. The arguments are then unpacked and decoded on the server. The operation is processed by the server and a return message (should one exist) is sent back to the client. On the client, this reply is transformed into a return value for NFS. The user's application is re-entered as if the process had taken place on a local level. By using NFS the AS/400 can be included as a client or a server in the network and Linux and AS/400 machines can easily share their files. An AS/400 can export any of the following file systems:
An AS/400 can choose its mount points in one of the following file systems:
If an AS/400 stream file is accessed remotely by a Linux machine, it can be edited by using any Unix editor such as vi. The AS/400 library file system QSYS.LIB can be exported, but there are some limits as follows:
|
6. Terminal EmulationBoth the AS/400 and Linux can use Telnet to establish an interactive session. However, when Linux wants to access an AS/400, Telnet is not the best option because the communication is oriented to single characters, whereas theAS/400 original 5250 data stream manages one full screen at a time. Some interesting emulators exists for the Linux market and are described below:
|