Can Your UNIX Apps Keep Up the PASE?

  • Smaller Small Medium Big Bigger
  • Default Helvetica Segoe Georgia Times

With IBM’s recent announcement of AS/400 Portable Application Solutions Environment (PASE), which is the marketing name for the actual name Private Address Space Environment, many UNIX users and vendors are wondering whether or not their applications will run on the AS/400. That’s a good question. The short answer is probably, but, then again, maybe not. Don’t you just love a wishy-washy answer like that?

Unfortunately, that’s about as direct an answer as you can get until you begin analyzing each and every program you want to run in AS/400 PASE. That’s because moving your UNIX applications to the AS/400 is a bit more complex than just saving them on your UNIX system and restoring them to your AS/400. While this article cannot provide a detailed, step-by-step process for porting your individual UNIX applications to PASE, it does provide information you need to get started in determining whether or not your UNIX applications will work on the AS/400.

What It Is

PASE is a UNIX runtime environment for the AS/400. Take note of the word runtime. PASE is not a UNIX operating system for the AS/400. What this means is that, with anywhere from very little work to a whole lot of work (depending on the requirements of specific applications), you can port existing UNIX-compiled binary objects to the AS/400 and run them on the PowerPC processor found there. These objects can integrate with the AS/400’s database and can take advantage of the AS/400’s Backup, Save, Restore, and Security functionality as well. What you cannot do is create and compile UNIX code into executable objects on the AS/400. For new UNIX applications or for modifications to existing UNIX applications, you need a UNIX environment running on another machine, such as a Sun Solaris.

PASE is a reality on the AS/400 because it takes advantage of the AS/400’s ability to switch between the operating system runtime modes Tags Active and Tags Inactive. Tags Active means that the AS/400 executes 64-bit applications such as RPG IV programs you develop every day. Tags Inactive means that the AS/400 executes 64- or 32-bit AIX applications. PASE uses the Tags Inactive runtime mode to run UNIX applications.

One of the nice things about applications ported to PASE is that they can be fully integrated with the AS/400’s ILE environment. This is accomplished by using the same Call Level Interface (CLI) library for DB2/400 with PASE as the one supported for AS/400

ILE. This means that your RPG IV or COBOL programs can call and trade data with UNIX applications running in PASE. Keep in mind, though, that data sent from and returned to the UNIX applications is first converted to ASCII from EBCDIC. This can quickly lead to performance issues if your UNIX applications need to do a lot of data exchanges with ILE applications.

Analyzing Your UNIX Applications

Before you can port your UNIX applications to the AS/400, you first need to know what, if anything, needs to be changed to make them work in PASE. PASE does not support all AIX runtime libraries, and, for those that it does support, it may implement them in a manner slightly different from what your UNIX applications may be expecting.

IBM provides a tool called the API Analysis Tool that you can use to evaluate the suitability of your UNIX applications for running on the AS/400. This tool, available from IBM’s Web site at www.as400., consists of two parts: a front-end and a back-end. The front-end portion is a UNIX script that you run on your UNIX machine to scan existing UNIX applications’ symbol tables using the UNIX dump command. The API Analysis Tool looks for interfaces (function calls) used by the applications. When you run the script, it produces a report that you then email to IBM for analysis (the back-end portion of the tool). Because you have to do this for every UNIX application you are considering porting to the AS/400, the idea of porting your entire UNIX suite of applications is somewhat less than appealing.

What’s Supported

The table in Figure 1 is a subset of a table provided by IBM on its UNIX porting Web site. This table shows the supported UNIX standards as well as the OS/400 version and release levels they are supported on. The following is a summary of some of these functions:

• POSIX file I/O byte stream support of the AS/400 Integrated File System (AS/400 IFS)

• Process management—used for parent/child relationships for starting and stopping jobs

• Semaphores—allow synchronization to control access to shared resources

• Shared memory—allows parts of applications to share memory space

• Network File System (NFS)—transparently shares file data in UNIX-based client/server applications (The AS/400 can be either an NFS server or an NFS client.)

• Transport Independent Remote Procedure Call (TI-RPC)—separates and distributes client applications from server mechanisms

• Qshell interpreter—allows command-line access to UNIX commands

• Environment variables—set environment parameters outside the scope of executing applications

For a complete list of supported UNIX functions, check out the IBM Porting Options and Sources Web page, the address for which can be found in the References and Related Materials section of this article.

