Trends > What's New

Preparing for V6R1

What to expect during your conversion

Upgrading to IBM* i5/OS* V6R1 requires a program conversion. The System i* community has experienced program conversions before, for example when switching from the System/38* to AS/400* platform in 1988 and moving from the 48-bit address space to the 64-bit address space in 1995. This was the CISC to RISC conversion where the instruction set was changed from complex instruction set computing to reduced instruction set computing.

The V6R1 program conversion is similar in some ways to the CISC to RISC conversion, mainly in that as long as the program has observability, the conversion can be quite seamless. Two main differences for the V6R1 program conversion are that it’ll be less time-consuming and that the conversion doesn’t require a hardware change. V6R1 will run on both existing hardware and the new POWER6* hardware.

Why the Conversion?

The main reasons for the conversion are to improve the operating system’s integrity, performance and functionality.

Integrity—The conversion will prevent any system state programs that aren’t part of i5/OS from loading. Part of the conversion process involves removing any altered programs found during the upgrade process. Starting in V6R1, all programs allowed to run in system state must be part of i5/OS. System state, a higher-privilege running environment, is now reserved only for i5/OS programs. This change will prevent any non-i5/OS programs from interacting incorrectly with the operating system, keeping i5/OS more stable and secure. Programs also won’t run without creation data. The creation data signifies that the program has observability, so any nonobservable programs won’t execute on a system running V6R1.

Performance—Several performance improvements are associated with the program conversion in V6R1. Memory will be handled more efficiently, speeding program execution. Program activation, procedure calls and pointer use will benefit from performance improvements. The V6R1 conversion opens the door to using teraspace for memory allocations, which offers a performance boost for your applications.

Performance improvements also come in the areas of two new create-time options and Adaptive Code Generation (ACG). When creating service programs or programs, you can use the Argument Optimization (ARGOPT) parameter to optimize calls between procedures in the program or service program. This compile option applies to programs created for V6R1 and can provide up to a 20-percent performance improvement in call-intensive applications, according to IBM.

The second compile option relates to the Bind Service Program (BNDSRVPGM) parameter. In V6R1, you’ll have the option to defer service program activation, which is helpful if you have a program that activates several service programs. By default, all of the service programs are activated when the program is invoked. With this new compile option, you can specify which service programs are activated or deferred. By deferring activation of rarely used service programs, you can reduce startup times. Enable this option by specifying *DEFER for the BNDSRVPGM parameter when creating service programs.

ACG lets programs take advantage of the new POWER6 hardware. When programs are compiled on V6R1 running on the new hardware, the program can take advantage of new processor features. In previous releases, some hardware features couldn’t be leveraged until several releases later, to provide program compatibility. With ACG and V6R1, if a program is compiled to leverage V6R1 and the new hardware, and it’s moved to an earlier release, the program is converted to use only the hardware features common to all processors. This flexibility lets you to take full and immediate advantage of new POWER6 hardware.

Functionality—V6R1 features three functional improvements: making programs more thread safe, the capability to utilize teraspace addresses, and making it easier to use trace functions and Performance Explorer (PEX) to address application-performance issues.

V6R1’s addition of thread-local static storage makes programs more thread safe. Programming languages RPG, C and C++ will offer new syntax for accessing this new storage class. You can find details on how to use thread-local static storage in the V6R1 Integrated Language Environment (ILE) Concepts manual.

Utilizing teraspace isn’t only a performance enhancer; it’s also a functional benefit. All programs can employ teraspace in V6R1, which means programmers’ jobs just got easier. They no longer bear the burden of ensuring they don’t pass tera-space addresses to programs that aren’t teraspace enabled.

The PEX tool can’t automatically collect this detailed level of performance information and trace data by default. A recompile is often needed to allow the PEX trace points to hook into the program. That’s no longer the case in V6R1, making it easier to collect detailed trace and performance data to analyze an application-performance issue.

The V6R1 conversion opens the door to using teraspace for memory allocations, which offers a performance boost for your applications.

Next page: >>