Special Articles on AS400

Preparing for V6R1

What to expect during your conversion

March 2008 | by Kim Greene

Kim Greene is a technical editor with IBM Systems Magazine and an independent consultant. She can be reached at kim@kimgreene.com.

Illustration by Larry Jost





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








What the Conversion Does

The program conversion for V6R1 involves recreating all Machine Interface programs. This includes both ILE and Original Program Model programs. All program objects (*PGM), modules (*MODULE), service programs (*SRVPGM) and SQL packages (*SQLPKG) will be converted during the upgrade.

Spooled files residing in the system auxiliary storage pool (ASP) will be automatically converted when the SystemÊi server is IPLed, as will any spooled files stored in basic user ASPs. Additionally, as ASP groups are varied on, any spooled files contained in them will be converted.

Files stored in the IFS in pre-V6R1 releases are stored in Unicode Standard 2.0 format. When moving to V6R1, the Unicode version changes to Unicode Standard 4.0 format. Noncase-sensitive files will be converted to Unicode Standard 4.0 format. File systems that contain noncase-sensitive files are root (*/) and any user-defined file systems created with option CASE(*MONO) specified.

Additionally, any Java* programs created and stored in the IFS will be converted during the upgrade.

Preparing for the Conversion

The best way to prepare for the V6R1 conversion process is to use the Analyze Object Conversion (ANZOBJCVN) tool that’s delivered via PTFs for both V5R3 and V5R4. This tool analyzes the objects on your i5/OS server and provides reports predicting how long conversions will take. The tool also notifies you of any program objects that won’t convert when you upgrade to V6R1 or migrate to a new system installed with V6R1.

While the ANZOBJCVN tool isn’t required, it’s highly recommended for proper planning. To acquire the tool, order PTF SI29369 for V5R3 or SI29370 for V5R4. Request that any prerequisite PTFs be downloaded with these PTFs.

There are two methods to run the ANZOBJCVN tool: in collection mode (*COLLECT) and in report mode (*REPORT). It’s best to submit the commands to run in batch mode when both collecting and reporting information.

Collecting the Data—To collect program conversion data, use the ANZOBJCVN command with OPTION(*COLLECT) specified. You can collect most of the information with one command or submit multiple commands to collect the data. It’s important to remember that every time you run the command, previously collected information is overwritten.

If you want to collect the majority of information with one command, here’s an example of the command you’d use:

SBMJOB CMD(ANZOBJCVN OPTION(*COLLECT) LIB(*ALLUSR) SPLFILE(*YES) OBJ(‘/’)) JOB(ANZOBJCOL)

When I submit a batch job, I like to provide a job name that describes the type of job I’m submitting. In this case, I’ve chosen a job name of ANZOBJCOL for the ANZOBJCVN command with the option *COLLECT.

While execution of this command takes some time, you’ll have almost all of the information available for report-generation purposes. The value ALLUSR for the LIB parameter includes all user libraries and many libraries that start with the letter Q. However, if you have Lotus* Domino* running on your server, the QDOMINOxxx libraries are unfortunately not included in this grouping, so it’s easy to overlook them. For a peek at the specific conversion details related to Domino, see my Web-exclusive supplement to this article, “Impact to Domino”.

If you’re concerned about command execution time, you can collect information about the program conversion times for objects on your system by using multiple jobs to collect the data. For example, one ANZOBJCVN job can collect information related to libraries on the system and another can gather information on objects residing in directories. These might look like:

SBMJOB CMD(ANZOBJCVN OPTION(*COLLECT) LIB(*ALLUSR) SPLFILE(*YES) OBJ(*NONE)) JOB(ANZOBJCOL)

SBMJOB CMD(ANZOBJCVN OPTION(*COLLECT) LIB(*NONE) SPLFILE(*NO) OBJ(‘/’)) JOB(ANZOBJCOL)


If you choose the multiple collection command, you’ll need to run multiple reports as well because each collection overwrites the data stored in the collection files.

The tool estimates how long the conversion process will take based on the CPW of the system in which the tool is run. If you’re upgrading your existing system to V6R1, you can use the default program conversion times. However, if you’re upgrading to a new V6R1 system at the same time you upgrade to V6R1, you’ll want the tool to estimate conversion times based on the CPW of the new system.

