The Four Hundred--OS/400 V5R3 PTFs Can Corrupt Licensed Internal Code

Newsletters	Subscriptions	Forums	Safari	Store	Career	Media Kit	About Us	Contact	Search	Home

Volume 15, Number 25 -- June 19, 2006

OS/400 V5R3 PTFs Can Corrupt Licensed Internal Code

Published: June 19, 2006

by Doug Bidwell

Unlike many of you, I spend a great deal of time--some would say an inordinate amount of time--dealing with PTFs for the OS/400 and i5/OS operating systems. And even a techie like me gets burned every now and then. Be careful with Cumulative Group PTF C6101530, which I call "cume" 6101 for short. If you follow the current installation instructions that are online at IBM's Fix Central site, you will be OK. But if you follow the instructions that ship with the PTF order, you could in trouble.

The basic problem is that IBM issued from PTFs, and they were defective. This is never a good situation, but all operating system vendors have this problem. It follows the Rule of Unintended Consequences: You fix one problem, and you cause an entirely different one because computers, their setups, and their applications are complex.

The following is an excerpt from SF98088: Defective PTFs, an IBM Preventive Service Planning document:


36. 16 May 2006 
DEFECTIVE PTF(s): MF34369, MF38536, MF38576, MF39123, 
                          and/or MF39361 for V5R3M0        
                          MF35091, MF38575 and/or MF38658  
                          for V5R3M5                       
        LICENSED PROGRAM = 5722999               
        APAR NUMBER: MA33716                     
        USERS AFFECTED: All i5/OS users with PTFs MF34369, 
                          MF38536, MF38576, MF39123, 
                          and/or MF39361 applied for V5R3M0.
                          All i5/OS users with PTFs MF35091,
                          MF38575 and/or MF38658 applied    
                          for V5R3M5.                       
                          If any of the above PTFs are      
                          temporarily applied, perform the  
                          following command to remove the PTFs:
                          RMVPTF LICPGM (5722999) SELECT    
                          (MFXXXXX) RMV(*PERM) RMVDEP       
                          (*YES). If any of the above PTFs are 
                          permanently applied, a restore of the 
                          Licensed Internal Code will be    
                          required.                         
                          LIC PTFs MF34369, MF38536, MF38576, 
                          MF35091, MF38575 and MF38658 are    
                          included in cumulative PTF Package  
                          C6101530.                           
             REASON DEFECTIVE: The Work with disk unit screens     
                          under Dedicated Service Tool (DST)  
                          and System Service Tool (SST) are in
                          English, not the installed National 
                          Language Version (NLV).             
                          Under some conditions, the Work with
                          disk unit screens become unusable 
                          for all languages.
             RECOMMENDATION: The defective PTFs MUST all be removed 
                          before applying the fixing LIC PTFs. 
                          Apply LIC PTF MF39611 when it 
                          becomes available for V5R3M0.                
                          Apply LIC PTF MF39614 when it    
                          becomes available for V5R3M5.

In that long list of stuff, here's the sentence that has the gotcha: "If any of the above PTFs are permanently applied, a restore of the Licensed Internal Code will be required." Superseded status also means that it was applied permanently. And, the gotcha is that putting on the latest cume over the 6101 cume will hose you as well.

There's a whole bunch to tell you on this one, but, we'll start with first telling you how to figure out if you've got an issue or not. Briefly, for those of you who have never done it, if you have to "restore the licensed internal code" (otherwise referred to as "slip the LIC"), you've got some anxiety in front of you. It's simple, it's well documented, and there's lots of help out there to get you through it, but it is cause for worry. If you get into a situation with your disk drives that require the use of the screens in question, and, they come up corrupted, you then may be in a situation where you have to slip the LIC before you can trust what you see on the disk screens. This is not a pleasant position to be in, if you catch my meaning.

To determine where you are, use the command DSPPTF for each of the PTFs above (MF34369, MF38536, MF38576, MF35091, MF38575 and MF38658, all for 5722999 Licensed Program Product). If any of them come up with a status of superseded or permanently applied, you are probably into a slip the LIC situation. You can always contact your next level of support and get a confirmation.

Instructions on what is involved and steps to perform a restore of the Licensed Internal Code (which IBM may or may not call a slip of the LIC) can be found in the Backup and Recovery Guide (SC41-5304-07), Chapter 4.

