How Free Is Free, Anyway?

I guess the first bit of news is The Biggest IBM Announcement Since 1988! This slightly tongue-in-cheek statement is based on some banter that has been going in various forums about the announcement. I believe the consensus is that the CISC-to-RISC announcement was really the biggest thing in iSeries history (short perhaps of the original AS/400 announcement) and that this latest announcement is more along the lines of the AS/400-to-iSeries naming "event."

A lot of smoke, a few mirrors, but not a ton of substance. For example, the "death of the interactive tax" was greatly exaggerated. What has happened in fact is that the iSeries basically now has two flavors: with interactive and without. With interactive costs more than without. The "how much more" is the issue, and from early indications, it's substantial: from 200% to 400% more than the equivalent model with no interactive. What has in effect happened is that IBM has finally drawn a line in the sand and said, "If you want 5250, you will have to pay, and pay dearly, to have it."

Those companies that have already purchased the maximum interactive in their tier will indeed save money. But by IBM's own estimation, companies that use one of the smaller interactive features may actually end up paying more for an equivalently sized machine. In an odd parallel to our own U.S. economy, it looks as though the interactive tax cut will be to the benefit of the rich at the cost of the middle tier.

This is serious news for software developers, as they have basically been told to either come up with a Web interface or abandon the smaller businesses that cannot afford the interactive feature. With the shortening of the length of service for each release (see below) in order to stay current, smaller businesses will need to choose between no interactive or all interactive in the not-too-distant future. Unless IBM makes some serious cuts in the Enterprise Edition pricing model, smaller businesses will have to go Web-based. And that doesn't mean a screen-scraper, either, because screen-scrapers all require interactive cycles.

In fact, the folks that have to be most shaken up by this announcement are the screen-scraper providers. They'll now all be competing for those few very high-end accounts that can afford the interactive costs. Of the products with any production installations here in the Americas, only WebFacing and my product (PSC/400) provide a purely batch alternative. I knew this was the right way to go way back in 1999 when I started my book, but I guess nobody believed me.

I'm Late for a Very Important Date

OK, I was late upgrading from V4R5. Heck, my poor Model 150 doorstop never made it to V4R5, and so it's stuck in Apache-less V4R4 limbo. Some people might say I procrastinate, but it's not that simple. It may just be me, but it seems like IBM is shortening the length of service for each release, while at the same time reducing some of the backward compatibility. The idea seems to be that IBM wants to change the mindset of the user base--the mindset that "if it don't work, don't fix it"--and instead bring them into the "update early and often" fold. And while I understand that from IBM's point of view, my clients don't necessarily see it that way.