To do this, you can use the data area QIZAFTCD in library QUSRSYS. This data area doesn’t exist by default. To create it, use the Create Data Area (CRTDTAARA) command. Let’s say you’re running the ANZOBJCVN tool on a model 520 with a feature code of 7735, but you’re moving to a new V6R1 processor. You’d want to create the data area with the processor feature code of the new system. Here’s an example of the CRTDTAARA command, where VALUE(‘XXXX’) represents the feature code of the new POWER6 processor.

CRTDTAARA DTAARA(QUSRSYS/QIZAFTCD) TYPE(*CHAR) LEN(10) VALUE(‘XXXX’)

If the system you’re generating the reports on isn’t capable of being upgraded to V6R1, the ANZOBJCVN tool will show the following exception in its job log: CPFB0E3 “Type and model information not available for this system. Model 0904, Processor Feature Code 7454 will be used to estimate conversion times.”

Generating the Reports—Once the object-conversion data is collected, generate reports to determine if any objects won’t convert and to see the estimated conversion times. Do this using the ANZOBJCVN tool and this time passing in *REPORT in the OPTION parameter. When passing in OPTION(*REPORT), you should specify one additional parameter to indicate the type of report to generate. Six options are available for the RPTTYPE field:

*ALLAVL—Provides information for all object types in both summary and detailed format
*CVNPRB—Shows the objects that won’t convert
*LIBSUM—Provides summary information related to the data collected about conversion times for library and spooled file objects
*LIBDTL—Provides *LIBSUM information in detail
*OBJSUM—Provides summary information on objects to be converted in the IFS
*OBJDTL—Provides *OBJSUM information in detail
You can also generate reports that include more than one option for the RPTTYPE field. Figure 1 shows the first section of the report generated with this command. Its first portion shows which objects will have issues converting. We see that library ASICGI has a total of 48 objects, one of which will have issues converting to V6R1. Figure 1 also shows us that a total of 299 objects were analyzed, of which 297 will be converted with no lost attributes; only one object can’t be converted; and the estimated conversion time is 2 minutes, 15 seconds.

Figure 2 shows a portion of the next section of the report, the library summary report. We see the total time required to convert each library, along with the time to convert spooled files on the sever.

To see the details of each object within each library and how long each will take to convert, the RPTTYPE option of *LIBDTL would need to be passed in. Figure 3 shows an example of how the library detail report looks.

The report shows several columns for each object within a library. Object name, type, system level and creation data are all pretty self-explanatory. The items that may have you wondering are state, digital signatures and profiling. The state of the program is reported as either user or system. Application programs run in user state, while operating-system code normally runs as system state. A program with a digital signature shows that the program object hasn’t been modified and that it came from a trusted source. The tool shows whether objects have digital signatures. Programs will also be categorized as being profiled or not. When an application has been profiled, it contains statistics on control-flow paths used to optimize its execution times. The profiling information will be lost during the program conversion and must be regenerated after the conversion.

Figure 4 shows the object summary section of the report, which summarizes the objects in the IFS and any user-defined file systems created with option CASE(*MONO) specified. In this example, there are 235 objects to be converted with a total estimated conversion time of 10 minutes, 32 seconds.

You can also create your own reports by writing queries over the underlying files containing the collection data. For details on how to write your own queries, see chapter 2.5 in the IBM Redpaper REDP-4293, “i5/OS Program Conversion: Getting Ready for i5/OS V6R1,” available online (www.redbooks.ibm.com).

You can create your own reports by writing queries over the underlying files containing the collection data.








When the Conversion Happens

You have three options to consider for determining when program conversions occur. The first option is for objects to be converted when they’re restored to a V6R1 system or when an unconverted application is installed. Second, program conversions can be scheduled using the Start Object Conversion (STROBJCVN) tool. Third, they can convert on first touch of an object. Regardless of the program conversion option selected, the conversion will only happen on a V6R1 system. You can’t preconvert the programs on a V5R3 or V5R4 system.

Conversion during restore—Option 1 should be seamless to the end user. When restoring objects, the Force Conversion on Restore (QFRCCVNRST) system value specifies what should happen with objects to be converted.

Conversion with the STROBJCVN tool—I highly recommend converting objects with extensive conversion times using this method. It avoids saddling end users with the penalty of conversion time the first time the object is accessed.

Two options are available when running the STROBJCVN tool in V6R1: *CHECK and *CONVERT. *CHECK is a good sanity check against the output of the ANZOBJCVN tool with option *REPORT. *CONVERT is the main option you’ll use.