As you can see from this short list, there are myriad considerations to be reckoned with before you can even begin porting your UNIX applications to the AS/400 and PASE. For each item listed above, there is a host of other questions that you must consider before deciding whether or not your UNIX applications are portable.

Take environment variables, for example. Most UNIX applications use CISC-type instructions, but most AS/400 applications use RISC instructions. If your UNIX applications are going to use environment variables on a RISC-based AS/400, you must remap those variables to use RISC. To do this, you merely have to add the extra, appropriate #include line to your UNIX code. Failure to do so, however, will cause your UNIX applications to fail when they attempt to execute in PASE.

There are a ton of these “little” modifications and fixes that you need to evaluate and implement before your UNIX applications will run without problems in PASE. Keep this in mind when deciding whether or not you want to get into the application porting business.

Other Considerations

Beyond evaluating the specific function calls of your UNIX apps, there are other areas you need to consider before porting your applications:

• What AS/400 hardware will support your applications? In other words, if you port your UNIX software to the AS/400, which AS/400 platform can you market it to? PASE runs only on e-machines, so you can’t market your applications to users of older AS/400 systems.

• Which version of AIX were your UNIX applications compiled with? Depending on the version used, you may need to recompile your applications prior to going to a specific OS/400 version and release. As an example, if your UNIX applications were created with or run on AIX 4.3.x and your target OS/400 version and release is V4R4, you probably need to recompile the code before you can run it in PASE. On the other hand, if your UNIX applications were created with or run on AIX 4.2.1, no recompilation is required. It gets pretty hairy real fast.

• If you port your UNIX applications to PASE on the AS/400 and then upgrade the AS/400’s hardware architecture (not just a processor upgrade), those applications need to be recompiled on a UNIX platform and remigrated to the AS/400 after the upgrade.

• There are many, many other issues to consider before you can even begin to evaluate whether or not your UNIX applications would be a good fit for PASE. For example, do your UNIX applications depend on the setguid and setgid commands? If they do, you need to modify them to use the “swap” function in OS/400 V4R4.

• Were your applications coded in C? If so, you need to recompile them using AIX compilers (xlc or gnu).

• Do your UNIX applications use embedded SQL? If so, you need to extract the database logic and build stored procedures that you will then call from your PASE-enabled applications.

I could go on and on, but there’s just not enough room in any one article to cover every possibility. Each UNIX application you want to port to PASE requires extensive analysis both by you and by IBM before you can feel comfortable that everything will work the way you think it should. Again, make sure you visit IBM’s Porting Options and Sources Web page as well as the AS/400 PASE Web site for a complete listing of all the porting considerations.

Opportunity Abounds

PASE offers a lot of promise to traditional UNIX applications and software providers. It opens up a whole new marketing world to them and makes the concept of the AS/400 a lot more attractive to shops looking to consolidate systems. PASE could be just the shot in the arm the AS/400 needs to appeal to the UNIX community and make converts out of them as it has out of the rest of us. However, porting UNIX applications to PASE is not yet a straightforward process. But those vendors and programmers willing to invest the time and effort to make it a reality are going to find that the pot of gold at the end of the rainbow is just sitting there, waiting for them to pick it up.

References and Related Materials

• AS/400 PASE Web page:
• IBM Porting Options and Sources Web page:

UNIX Function V3R1 V3R2 V3R6 V3R7 V4R1 V4R2 V4R3 V4R4

BSD Sockets OS OS OS OS OS OS OS OS POSIX File I/O OS OS OS OS OS OS OS OS CPA Threads CPA CPA CPA CPA CPA CPA CPA CPA Environment Variables CPA OS OS OS OS OS OS OS Async Signals OS OS OS OS OS OS OS Process Management CPA OS OS OS OS OS OS Semaphores CPAOS OS OS OS OS OS OS Shared Memory CPA OS OS OS OS OS OS OS Message Queues OS OS OS OS OS OS OS Message Catalogs OS OS OS OS OS NFS OS OS OS OS OS TI-RPC OS OS OS Kernel Threads OS OS OS UNIX-style Shell OS OS OS

OS = Operating System CPA = Common Programming APIs Toolkit

Can_Your_UNIX_Apps_Keep_Up_the_PASE-04-00.png 509x304

Figure 1: PASE supports these UNIX functions on the AS/400.