If you have never done this procedure, or, if you're the least bit anxious about doing this procedure, I urge you to seek the guidance of your next level of support for your iSeries or System i. If you are not experiencing an issue with this at this point, then I suggest you do the preparatory research, seek the guidance of your next level of support, and be patient. There is no need for panic in any of this; it's just a matter of being prepared.

Now for the fun part: I will try to explain how this happened. The defective PTFs were first made available in Cumulative Group C6101530. At the time they were issued, they were not known to be defective. They were found to be defective about six weeks later. Many of us had installed cume 6101 by that time, and, several HIPER PTFs and other group PTFs as well. IBM posted the note in the install instructions for cume 6101 at that time to omit these PTFs when putting on cume 6101. So, the only people with issues were those that installed cume 6101 in that six-week period (yours truly and some of my customers), or those who ignored the installation instructions (yes, people do this). IBM also immediately issued cume C6142530, which automatically omitted the offending PTFs. So, today, if you have to go with a cumulative PTF update, do not put on cume 6101, put on cume 6142 instead. If you need to put on 6142, and you already have 6101 installed, putting on 6142 does not put you in any greater jeopardy.

Also, you might want to be cautious with a PTF called SF99503-530 DB2 UDB for iSeries Level 10. Level 11 is now available, so go with that instead. Level 10 has issues with defective PTFs as well.

Doug Bidwell is the president of DLB Associates, an IBM business partner that supports customers on the OS/400 platform, and creator of the System i PTF Guide, which we publish weekly as part of our Four Hundred Guru newsletter. You can reach him at tuner@dlbassoc.com

Sponsored By
XPERIA

Size DOES Matter

Size does matter - the relative size of the customer and a supplier. The best relationships happen when customer and supplier are equivalently sized - when they are both small, both mid-sized, or both large. A large company does not, and cannot, pay close attention to a small one for a very simple reason: The small company does not represent a significant portion of the large company's revenues or purchases. The small company is not critical to the large company's continued success.

This is not to say that large companies deliberately mistreat small ones. No, they just don't listen to them very well or pay much attention to their needs.

What does this have to do with ERP software? Everything. Imagine the following scenario: a small to mid-sized manufacturer buys a package from a very large ERP supplier, one with sales of several billions of dollars per year. The manufacturer has some ideas about how the package could be improved to provide better functionality for their unique environment. So they want the software supplier to include those ideas in future development. What do they have to do to get the software supplier's attention? Can they call the president of the software supplier? Can they meet face-to-face with the VP of Sales and Marketing? And if, by miracle, they can arrange such a meeting, what are the odds that the large company will include those unique requirements at the top of their development priority list?

"But," you say, "The large supplier's package will have everything a smaller manufacturer needs." Let's be blunt. Yes, it may have the features and functions that a small or medium-sized manufacturer requires. But it will also come with something else: all the features and functions that are needed by multi-national companies, Fortune 10 companies - the complexity, the bells and whistles, the additional data fields. One way to describe the experience is like this. You're shopping for a new SUV. The salesman says, "I have a special model in the back." You go into the back lot and climb inside the vehicle - nicely appointed, comfortable seats. However, there is a wall behind the third seats. "So what's behind the wall in back?" you ask. "The rest of the bus," replies the salesperson. When you walk around the outside, you realize how big the bus is. "Don't worry," says the salesperson. "You'll only see the first three rows of seats, and I'll price it just the same as an SUV." But that's not the issue. You'll be stuck with the care, feeding and maintenance of a much larger vehicle. And good luck driving it through the city, or, even worse, finding a parking place. You won't be able to drive it to get groceries or to commute to work. You finally conclude that, no matter how nice the interior looks, it just doesn't fit you. Software is the same. So when you're looking at an ERP package, look to see the size of the companies on their customer list. And if they list a lot of the Fortune 100 or Fortune 500 companies, ask yourself if you really want to drive a bus. Look at all the data items in the various tables and files, and ask how many you need, and how many you want to maintain.

Additionally, the service that large software suppliers provide is impersonal. It has to be; how many tens of thousands of customers do they have? There is no way they can focus on any given small manufacturer. Sure, the supplier will use your first name after you give it to them. But the next time you'll talk with a different support person, and a different one the time after that. There is nobody at the software supplier who knows and remembers you by first name each time you call, and who knows what your company does and who can help you beyond just answering basic questions about how the software works.