Conversion with first touch—Objects can also be converted when they’re first used, which is commonly referred to as first touch. This option is viable for objects that take a fraction of a second to convert.

Restoring to Previous Versions After Conversion

Objects that have undergone conversion when upgrading to V6R1 must be converted back if they’re restored to V5R3 or V5R4. To accommodate this conversion, you need the necessary PTFs on the V5R3 or V5R4 system prior to attempting to restore program objects created in V6R1.

The following table lists the PTF required on earlier versions of i5/OS for programs having undergone the V6R1 program conversion to be restored back to these releases:

i5/OS release
PTF

V5R3M0
MF41354

V5R3M5
MF41734

V5R4M0
MF40520

V5R4M5
MF42655


Happy Converting

I hope I’ve given you some valuable information about the V6R1 conversion. You should know why the program conversion is happening, what you should do and how best to do it. I’ve provided some tips for working with the tool in a Web-exclusive article, “Tips for Working With the V6R1 Conversion Tool” (www.ibmsystemsmag.com/i5/19325pl.aspx). These additional references may also be helpful:

Redpaper REDP-4293 “i5/OS Program Conversion: Getting Ready for i5/OS V6R1” (www.redbooks.ibm.com/redpieces/pdfs/redp4293.pdf)
KB 1288199 “Considerations for Domino when upgrading to i5/OS V6R1” (www.ibm.com/support/docview.wss?rs=0&q1=1288199&uid=swg21288199&loc=en&cs= utf-8&lang=)
II14306 “Analyze Object Conversion (ANZOBJCVN) for V5R3M0 and V5R4M0” (www.ibm.com/support/docview.wss?)uid=nas23af47a966c4df94586257306003c6868)
System i upgrade planning Web site (www-304.ibm.com/jct01004c/systems/support/i/planning/upgrade/index.html)
Best of luck in your upgrade or migration to V6R1!

More Articles From Kim Greene



Impact on Domino

Tips for Working With the V6R1 Conversion Tool

Tips for Working With the V6R1 Conversion Tool
< Return to main article

Print Email

IBM recommends using the Analyze Object Conversion (ANZOBJCVN) tool to prepare for your conversion to i5/OS V6R1. ANZOBJCVN analyzes the objects on your i5/OS server and provides reports predicting how long conversion will take. The tool also notifies you of any program objects that won’t convert when you upgrade to V6R1 or migrate to a new system installed with V6R1.

I found three issues with the ANZOBJCVN tool that I’d like to share with you to make your life easier.

The first issue relates to the default setting for the maximum number of spooled output records allowed for the file QPIZARPT in library QSYS. By default, this file can have 100,000 spooled output records. Once you exceed this amount when generating program conversion reports, you’ll see the following message associated with the ANZOBJCVN *REPORT job you’re running.


Message ID . . . . . . : CPA4072
Date sent . . . . . . : 12/28/07
Time sent . . . . . . : 19:32:22


Message . . . . : Maximum number of records reached for file QPIZARPT. (C R NOMAX 1-999999)




To temporarily get around the issue, you can specify R, NOMAX, or a number up to 999999 to allow the program to complete its execution. I understand the built-in precaution of not allowing more than 100,000 spooled output records to be generated to protect disk consumption on a customer’s system. However, my experience has proven that almost no system can run with the default settings and have the reports generate without throwing this error. To get around it, change the print file attributes for the QPIZARPT file in library QSYS and specify *NOMAX for the maximum number of spooled output records, with this command:

CHGPRTF FILE(QSYS/QPIZARPT) MAXRCDS(*NOMAX)

The second issue was an annoyingly simple error. Regardless of how you run the *COLLECT portion of ANZOBJCVN, the *REPORT version will always report that you specified “/” for the objects to collect information about and the subtree parameter will always show “*ALL.”

For example, I specifically ran the tool to collect only information about all user libraries and spooled files. I explicitly specified *NONE for the OBJ parameter and *NONE for the SUBTREE parameter and, voila, the report says I collected information over *ALL for the OBJ parameter and *ALL for the SUBTREE parameter. To better explain, the command I actually submitted is:

ANZOBJCVN OPTION(*COLLECT) OBJ(*NONE) SUBTREE(*NONE)

The results in the report indicate that I submitted this command:

ANZOBJCVN OPTION(*COLLECT) OBJ(/) SUBTREE(*ALL)

