June 21 is the most important day on the AS/400 calendar. On June 21, 1988, IBM announced the AS/400?a system designed to lead IBM midrange systems through the end of the century. Seven years later, on June 21, 1995, IBM announced the new AS/400?a RISC-based system that is an AS/500 in all but name. You'll find detailed coverage of this year's hardware announcement in "Hardware Announcements: The Revolution Continues," elsewhere in this issue.
The new hardware requires significant changes in the licensed internal code (the lowest layers of the operating system). All pre-1995 AS/400s (CISC-based AS/400s) can run V3R1 of OS/400; the RISC-based systems require V3R6. On any computer, a new processor requires some rewriting of the operating system. The AS/400's unique architecture reduces, but does not eliminate, this requirement. (For details on the AS/400 architecture and the effect of changing to RISC chips, see the sidebar, "Below OS/400.")
Each new hardware generation of the AS/400 has required a new version of OS/400. What makes V3R6 unique is that all the previous releases of OS/400 were completely backward compatible with hardware (i.e., V3R1 runs on every AS/400 ever built, including the original B-models). Because this isn't true for V3R6, maintenance and performance issues will limit the enhancements to V3R1 over time. Initially, V3R1 and V3R6 will be almost identical, but future compatibility is a question.
The real issue for AS/400 customers is applications compatibility. It's important to distinguish between backward compatibility and forward compatibility. IBM is providing 100 percent forward compatibility for all existing AS/400 applications. For more information, see "Announcement Analysis: Planning for the Upgrade," elsewhere in this issue.
Backward compatibility is more complex. Currently, IBM provides N-1 (previous release) support for save commands and compilers. V3R6 extends this support to N-2 by allowing target releases of *CURRENT (V3R6M0), *PREV (V3R1M0), V3R0M5, or V2R3M0. This allows developers to create applications on a V3R6 AS/400 and support customers who are as much as two full releases back on OS/400 (V2R3M0).
As with all previous release support, the system will verify compatibility for objects saved to a previous release. If an object requires support that only exists in the current release of OS/400, the system issues an error message. Previous release compatibility is also checked on compiles. For example, you cannot compile an ILE RPG program to V2R3M0 because no ILE RPG support is available in that release.
In a move that surprised many industry analysts, this year's announcement includes substantial enhancements to V3R1. Because of the slippage in the delivery schedules for V3R1, there is a backlog of new functions waiting in IBM development labs. In most cases, both V3R1 and V3R6 delivery is planned, and in many cases, V3R1 support will be delivered first?primarily because V3R6 delivery is dependent upon the hardware delivery schedule.
One element that is still unclear is how IBM will deliver the V3R1 enhancements. Indications are that most will be delivered as PTFs, but some changes?such as the new ILE RPG functions?may require a point release (i.e., V3R1M1). The strategy for client products, such as Client Access, calls for a delivery schedule that is independent of OS/400 release dates. How IBM will manage the ordering process for refreshed Client Access components is not yet clear. I'll try to provide some insight into the long-term software picture as I discuss the specific announcements made on June 21, 1995.
The overall themes of the software announced on June 21 are consistent with the direction IBM has set over the past few years. The commitment to client/server technology is stronger than ever. Key announcements address connectivity, open systems standards, database improvements, and new features for the flagship RPG products ILE RPG and VRPG.
Some of the June 21 announcements fulfill previous statements of direction and technology previews?for example, the File Server I/O Processor (FSIOP) with Novell NetWare software support. Others, such as improved SQL support, build the foundation for the AS/400 to participate fully in future computer systems. The traditional AS/400 tools haven't been neglected either. Among the highlights is local variable support for ILE RPG. Don't expect these new features in the short-term. Availability dates range from early fall to a vague "first half of 1996." 1 provides an overview of the software announcements and delivery dates.
Some of the June 21 announcements fulfill previous statements of direction and technology previews?for example, the File Server I/O Processor (FSIOP) with Novell NetWare software support. Others, such as improved SQL support, build the foundation for the AS/400 to participate fully in future computer systems. The traditional AS/400 tools haven't been neglected either. Among the highlights is local variable support for ILE RPG. Don't expect these new features in the short-term. Availability dates range from early fall to a vague "first half of 1996." Figure 1 provides an overview of the software announcements and delivery dates.
Client/Server Sets the Pace
The most important component of IBM's AS/400 strategy is client/server. The AS/400 strategy calls for increased networking capabilities, open systems standards compliance, and specific application services.
The highest profile client/server announcements are three new FSIOP configurations: Novell NetWare 4.1 support, a product preview for a Lotus Notes implementation, and standalone communications adapter support. Like the current FSIOP implementation (see "Is an FSIOP in Your Future?" MC, May 1995), the NetWare and Lotus Notes FSIOP offerings have hardware and software components. The hardware component is the same as the current FSIOP's?an AS/400 card with an onboard 486 processor and memory.
The major difference between these new offerings and the current LANServer/400 FSIOP is the level of support. For example, initial FSIOP Novell NetWare support for V3R1 will be available during the fourth quarter of 1995, but it will not include system management functions, such as automatic creation of NetWare user profiles based on AS/400 user profiles. The additional functions are planned for the first half of 1996. Lotus Notes support will be delivered in two similar stages.
Key components of the Novell NetWare support include file and print serving capability, the ability to use most NetWare Loadable Modules (NLMs), NetWare installation using a client PC, and native IPX support in OS/400. The IPX support is not tied to the FSIOP, so it's possible to route NetWare traffic from one LAN to another using the AS/400 as a conduit.
The option to use the FSIOP as a standalone communications adapter gives customers more flexibility in planning and configuring communications. Customers can choose to run one or two Ethernet or token-ring LANs with an FSIOP. Without purchasing any additional communications adapters, the configuration can be changed. For example, if you are running two token-ring LANs on an FSIOP, a simple configuration change allows you to run a token-ring LAN and an Ethernet LAN on the same FSIOP. (Of course, the attached PCs may require new hardware and software, but at least there's no additional server expense.)
Customers also have the option to run the FSIOP as a standalone communications adapter and to add LANServer/400, NetWare, or Lotus Notes support at a later date. Again, there is a potential cost savings here. If you plan to use one of the FSIOP software options in the future, purchasing an FSIOP as a standalone communications adapter as opposed to buying a LAN adapter may be a more cost-effective solution.
Finally, the FSIOP may simply be less expensive than other communications adapters for some AS/400 configurations. In this case, you should certainly consider the FSIOP. Its performance is at least equivalent to other communications adapter choices; in many cases, performance is slightly better.
Client Access Forges Ahead
A vital component of the software announcement concerns continuing enhancements to the Client Access products?the most visible being a new way of delivering graphical access to OS/400 menus and commands. Using software licensed from Seagull Business Software B.V., makers of GUI/400, IBM is delivering a graphical user interface (GUI) front-end for OS/400 (see 2).
A vital component of the software announcement concerns continuing enhancements to the Client Access products?the most visible being a new way of delivering graphical access to OS/400 menus and commands. Using software licensed from Seagull Business Software B.V., makers of GUI/400, IBM is delivering a graphical user interface (GUI) front-end for OS/400 (see Figure 2).
In a related announcement, IBM shared the results of a pilot project for graphical network operations that is being delivered as an enhancement to SystemView System Manager/400. A graphical front-end is added to the network management support allowing an OS/2 workstation running Client Access to use a graphical interface to manage multiple AS/400s and OS/2 networks.
More important from a developer's perspective are the changes IBM has made to Open Database Connectivity (ODBC) and enhancements to the Client Access Windows client. The ODBC driver supports Level 2 conformance, making it easier to split function between the client and the server. The client management enhancements include the option to install client software from a CD-ROM and native Windows applications for the administration and PC update functions. The administration function was not included in the first release of the Client Access Windows client. (See "IBM's Client Access/400 for Windows 3.1," MC, June 1995.)
IBM announced a variety of other enhancements for the OS/2 32-bit client (initial shipments were planned for June 1995) and the Windows client. Here are a few that I found interesting.
* A new user interface for file transfers and support for batch and timed file transfers in the Windows client.
* X.3 Packet Assembler Disassembler (PAD) dial-up support from the Windows client to the AS/400 using an X.25 network.
* The ability to view OS/400 spool files from the OS/2 client as part of the Network Print function.
Host Print Transform is not directly part of Client Access, but it is an important part of IBM's client/server strategy. The Host Print Transform support announced on June 21 translates a host or PC print stream to another printer format. For example, you can create a document using Advanced Function Printing on the AS/400 and send it to an HP LaserJet printer attached to a PC LAN. Provided that the target printer has the necessary capabilities, Host Print Transform handles the data translation.
New Partners Offer Options
Delivering even more fuel to the client/server battle, IBM announced new entries in the Client Series: Guidelines from JBA International, Inc.; Obsydian from Synon Corporation; LANSA/CS400 and LANSA/Server from Aspect Computing; SequeLink from TechGnosis; and IBM's own VisualGen. Client Series product recommendations are designed to give AS/400 customers a guideline concerning client/server tools. IBM isn't necessarily saying that a particular product is the best in its category; instead, IBM tries to find at least one AS/400-compatible product in each product niche. The Client Series can provide a good starting point for customers who are exploring client/server options.
Connectivity is Critical
Client/server is just one component of IBM's overall networking strategy. Some of the most important announcements address increasing the AS/400's ability to connect to other platforms and its ability to handle data from multiple systems. Building on last year's UNIX compatibility announcements, IBM announced support for 140 additional application program interfaces (APIs) in the Spec 1170 standard. (Spec 1170 is now referred to as Single UNIX Specification APIs.) The company also released a list of about 40 vendors (primarily in PC and UNIX markets) who have ported their software to the AS/400 or are working on a port. Major players like Oracle and PowerSoft are active in this program.
The Oracle project is interesting; Oracle is working with IBM to allow Oracle applications to access DB2/400 data and AS/400 applications to access Oracle data. Planned availability dates are August 1995 for the Oracle-to-DB2/400 product and October 1995 for the DB2/400-to-Oracle product.
IBM has crystallized its plans for Asynchronous Transfer Mode (ATM) with a statement of direction. AS/400 customers can expect ATM support to be announced within the next two years. ATM enables very high performance communications between systems (up to 155 million bits per second) and is a widely accepted industry standard. The commitment to provide ATM support on the AS/400 should be welcomed by network managers who are constrained by the transfer rates currently available.
Finally, on the communications front, IBM just couldn't resist the temptation to jump on the Internet bandwagon. As you may know, IBM has had a World Wide Web home page available for AS/400 information since last September. What you may not know is that the home page is supported by an AS/400 in Rochester, Minnesota. IBM plans to expand this technology and make it available to other AS/400 sites interested in establishing an Internet presence. OS/400 enhancements planned for 1996 include allowing any AS/400 to function as a World Wide Web server, allowing AS/400-developed applications to be accessed from a Web browser, and ensuring security while allowing dial-in access from Anonymous FTP users. These functions will be part of OS/400, not a separate licensed program product.
Database Reaches Out
Database enhancements are as critical as communications enhancements when it comes to multiplatform networks. V3R1 brought the OS/400 database to the forefront?gave it a name, increased SQL standards compliance and performance, and added substantial new functions. This year's announcements have a narrower audience, but they continue to prove that DB2/400 is an important player in the database arena.
Not surprisingly, SQL is at the heart of the database announcements. SQL is the database language for the next decade; it's as close to a true standard as any you'll find in this industry. Two new functions are added to the existing SQL support?outer join and alter table. (Outer join support is already available natively in OS/400, but alter table is completely new for both SQL and the native database with this announcement.)
The SQL Client Integration API provides a migration path for applications designed to access DB2/400 using SQL. Using this API, these applications can access data stored in other databases, such as Oracle or Sybase. The API also provides an interface that database vendors can use to write DB2/400 drivers. This type of driver allows their database functions to retrieve information from DB2/400.
Support for X/Open Call Level Interface allows any standard SQL application to access DB2/400 without using the SQL precompilers. Although performance is better if a precompiler is used, this new support improves DB2/400's ability to interact with many applications.
In addition to the SQL products that inherently improve the AS/400's ability to participate in a distributed network, IBM announced transparent remote access to data areas and data queues. This access makes it easier to write applications that use data from more than one AS/400.
Two product previews introduce new functions designed to improve query processing; one also addresses the issue of data that is stored on multiple AS/400s. Both of these functions improve performance by distributing the query function to multiple processors.
Symetric Multiprocessing (SMP) takes advantage of the multiple processors that exist on even a single AS/400 to process database queries more efficiently. Each query is broken down into smaller units and processed independently; the results are recombined transparently for the user.
Loosely-coupled, shared-nothing parallel database promises support similar to SMP across multiple physical systems. Loosely-coupled, shared-nothing parallel database partitions a file so that records are distributed to many systems. When a query runs in this environment, OS/400 will locate a particular record, collate query results across systems, and send retry or error messages if a communications failure occurs. Again, the entire function is transparent to the user, and the elapsed time to process the query may be substantially reduced. SMP and loosely-coupled, shared-nothing parallel database are completely compatible. In theory at least, a query could take advantage of both.
Take a RISC
Some database enhancements are being implemented only in V3R6 because they require the performance of the RISC hardware or the specific capabilities of the new Systems Licensed Internal Code (SLIC). The V3R6 support includes Unicode, modifications to IFS, and a new licensed program product?ObjectConnect.
Unicode standardizes the internal storage of single- and double-byte character sets. For example, Unicode makes it possible to create a multilingual database that combines double-byte and single-byte languages (e.g., Japanese and English). Using Unicode, IBM can enable new functions for all national languages more easily.
Improvements to the Integrated File System (IFS) make it possible to access AS/400 data on multiple systems using IFS commands and provide OS/400 support for optical devices, such as CD-ROM drives. The ObjectConnect for OS/400-licensed programs makes it easier to save and restore AS/400 objects across a network without using tape media.
All of these database enhancements are further proof of two important truths in the June 21 announcement: IBM is committed to making the AS/400 an important player in distributed, multiplatform networks, and the new strengths of the AS/400 are built upon the traditional strengths of the AS/400.
IBM has no plans to replace the highly successful, integrated components of OS/400 with standalone components from multiple vendors. As a result, enhancements to the database, OS/400, and application development tools will continue. This is great news for those AS/400 shops that do not have distributed processing requirements, but do have continually evolving MIS requirements.
RPG Keeps Rolling Along
The ILE RPG enhancements are encouraging for those with immediate requirements for more AS/400 functions. I talked with RPG developers in Toronto who indicated that the new software will be delivered in late 1995 or early 1996. For an overview of the language and application development delivery dates, see 3 (see page 49).
The ILE RPG enhancements are encouraging for those with immediate requirements for more AS/400 functions. I talked with RPG developers in Toronto who indicated that the new software will be delivered in late 1995 or early 1996. For an overview of the language and application development delivery dates, see Figure 3 (see page 49).
Some of the most important new functions include multiple procedures within an ILE RPG module, an option to replace an existing prefix using the PREFIX keyword, support for the CYMD date format, better access to system APIs, and integer data types (signed and unsigned).
Procedure support gives RPG programmers the ability to write standalone functions without creating separate modules. Procedures as implemented in ILE RPG allow for local variables, returned values, automatic storage instead of static storage, and a free-form CALLP op code that includes a list of fields instead of the traditional PLIST. Procedures also make it possible to write recursive code and code with multiple entry points in RPG. These new features provide better support for information hiding and encapsulation. Obviously, IBM recognizes that RPG will continue to be a major development tool on the AS/400 and has made the commitment to continue to improve ILE RPG.
IBM faces a challenge with such major changes to ILE RPG?determining the best way to maintain prior release support in the compiler. OS/400 plans do not currently call for an additional release for CISC-based AS/400s. However, according to our sources, the changes in ILE RPG are major enough that prior release support makes sense. I expect that at least some enhancements to licensed program products, such as ILE RPG, will be delivered at a V3R1M1-level early in 1996.
For RPG programmers who've started the journey to client/server, IBM announces significant enhancements for VRPG, IBM's visual client/server development environment for RPG. (See "IBM's VRPG Hits the Street," MC, April 1995.) As promised, IBM delivers Windows run-time support for VRPG, allowing developers to deploy VRPG applications on virtually any PC. The Windows support is backward compatible so that applications developed with V3R1 VRPG can be rebuilt (recompiled) to run under Windows. Discussions are continuing about a possible Windows development version of VRPG.
Other modifications are designed to improve performance, to make VRPG easier to use and install, and to improve the database interfaces. In particular, VRPG can access local (PC) databases using embedded SQL or RPG op codes like READ and WRITE. Midrange Computing is working closely with IBM to bring you more detailed coverage of the ILE RPG and VRPG announcements.
There are some changes to other languages?most significantly, ILE C. In V3R6, ILE C supports System Object Model (SOM) and Distributed System Object Model (DSOM), which moves it closer to the object-oriented (OO) development tools that are beginning to show up in the AS/400 environment. ILE C performance on the RISC hardware should be significantly better than V3R1 performance. Some additional ILE C functions support UNIX-like development. These functions support TCP/IP sockets and the ability to address the IFS root file system directly. (See "V3R1 Announcement Follow-Up: The Integrated File System," MC, July 1994.)
Pascal, BASIC, and PL/1 will not be sold as licensed program products. All three compilers are available as PRPQs to allow customers to maintain existing applications. Existing program objects will continue to run and be supported. Reclassifying low usage licensed programs as PRPQs reduces support costs that affect all AS/400 customers. The FORTRAN and RM/COBOL compilers are being completely withdrawn because very few customers are using these products.
The Object of the Exercise
Beyond client/server, the next frontier is object-oriented programming (OOP). The announcement addresses OO development with VisualAge C++ for AS/400. VisualAge C++ is a true OO design tool with a strong C++ compiler. It may have important repercussions for AS/400 tool development because most tool vendors use C or C++. By providing high quality C compilers for the AS/400, IBM increases the opportunity for vendors to port applications to the AS/400 from other platforms. It also opens up opportunities for AS/400 developers to port their own products from the AS/400 to other platforms.
VisualAge C++ for AS/400 can be used to create applications that run on OS/2, OS/400, or both. Both platforms include a consistent set of class libraries (OO building blocks). Like other visual development tools, VisualAge has PC and host components. The AS/400 objects are consistent with ILE and can be bound into ILE applications.
For more traditional development, IBM announced some minor enhancements for application development tools and several new packaging options to make client/server development tools more affordable. Although prices were not available at press time, I expect IBM to price these toolsets aggressively.
The IBM DeveloperPak for OS/400 gives RPG developers a full set of host-based and client/server development tools. It includes ILE RPG, Application Development Toolset for OS/400 (ADTS), Application Development Manager (ADM/400), Application Dictionary Services (ADS/400), and Application Development Toolset Client/Server for OS/400 (ADTS CS)?CODE/400 and VRPG.
Enhancements to the application development tools include CODE/400 support for COBOL, impact analysis for ILE objects, and a variety of ease-of-use improvements in ADTS CS. ADM/400 supports VRPG and S/36 parts, and user libraries. New ADM/400 facilities make it possible to distribute applications to multiple AS/400s.
It's always difficult to choose which elements of a major announcement to include in an article because it's impossible to include everything. Here are a few final items that caught my eye.
* A new licensed program product?Job Scheduler for OS/400?provides some functions that are not available in the built-in job scheduling support supplied with OS/400. (See "Job Scheduling: Compliments of IBM!" MC, December 1992.) Perhaps the most critical of these is support for job scheduling across an SNA network. The new product is available immediately for V3R1, and by PRPQ for V2R2 and V2R3. V3R6 availability is planned for September 1995.
* Effective with V3R6, IBM has withdrawn the TAA Tools from the QUSRTOOL library. The TAA tools functions formerly included in QUSRTOOL are now available from Jim Sloan, Inc. (see From the Toolbox elsewhere in this issue).
No Crystal Ball Required
Not surprisingly, this year's software announcement is far smaller than last year's V3R1 announcement. I think of this more as a continuation than a new announcement. Still, I'm impressed with the amount of new functions that IBM plans to deliver over the next 12 months.
My only major complaint is the lack of specific general availability dates. There are lots of mechanisms available to preview software (e.g., technology previews, product previews, and statements of directions). I think the AS/400 Division should wait to announce until it can specify a delivery date and adhere to it. In the past, a firm commitment to deliver a specific function on a specific date distinguished IBM's AS/400 software offerings from their competitor's offerings.
In other respects, the direction is clear and the specifics are encouraging, even if they don't fulfill everyone's dreams. I like the concentration on distributed systems in general with client/server as a part of the overall picture. This is an arena where the AS/400 can shine. The system management, security, and ease-of-use that are integral parts of OS/400 seem custom-built to handle multiple systems?whether they are PCs, AS/400s, or anything else.
I particularly like the continuing enhancements to RPG. I'm all for OO development; I expect that it will be the future of programming. But lots of people have problems to solve today. The continuing enhancements to RPG acknowledge these requirements, while tools like VisualAge C++ for OS/400 pave the way for the future. Some may consider it a mixed message, but I'd call this dual strategy a clear direction for the AS/400.
The new RISC-based hardware sets the stage for the AS/400 to continue its long and successful career. The continued software enhancements promise a future that is dynamic and exciting. I just can't wait to see what IBM has in store for the AS/400 community on June 21, 2002!
Sharon Hoffman is the editor of Midrange Computing.
One of the strengths of the AS/400 architecture is that applications programmers do not need to know anything about the underlying hardware. In fact, most of the programmers writing OS/400 are insulated from the hardware because of the system's unique architecture. This allows IBM to make changes as new technology becomes available, changes that would require a complete operating system rewrite on most computers. This design, known as advanced application architecture, is the brainchild of Dr. Frank Soltis.
At the press briefing prior to the June 21 announcement, Soltis explained how advanced application architecture insulates programmers from the hardware. With that framework established, he discussed the changes that allow OS/400 to take full advantage of the 64-bit addressing the RISC chips use in the new generation of hardware.
A1 illustrates the AS/400 (and, incidentally, the S/38) architecture for all CISC-based systems. The separation of OS/400 from the hardware is accomplished by the machine interface (MI). Approximately 90-95 percent of OS/400 resides above the MI. As a result, OS/400 is not affected by hardware changes. IBM has changed the AS/400's hardware several times over the life of the system. The difference between those changes and the CISC to RISC change is a matter of degree.
Figure A1 illustrates the AS/400 (and, incidentally, the S/38) architecture for all CISC-based systems. The separation of OS/400 from the hardware is accomplished by the machine interface (MI). Approximately 90-95 percent of OS/400 resides above the MI. As a result, OS/400 is not affected by hardware changes. IBM has changed the AS/400's hardware several times over the life of the system. The difference between those changes and the CISC to RISC change is a matter of degree.
IBM made a conscious decision to rewrite the code below the MI to take advantage of OO techniques. Among other benefits, the new system licensed internal code (SLIC) improves performance for all ILE languages by offering a more direct path to the hardware instructions. It also handles multiple instruction streams concurrently and expands the limits (e.g., maximum field size). A2 shows the architecture used in RISC-based AS/400s.
IBM made a conscious decision to rewrite the code below the MI to take advantage of OO techniques. Among other benefits, the new system licensed internal code (SLIC) improves performance for all ILE languages by offering a more direct path to the hardware instructions. It also handles multiple instruction streams concurrently and expands the limits (e.g., maximum field size). Figure A2 shows the architecture used in RISC-based AS/400s.
On CISC machines, translating instructions into machine language is a two-step process. Instructions are first translated to an instruction set based on 370 assembler language. There are two translators on CISC systems?old program model (OPM) programs use a different translator than the ILE programs. In both cases, the result is assembler language at the internal microprocessor interface (IMPI). (See A1.) The hardware-specific portion of the operating system is the horizontal licensed internal code (HLIC), which interprets each assembler instruction using many hardware instructions.
On CISC machines, translating instructions into machine language is a two-step process. Instructions are first translated to an instruction set based on 370 assembler language. There are two translators on CISC systems?old program model (OPM) programs use a different translator than the ILE programs. In both cases, the result is assembler language at the internal microprocessor interface (IMPI). (See Figure A1.) The hardware-specific portion of the operating system is the horizontal licensed internal code (HLIC), which interprets each assembler instruction using many hardware instructions.
RISC-based AS/400s use a single translator based on the ILE translator, which generates hardware-specific instructions for the PowerPC chip. The version of the PowerPC used in AS/400s supports 236 machine instructions?the 207 instructions required for PowerPC compatibility, four of the optional PowerPC instructions, and 25 AS/400-specific instructions.
In both CISC- and RISC-based AS/400s, instructions at the MI layer are defined as a 128-bit pointer made up of four parts. The construction of this pointer is the key to full 64-bit processing.
* The header is 32 bits long. Because the system has evolved from the original S/38 design, much of this space is unused.
* A used section of 32 blank bits follows the header.
* The address is (and always has been) stored as 64 bits.
In pre-RISC versions of OS/400, the Vertical License Internal Code (VLIC) above IMPI converts the 64-bit address to a 48-bit address. Obviously, the ability to go beyond 64 bits is available in the OS/400 pointer design, but addresses of 96 bits or greater would require every program to be recompiled.
The 48-bit to 64-bit retranslation on the new RISC-based models is possible because OS/400 actually stores two versions of every program--the MI (64-bit) version and the IMPI (48-bit) version--unless observability has been removed. When you convert from CISC to RISC (see "Announcement Analysis: Planning for the Upgrade," elsewhere this issue) the retranslation process uses the MI version of the program and the new SLIC translator to create PowerPC machine language.
Because of the low-level rewrite, concern about the compatibility between older versions of OS/400 and V3R6 may be valid. Asked about this issue, Soltis pointed out that only slightly more than 1 percent of the MI code was affected by the SLIC rewrite. This low impact increases the possibility that IBM will continue to add new functions to both V3R1 and V3R6?at least for the immediate future.
Software Announcements: Evolutionary Growth
Figure 1: Overview of Software Announcement Delivery Dates
V3R1 V3R6 Graphical Access for June 1995 Fourth quarter 1995 OS/400 (Client Access) OptiConnect (OS/400) Fourth quarter 1995 Fourth quarter 1995 Systems Management Fourth quarter 1995 Fourth quarter 1995 Open Print Support Fourth quarter 1995 Fourth quarter 1995 World Wide Web Service Offering Fourth quarter 1995 Fourth quarter 1995 Novell NetWare Integration First half 1996 First half 1996 World Wide Web Server First half 1996 First half 1996 WebConnection for OS/400 First half 1996 First half 1996 NLS Enhancements (UNICODE) Not applicable First half 1996 SOM/DSOM Not applicable First half 1996
Software Announcements: Evolutionary Growth
Figure 2: Example Graphical Interface for OS/400
Software Announcements: Evolutionary Growth
Figure 3: Overview of Language and Application Delivery DatesV3R1 V3R6 ILE RPG for OS/400 Now available September 1995 ILE COBOL for OS/400 Now available September 1995 Application Development Now available September 1995 ToolSet for OS/400 DeveloperPak for OS/400 June 1995 Fourth quarter 1995 Application Development ToolSet Now available Fourth quarter 1995 Client/Server (ADTS CS) for OS/400 Additional enhancements for First half 1996 First half 1996 ILE RPG and ILE COBOL Additional enhancements for First half 1996 First half 1996 ADTS CS/400 ILE C for OS/400 Now available September 1995 Visual Age C++ for Fourth quarter 1995 Fourth quarter 1995 OS/400