When a small- or mid-sized manufacturer attends a user group meeting of a large software supplier, they can feel like an Austin Mini-Cooper in a room full of 18-wheelers. It's pretty clear who has the supplier's ear, and which companies' suggestions are the primary focus of the user group.

At the core of this issue is one word: relationship. With a right-sized software supplier, the customer is much more than just a number, just an account, just a monthly maintenance revenue stream to be maintained. A small- to medium-sized manufacturer can develop a lasting and highly beneficial relationship with a small software supplier. In this relationship, the people at the software supplier know the people at the manufacturer by name and by voice. They remember prior conversations; they know the real issues that the manufacturer faces, both on strategic and day-to-day levels. And the supplier is constantly improving their software to better support their customers. What is that worth? Like any intangible, its value is impossible to compute, but worth much more than a typical accountant could quantify. Balance sheets have an entry for "good will" - the difference between the actual value of the assets and what was paid for them. Likewise, a business relationship can, and should, have "good will" - the intention of each party to help the other prosper. That's what makes a relationship valuable. Such a relationship happens best when the two companies are roughly equivalent in size. Each understands the other, because they each face the same competitive pressures on a daily basis. In a smaller ERP software supplier, people throughout the company know their customers. They can get passionate about what their customers need. They create software so their customers can run their businesses better.

What would it take for a small or medium-sized manufacturer to reach the CEO of a large software company, let alone have the luxury of more than three minutes on the phone? Would the CEO ever meet such a customer in person, or tour their plant, or take a real interest in their company? That's where smaller ERP suppliers shine. Customers can reach the CEO. The CEO is truly interested in the customers' well-being, and not from just the standpoint of more revenue. There is the bond of being smaller businesses, with all the difficulties and triumphs that entails. The smaller ERP supplier has indeed walked several miles in the small manufacturer's shoes.

Relationship is more important for a small-to-medium manufacturer than a large one, because small-to-medium manufacturers tend to have few IT resources, and therefore rely more on the software supplier and/or the implementation consultant. Thus, relationship will be more important to the manufacturer, in the long run, than almost any given feature or function.

Since smaller software suppliers sell to small-to-medium manufacturers, it is that size of manufacturer that their implementation consultants have the bulk of their experience with. An implementation consultant who has just finished helping a Fortune 50 company implement a large ERP package would not fit well with the culture or expectations of a small-to-medium manufacturer. Consultants who specialize in small-to-medium manufacturers tend to be more practical and results-oriented (just like the packages they are implementing). They roll up their sleeves and make things happen. They are agile; adjusting to the realities of the particular client. They think in terms of hours, days, and weeks, rather than weeks, months, and quarters.

Generally speaking, once a competitor acquires an ERP package, the acquired package languishes as far as future development. The victor frequently encourages the customers of the acquired package to convert to the flagship package. Contrary to popular perception, the size of a software supplier is no predictor of its future survival. In the recent past JD Edwards, which was arguably the premier ERP supplier on the AS/400 platform, was acquired by Peoplesoft, one of the Big Four software suppliers. Peoplesoft, in turn, was acquired by Oracle. Another of the Big Four software suppliers, Baan, was acquired by Invensys, who later sold it to SSA, which has now been acquired by Infor, which also owns MAPICS. And now that Microsoft has also acquired several smaller ERP suppliers (Great Plains, Axapta, Navision, and Solomon), one can only wonder if it will continue to invest in all of them, or start encouraging customers to migrate to a single package. E-week (an on-line magazine) states, "Four years after the piecemeal acquisition of the Axapta, Great Plains, Navision and Solomon ERP applications, Microsoft is still trying to turn it all into a coherent midmarket product line…Customers are left wondering whether Microsoft is committed to supporting all these products into the indefinite future, or … which products [will] prosper and which ones [will] wither on the vine." So the best bet is to find a package which the owners will not sell because they want to be in the ERP software business.

Managing Automation outlines the two options. "You go with a large vendor, you spend a ridiculous amount of money, you get half of what was promised, and then it takes a year of arguing with the vendor's many different service organizations to get the solution you believed you were buying.
"[Or,] you go with a small vendor, you get exactly what you want, [and] they bend over backwards to service you..."