It’s definitely not a showstopper, but be aware that it could skew your results if you thought you really ran the program conversion collection tool over “/” for the OBJ and *ALL for the SUBTREE parameter when, in fact, you didn’t collect any of this information.

The third issue concerns missing libraries. I recommend you check the reports to see which libraries are reported by specifying option *ALLUSR for the LIB parameter when collecting the program-conversion information. As the sidebar indicates, Domino program libraries aren’t included in the all user library selection. Check the list of libraries the tool reports back against a list of libraries on your System i server to ensure none was overlooked. The Domino conversion can be time consuming so checking for all critical libraries on your server will help ensure your estimates are accurate. For more specific conversion details related to Domino, see “Impact on Domino.”



Many happy returns of our dear AS400s Birthday
Hi All



21-June-2008 is our dear AS/400’s 20th birthday. Having been a bachelor (System i) for many years it got married to System p (RS/6000) and now the union is called as IBM Power Systems (i to We).



The AS/400 (I still love to call this way) had an amazing journey picking up all the hot technologies both at the Software and Hardware level. No matter how much ever has changed, there are few things that will make this rock-solid business machine stand out amongst the rest of the crowd. These are:



1) Security, Reliability, Availability and above all Scalability.

2) Single-Level Storage

3) Technology Independent Machine Interface (TIMI)



Anyways, these are known stuff that everyone is aware of, thought it will be a good refresher.



I attended a Webinar last Thursday (6/19) hosted by Tango/04 where I had the privilege of hearing Dr. Frank Soltis talk about “THE FUTURE OF THE IBM i PLATFORM”. On this special occasion, I thought it will be worth while to share some of the key points in random order:



1) Rochester, Minnesota (birthplace of AS/400) will celebrate the birthday on Monday (6/23). I THINK WE MUST ALSO CELEBRATE BY CUTTING A BLACK AND GREEN CAKE.

2) 2008 is a special year for 3 things:

a. OCT 2008 marks the 30th Anniversary of SYSTEM/38 (Predecessor of AS/400)

b. NOV 2008, marks the 40th Anniversary of Dr Soltis’ move to Rochester when he was assigned a task for replacing a SYSTEM 3

3) After the iSeries merged with RS/6000 during Apr 2008, there were mixed reactions in the market.

a. Large Customers are very happy about the merging of platforms

b. Small and Medium customers felt they are losing their dear AS/400

c. Dr. Soltis mentioned that the exact same feeling was there 20 Yrs ago when small and medium customers refused to buy/upgrade to AS/400 from S/38

4) We all know during the year 1995 IBM introduced a major hardware change that led to moving 48-bit CISC to 64-bit RISC

a. The transition was smooth no rewrite and in rare instances a recompile was required

b. When 64-bit processor was introduced, everything inside the box was 64-bit including the OS & DB.

c. The platform had already set stage for 128-bit

5) Now here are some of the Futures that IBM is focusing on:

a. World of Super Computers. IBM currently holds the record building the world’s fastest computer (Road Runner)

b. The trend is to bring in Super Computing to desktops using super fast processors

c. Currently the POWER 6 (introduced in 2007) processor running within IBM Power Systems is the fastest processor in the world

d. In 2010 IBM is coming out with POWER 7

e. With the new faster processors there might be extensions to OS, Programming Languages

f. IBM has introduced HYBRID ARCHITECTURE involving POWER6 + 8 Special Purpose Processors giving a 10-12% performance improvement

g. POWER7 will introduce a Virtual Accelerator that further improves the performance.

6) The session ended with a Q&A with Dr. Soltis. Key among them are:

a. Will windows run on POWER6?

IBM initiated the discussion with Microsoft in Year 2000 regarding this but did not materialize. As per Dr. Soltis, Microsoft is too busy now to move windows to 64-bit (which IBM has already done in 1995).

b. Will Intel compete with POWER processors?

Dr. Soltis’ personal opinion is that for the next few years, IBM and INTEL are going to be the only two chip making vendors. The target markets for these chips are entirely different. IBM POWER chips are clearly for High-end computing whereas INTEL is more for Mobile and Low-end computing.


Sorry if I had bored you with this long detail. If you have read this so far it clearly shows your commitment/loyalty to AS/400.



Once again a very HAPPY BIRTHDAY to AS/400, A VERY HAPPY MARRIED LIFE WITH SYSTEM P and MAY YOU LIVE LONGER.








Thanks