Support MC Press - Visit Our Sponsors

Forums Sponsor

Popular Forums

TechTip: Linux Command Line Basics, Tips, and Tricks (225 views) I need to buy cassettes: 1/4" 2.5 GB (178 views) CyberDefender Grows to Over 8 Million Users (175 views) Frank Soltis, Father of AS/400, Retires from IBM (29 views)

Forums

 

Search Sponsor

POPULAR SEARCHES

Search

Will it be The Joy of Six (V6, that is) or The Annoy of Six? In all likelihood, the correct answer is: it all depends.

In July, IBM announced that it would deliver a new release of i5/OS, V6R1, sometime in 2008. When in 2008 is not yet clear.

The available list of new features and enhancements is somewhat vague and likely incomplete, but they fall mainly in the areas of encryption, virtualization, integrity, Java support, and Web deployment. An attempt to read the tea leaves left after drinking in the announcement suggests that Web deployment is receiving particular attention.

Should you upgrade to V6R1 when the time comes? You'll have to decide that after the benefits are more fully fleshed out. However, if you're using a particularly old System i machine, it's not even an option unless you also invest in new hardware. V6R1 won't run on older systems. The plan is to support System i POWER5 Models 515, 520, 525, 550, 570, 595 and POWER6 Model 570. Thus, a box with an "AS/400" label slapped on it probably won't run V6R1 (unless, of course, you slapped the tag on yourself over top the "System i" label to protest against IBM's system-naming flippancy). Second-generation, but not first-generation, systems with the "iSeries" label will support the new operating system.

Assuming your hardware will run V6R1, you still need to consider another important question: Will your existing programs run under it? In all probability, they will, but not necessarily and not without being converted first. The good news is that many programs can be converted automatically the first time they run on V6R1. You can also explicitly schedule conversion or have it performed when installing or loading the program. But there's a catch: Not all programs will convert without a fuss.

If the previous paragraph induced a feeling of déjà vu — a feeling of having experienced something before despite it being the first time — the feeling may be false. This might not be the first time you've been through this sort of thing. Similar conversions were necessary twice before: once, in 1988, during the move from System/38 to AS/400 and again in 1995 with the introduction of OS/400 V3R6. Then again, if the previous paragraph induced a feeling of having been here before, but you've been exposed to the joys of the Technology Independent Machine Interface (TIMI, also known as just MI) for less than a decade, then maybe it really is déjà vu.

A Redpaper discussing V6R1 program conversion is posted on IBM's Web site. The paper is still marked "Draft Document for Review," with a caveat in bright red print about the possibility that some details may change as a result of that review. Because much of the information in the remainder of this article was drawn from that Redpaper, the same caveat applies here.

Conversion, which must be performed on all programs that use the TIMI, does not alter the name, location, or owning user profile of program objects, but the internal structure of the object is changed. IBM claims that all TIMI programs with sufficient creation data (known as "observability") can be converted. Programs created under V5R1 or later automatically had this data saved unless they were altered in "unsupported ways." Programs created under V4R5 or earlier can also be converted unless their creation data has been deleted. Even then, you can convert those programs after first recompiling them from their source code. Of course, that's a problem if you run no-longer-supported applications for which you don't have source code.

An Analyze Object Conversion tool, ANZOBJCVN, is available through PTFs for V5R3 and V5R4. This tool examines the program objects on your system and reports on whether they can be converted as is. ANZOBJCVN also estimates conversion times. Conversion will, obviously, consume processor resources. Thus, times will vary depending on the CPW rating of the system performing the conversion. If you run ANZOBJCVN on a development machine that holds copies of all of your production applications, the time estimates will not be accurate if the programs are then converted on a differently sized machine.

Fortunately, ANZOBJCVN provides a means to estimate conversion times for a machine other than the one on which ANZOBJCVN is run. The details of that process are beyond the scope of this article.

You don't have to run ANZOBJCVN before upgrading to V6R1, but, because some programs may not convert as is, failing to do so would be foolish. You don't want to find out after you've upgraded to V6R1 that critical applications won't run. You might be able to solve the problem by simply recompiling the program, but you probably won't be able to do so fast enough to satisfy users.

Some things will be lost in the conversion. For example, if you use digital signatures to validate that programs have not undergone any unauthorized alterations, those digital signatures will be lost. This is because conversion significantly alters the internal structure of the program object, thereby invalidating the signature.

In addition, if an object has profiling data but the encapsulated data was removed, the benefits of profiling for that object will be lost during conversion. Reports available through ANZOBJCVN will tell you which program objects will lose their digital signatures and/or profiling benefits.

In some cases, object naming may be an issue. The IFS stores all names in Unicode, currently using Unicode Standard 2.0. With V6R1, an automatic conversion will be performed to switch to Unicode Standard 4.0. In some instances, this may result in names being changed. ANZOBJCVN will report on all affected objects. If it any objects turn up in that report, consider proactively changing their names prior to conversion. Otherwise, some objects may not be found by their old names after moving to V6R1.

If you're sitting there growling "grrr" under your breath (or maybe right out loud) because of the possibility that some of your beloved programs will not convert cleanly and easily to V6R1, hold your growling. Not surprisingly, IBM points out a benefit to be gained through conversion. In addition to the enhanced integrity features that will be included in V6R1, IBM paints the conversion process itself as enhancing integrity.

The Redpaper suggests that "An immediate result of re-creating all MI programs is that any unsupported alterations (for example changing the hardware instruction stream with a service tool) are eradicated. They're gone, so they have no chance of interfering with intended uses of your system." Such programs will have to be rewritten to remove the offending instructions before they can be converted. That's great, unless, of course, those unsupported alterations were done intentionally for a valid purpose.

As the paper suggests, this "feature" of conversion ("feature" is in quotes because anyone who wants to keep the offending code will naturally see it as roughly equivalent to software vendors referring to bugs as features) is a way to increase your confidence in an application from an unknown supplier. If you convert the program as you install it, any code that does not conform to TIMI semantics will be removed. Because you can use the conversion process to "refresh" code at any time, you can employ this technique even for software that the vendor has already targeted at V6R1.

How much work will you have to do before you can experience the joy of six? The first step in answering this question, a step you can take even before the release of V6R1 sometime in 2008, is to get ANZOBJCVN and run it to determine the convertibility of your program objects.