Software companies and end users
developed on the IBM AS 400
platform because it offered a number of advantages – database capabilities at
the machine level, stability, wide acceptance and excellent support from
IBM. Within the business community. As
the industry matured, the marketplace has sought more open growth platforms
such as Windows or Windows. Starting
over every time a new business requirement arises is neither practical nor
justifiable. An approach is needed which
enables applications to adapt to rapid business and technology changes. Many
companies wish to operate their AS 400 applications under Windows
instead of i OS. They wish to run the
software in a virtualized environment like VMWare, they wish to use industry
standard blades instead of proprietary System i or IBM P series hardware
running i OS and DB2/400. They would
like to write to an industry standard database like MS SQL and they would like
to provide a Cloud-based, graphical UI that is intuitive and not
menu-driven. This paper will explain how
these objectives can be achieved.
This white paper will discuss how to
migrate RPG or COBOL code, CL and DDS to Windows and to execute on MS SQL. AS/400
applications were generally written in RPG/400 and were subsequently developed in
RPG ILE. The usual compiled environment of
AS/400 applications also include CL and DDS.
In order to accomplish the goals
discussed earlier in this paper, the code must be recompiled. In this instance, we are using the compilers
available from Infinite Corporation.
Infinite has developed a family of products named Infinite i. As part of this product family, there are
several compilers that will provide for the recompilation of RPG.400, RPG ILE, COBOL/400
and COBOL ILE, CL and DDS source code.
Once recompiled, this code will be executed as native object code for Windows
Enterprise Server 2008 r2. This is a
This approach uses what you already
have; proven AS 400 code and resources, and allows you to execute functionally
rich applications on a lower-cost 21st
Using infinite i, end-users can
combine all the ‘competitive edge’ benefits of Windows with the power and
stability of their RPG or COBOL applications. Since the underlying code is the original, the
skills required to maintain the core logic remain the same. In fact, this process maintains source code
integrity and simply allows it to be distributed on open platforms.
For AS/400 ISV’s
infinite i provides a way to access thousands of new sales prospects, without
taking years to rewrite applications.
ISV’s can maintain the same source code and continue development on the
IBM i OS (if they desire) and can deploy those programs on the i OS or Windows
or even Windows via Infinite i.
To illustrate what infinite i can do
we will look at how infinite i deals with re-hosting an AS/400 application to
run on Windows.
Presented with the challenge of running an AS/400 application on Windows,
the problem that first comes to mind is that of source language; how to find a way
of compiling thousands of programs written in proprietary CL, RPG or COBOL on Windows? But, in fact, the language issues are only
the small tip of a large iceberg.
An AS/400 comes with a standard, mature and sophisticated
environment designed to meet the needs of commercial applications. i OS (OS/400) provides the fundamental
services required by an application-service such as print spooling, message
handling, batch job process and, of course, the database.
In contrast, the services provided by Windows are less complete
and less rich and where an adequate service is provided, it is invariably different to the service on an AS/400 in
some significant respect.
AS/400 applications depend on these services as much, if not more
than, the CL, RPG and COBOL languages that are used to define the application
algorithms. So, the most vital
components of infinite i are not the language compilers but the Infinite
Deployment Environment. This environment
contains internal DLL’s holding a legion of function that map OS/400 services
on to underlying Windows services and so provide an OS/400-like ‘shell’, in
which application programs can execute.
In this paper we examine the Big Four Services:
- Job management
- Database access
- User interface
And other service functions, to see how
infinite i enhances standard Windows architecture to implement OS/400
We will then look at the process by which
an iSeries application is built on Windows.
When an application program is compiled, Infinite
i first generates intermediate C code (analogous to the Machine Code generated
by the OPM and ILE compilers) and then uses the Microsoft Visual C++ compiler
and linker to build native Windows DLLs, LIBs and EXEs. The characteristics of
these components are similar to those of a program object on the AS/400. The compiled components can be dynamically
loaded into and unloaded from a running job.
They can call other modules and return control without being unloaded
from the calling job (so enabling the RPG RETURN functionality).
In addition to compiling application
programs into Windows Standard DLLs, LIB and EXEs, Infinite i implements most
of the standard OS/400 programs as DLLs with the same characteristics. An
application running on Infinite i will find job and program models very similar
to those on the AS/400. The job management service functions provide the glue
to link the programs together at runtime and implements job attributes such as
the library list, program stack and job message queue that provides the
backbone of any application job.
Infinite i replicates the DB2/400 database
within the suite of programs, providing a complete replacement of the IAS/400. The internal database provides all the
routine functionality (physicals, simple and join logicals, select/omit, triggers,
etc) as well as functionality that is specific to DB2/400 such as multi-member
files, multi-format logicals, etc.
Alternatively, either Oracle or MS SQL Server can be designated as the repository
for all the application's data files. In this case, Infinite i creates the
database schemas (for example, mapping physical files to tables, logical files
to views) and, at runtime, translates the application database calls (READ,
READE, SETLL etc.) to the appropriate SQL statements. This translation takes
place within the database service function so the application programs remain
independent of the implementation.
Infinite i replicates the
traditional AS/400 print service functions that provide a high level of support
for printer file DDS, together
with an implementation of the OS/400 print spooling system (including out
queues, device descriptions and writer jobs) that integrates naturally with the
target operating system’s Print Manager. This allows for the same level of
application and operator control of print activity, using the standard commands
(e.g. RLSSPLF) and user interfaces (e.g. WRKSPLF). Alternatively a user can choose to have output
for designated printers released immediately to the Print Manager so that print
jobs can be managed using standard interfaces.
4. Other Services
OS/400 object management system provides a variety of object types, most of
which are listed in Figure 1. The Infinite
i service functions implement all the object types that are in common use by
applications. In each case, the object
is implemented using one or more of the target operating system files and
wrapper functions to provide controlled access to the object and to implement
the standard OS/400 commands and APIs.
THE REHOSTING SUITE
1. Save Application On AS/400
Migrating an application to Infinite i is
a straightforward procedure. The application needs to be saved on the AS/400
using SAVLIB to save all the application components (source and object) to save
files. The save files are then
transferred to Infinite i.
2. Load Application On Infinite i
Infinite i provides the command RSTAPP -
Restore Application, to load the application components from the save files.
all the source files and members
catalog information in the save files to generate instructions describing how
the source members need to be compiled
restores other object types that are not created from source (e.g. job
descriptions, message files)
3. Build Application
The Infinite i command RUNBIF - Run Build
Instructions, executes the build instructions that were generated by the load
phase, by making calls to the appropriate 'create' commands (CRTPF, CRTRPGPGM,
CRTBNDRPG etc). When this command has completed, all the source members should
have been compiled and the application will be ready for testing.
4. Application Changes
Infinite i provides development tools to
allow changes to be made, built and tested.
The SEU, PDM and the
language compilers implement full source validation – they don't assume that
they will be compiling valid source programs. Alternatively, if the application
source is still hosted on an AS/400, changes can be made there and selectively
transferred to and rebuilt on Infinite i using the procedure described above.
Appendix: Summary of ISERIES Features