Small ERP suppliers are agile by necessity. That is one of their competitive strengths. Big companies can take forever to make a decision, then another forever to include it in the package, and still another forever to roll it out to the field and make it work in their customers. One venture capitalist has quipped, "While big companies deliberate, small companies obliterate."

Finally, large company ERP packages can take a long time, even a very long time, to implement because of their complexity. They take longer for people to learn, and they have more options which need to be tailored and tuned. This is more important than it sounds, because of the operational and financial implications. Small packages have three substantial financial and operational advantages over large packages:
1. Implementation cost. The actual cost of implementation should run 1 to 2 times the cost of
      the software, but, for some of the very large packages, it can increase to a factor of 10
      or even higher! Ask the references how much it cost to have the software running their
      company well.
2. Implementation time and risk. A rule of thumb is that when an ERP implementation starts
      stretching beyond 12 months, life will intrude (other matters will become higher priority,
      the project leader will leave the company, etc., etc., etc.), and the package will not achieve its
      intended objectives. The smaller the package, the faster the implementation. A fast
      implementation reduces risk and improves the odds that you'll get the results you wanted.
      Ask those same references how long the implementation took.
3. ROI. Shorter implementation times yield higher ROIs because they start paying back more quickly.
      For smaller packages, the actual ROI is also higher than larger packages because the expenses
      are lower. Finally, the risk of an incomplete implementation is lower for smaller packages,
      which again improves ROI.

Large package or small package? Do you want the bus or the Mini-Cooper? Do you want long, expensive, risky implementation, impersonal service and moderate ROI or quick implementation, low risk, excellent long-term relationship and support, and high ROI? Size does matter. Choose wisely.

To learn more please visit us at www.xperiasolutions.com
or call (610) 433-6511 x123

Editor: Timothy Prickett Morgan

Contributing Editors: Dan Burger, Joe Hertvik, Shannon O'Donnell,
Mary Lou Roberts, Victor Rozek, Kevin Vandever, Hesh Wiener, Alex Woodie

Publisher and Advertising Director: Jenny Thomas

Advertising Sales Representative: Kim Reed

Contact the Editors: To contact anyone on the IT Jungle Team
Go to our contacts page and send us a message.

Sponsored Links

iTera: High availability solution for $50 a day - includes IBM System i5 Hardware
COMMON: Join us at the Fall 2006 conference, September 17-21, in Miami Beach, Florida
LANSA: An entirely different approach to application modernization and innovation

THIS ISSUE SPONSORED BY:
Aldon Xperia Lakeview Technology LXI Integrated Print Solutions

TABLE OF CONTENTS

Happy 18th Birthday, AS/400; Time to Leave the Nest

OS/400 V5R3 PTFs Can Corrupt Licensed Internal Code

OS/400 Shops Share Their Training Experiences

The X Factor: Virtual Server Sprawl

But Wait, There's More:

Windows Patches Kill Operations Console on V5R3 and V5R4 . . . IBM's Systems and Technology Group to Invest Heavily in India . . . Middleware Sales Continue to Grow in 2005, IBM Still the King . . . Magic Software Sells Off CRM Application Business . . . IBM Launches System i Laboratory in South America . . . System i Helps Catholic Charities Spend Its Money on the Needy . . .

The Four Hundred

BACK ISSUES


Project Bandit to Open Source Identity Management Software Dell Pre-Announces Generation 9 of PowerEdge Servers Merrill Lynch Cases IT Spending, Server Buying Patterns Mad Dog 21/21: Patent Depending


It's MIPS Again, at Least for Hardware Pricing Top Mainframe Stories and Vendor Announcements Chats, Webinars, Seminars, Shows, and Other Happenings


Get Your Patch On: 8 Critical Updates Issued by Microsoft Dynamics AX 4.0 Takes Step Toward Unified ERP RingCentral Provides Virtualization for Phone Calls Windows Compute Cluster Server is Ready, Microsoft Says


OpenSolaris: One Year Down, Participation Up Merrill Lynch Cases IT Spending, Server Buying Patterns HP Says It Will "Blade Everything" As Next Gen Boxes Launch The X Factor: Is Memory-Based Software Pricing the Answer?