This puts those of us who write software in a bit of a bind. On the one hand, I've got clients on older releases who want their software to keep running; on the other hand, I'm trying to support new releases to get new business. And unless I'm independently wealthy and can afford an entire fleet of machines on various releases, I have to be very judicious in my upgrade path. Right now, I'm moving to V5R1 so that I can still support my clients on WebSphere 3.5 Standard Edition, while at the same time I can get ready for WebSphere 5 Express. Only recently did IBM announce WAS5X as the successor to WAS35, so now we vendors finally know what we need to support (WebSphere 4 was not an option because of pricing, but I'd rather not rehash that old story). So, since V5R1 is the only release that supports both, it was finally time for me to upgrade to V5R1.

Well, part of the standard upgrade process is to get your machine to the latest and greatest PTFs for your current release. Not a problem, right? I went to one of my favorite IBM Web sites, Preventive Service Planning, made sure I had the latest and greatest numbers, and faxed in an order for the latest cume and group PTFs for R450 (IBM's term for what we call V4R5). At the same time, I ordered the cume and groups for R510, just to be on the safe side, and I continued on.

Now, I knew that I was past the support date; according to IBM, support for V4R5 stopped on December 31. But I figured that they had to know people like me existed, people who just hadn't yet had the time to upgrade. Besides, several of the PTFs were dated in mid-January, so they were created after the cutoff date! So, as I said, I figured it would be no problem.

Well, I got a fax back almost immediately. The fax said, "2 of your orders were not processed because programming services only supports requests for R510 & R520 of OS400 now." Well, there's a fine how-do-you-do! Even though the PTFs I was trying to get were in some cases only days old, I couldn't get them. This was a bit frustrating, but I didn't give up. Instead, I poured my heart out to others in the industry. And someone suggested that I try iPTF.

Well, I'd never used the Internet PTF system before, and I want to say this: It was easy to set up and easy to use, and I had zero problems (other than my transfer speed). I called IBM and asked if I had an account already set up (I have so many accounts, it's hard to know which one pertains where, and that's still an issue IBM needs to address). It turns out I didn't, but within an hour of registering, I was up and running. I was able to order my cume and all seven group PTFs, and while I had to order each one separately, it only took me about 15 minutes to order them all.

Within a few minutes, my initial confirmations started to come back, and within just over two hours, all my orders were available on an IBM FTP server. Next came the ugly part, downloading them. Since I have a 384K SDSL line, I have decent speed in both directions, but downloads are pretty limited, and I was looking at about 25 hours of download time. Luckily, I was able to once again ask a friend for help, and within hours, a 1.5MB line managed to pull down a good portion of my requests. Burning them to CD was a simple process. Since I use Nero, I had to rename the CD images from .bin to .iso, but that was the only additional step.

Then, like the good boy I am, I backed everything up. Now, remember that I have no tape drive on this machine. While it seemed like a good idea at the time, it also means that I have no way of doing an actual SAVSYS. While most of my save options can be directed to a save file (and then offloaded), there's no way to SAVSYS to a save file. This makes sense, I suppose, because how would you later get that save file back to the machine in order to restore? So, while I was a conscientious administrator and backed up everything I could, I didn't do a SAVSYS.

I shouldn't have worried. The PTF upgrades went smoothly, and within minutes of the completion of the installation process, I was testing my machine, and soon after that I had my PSC/400 test programs up and running on WebSphere.

And there was much rejoicing.

It did not last.

V5R1--Moving Up Is Hard To Do...

...at least harder than applying PTFs. I wanted my V5R1 upgrade to go as smoothly as my V4R5 PTF install, but this was simply not to be.

After everything had gone so wonderfully during the PTF process, I had expected nothing less from the upgrade. After all, they've done this hundreds of times already, right? Well, I should have known from the get-go that it wasn't going to be easy. The warning signs were there from the very beginning, when my initial V5R1 order got lost. I ordered the disks and confirmed the order on January 3, but when I checked back again a couple of weeks later, it hadn't shipped yet. After a couple of phone calls, things changed, and I received the disks sometime around January 18.

OK, so now it was time to do the installation. I assumed that this was a pretty vanilla Model 270, so the automatic install should work no problem. Assumptions are bad things. Very, very bad things.

Friday, January 24, 2003

1:30 p.m.
I began the automatic install from the Software Installation manual (page 17). I put the SLIC disk into the reader and IPLed the machine using the command "PWRDWNSYS *IMMED RESTART(*YES) IPLSRC(D)". The machine thought and thought. And then it thought some more. Eventually, it went through the Licensed Internal Code load screen like it should. And then bad things began to happen. In this case, rather than load the rest of the operating system off of the disks, my machine displayed a sign-on screen. I didn't know what else to do, so I signed on. I tried to do a WRKACTJOB and got an MCH error, at which point I knew things weren't quite right. Basically, what I had now was a machine with V5R1 licensed code and a V4R5 operating system. And if you think about it, the fact that it came up at all was pretty cool.

3:00 p.m.
I tried numerous things. I tried to reinstall, I tried to do a manual install, and so on. Every time I tried something, the system insisted that its internal tables were messed up. I got messages like the following:

Field 0 in mapping template not valid when creating cursor.
Function check. MCH1819 unmonitored by QP0DCFID at statement *N,
instruction X'00AE'.
(repeat above two errors once)
File system may be unusable.

"File system may be unusable." Not exactly good news.

5:50 p.m.
After about four hours, I decided to give it up for the night, with the full intention of doing a scratch install in the morning. However, one of the last notes posted on MIDRANGE-L that night indicated that a call to 1-800-IBM-SERV might be in order. I slept on that idea.

9:15 a.m.
Called 1-800-IBM-SERV. Talked to a nice guy with a balky computer. It seems that the IBM customer service computer wasn't up. Since the machine in question is a leased machine, neither one of us was sure whether I was covered for support. I gave him my information and then opened a severity one incident (severity one meaning my machine was completely broken and unusable). He said a tech would call me "right away."

11:00 a.m.
By this time, I was just about ready to call IBM back to find out what exactly "right away" means. Decided to give them 30 more minutes.

11:15 a.m.
My good friend Mark Waterbury of Industrial Strength Software Company called. Through his involvement with education, and especially IBM's PIE program, Mark has done quite a few upgrades and scratch installs. However, after reviewing my situation, he became convinced that all I needed was a manual install. Since the V5R1 SLIC was already in place, I needed to get the V5R1 operating system loaded, and he thought a manual IPL would do just that. Mark walked me through manual IPL, and the initial load screen (the one that I had expected during the automatic load but that never appeared) popped right up.

11:55 a.m.
Initial IPL completed. Got sign-on screen. Began manual installation of licensed programs.

12:52 p.m.
Manual installation complete. Review showed successful installation.

1:01 p.m.
Began application of cume PTF.

1:30 p.m.
Found a problem with the PTFs. A bad one. MF27247 wouldn't load because it is superseded by MF28144.

1:45 p.m.
Did research, and MF28144 does indeed supersede MF27247. But there were no special instructions regarding MF28144 in the cover letter for cume C2145510. Looking further, MF28144 wasn't on my machine and is in fact not available until cume C3007510. I decided to IPL anyway and see what happened.

2:05 p.m.
IPL completed!

2:11 p.m.
PSC/400 (and WebSphere 3.5 Standard edition) ran successfully! I went through my standard test screens, and everything was fine and dandy.

2:15 p.m.
Called 1-800-IBM-SERV. The lady who answered was very nice and apologetic and canceled the call. ($250 gone, IBM!)

Author's Note: After this, I tried to install my next cume. That completely blew up my machine, to the point of requiring a licensed code reload. As it turns out, I ended up getting that call in with 1-800-IBM-SERV anyway. I'll relate that story in detail in my next column.

Conclusions

The moral of the story? IBM is getting better at some things. The processes continue to improve, especially those wherein we the customers do the bulk of the work. The human side of the equation, especially in support, is still a little lacking. And these days it seems that it's not due to a lack of either effort or care on the part of the personnel, but instead on some glitches in the infrastructure. Every problem I've had in recent weeks (credit card payment, late delivery, no call back) seems to hinge on processes, not people. Whenever I pushed the issue, somebody talked to somebody else, circumvented whatever procedure was holding things up, and resolved my problem.

Marketing, on the other hand, is not getting better. The whole spin of the interactive feature has been pretty hard to justify from day one, and in my opinion, IBM just makes it worse every time they "address" it with one of these restructurings.

I just hope IBM is learning from these mistakes.

Joe Pluta is the founder and chief architect of Pluta Brothers Design, Inc. He has been working in the field since the late 1970s and has made a career of extending the IBM midrange, starting back in the days of the IBM System/3. Joe has used WebSphere extensively, especially as the base for PSC/400, the only product that can move your legacy systems to the Web using simple green-screen commands. Joe is also the author of E-Deployment: The Fastest Path to the Web. You can reach him at This email address is being protected from spambots. You need JavaScript enabled to view it..