The Cost of Standing Still

We are constantly amazed (more like dismayed) at the number of shops we run into at conferences and during private classes who are still using V5R4. Since IBM has now announced that end of life for V5R4 support is in September of this year, we're wondering how that will affect these shops.

We suspect that many end to need an official end-of-life date to give them the impetus to move. So maybe some will finally get moving. After all, 6.1 has been available since 2008 and  7.1 has been around for more than two years. So we're not exactly talking about joining the bleeding edge!     

Speaking of 7.1, the other thing that has surprised us is the number of people on V5R4 who tell us they have plans to move to 6.1 soon. Why 6.1? If you've waited this long, surely one advantage of upgrading is that you can short-circuit the process by going directly to 7.1. Why move to 6.1 now just to get caught up to 2008 technology? Of course the great thing about moving to 7.1 is that you will be able to add new functionality by applying technology refreshes--something that has always required a release upgrade in the past.

We know many other reasons--besides inertia--keep shops at V5R4. We've heard of application providers who are charging high prices for versions that will run on 6.1 and later. In some cases this is happening even when the "upgrade" simply requires that a few modules need to be recompiled. And then of course a few applications are in use that can't move to 6.1 at all, because the company is now out of business and the code was compiled prior to 5.1 and has no observability.

Maybe other reasons also exist. We're interested in hearing about what's keeping shops from moving beyond V5R4 after all this time. Hopefully some of you will share your reasons with us in the comments. If you have recently upgraded or are planning to upgrade to 6.1, we're also curious what kept you from going directly to 7.1.

Obviously, there is effort and time involved in the upgrade process--perhaps more so in the move beyond V5R4 than from other releases. But every coin has two sides. There is a cost to staying on an old release as well.

Once IBM support goes away, you may also incur a cost related to your compliance with various standards, such as PCI. And there's the cost of not implementing new features and functions that require later releases.

We've written a lot about the new features in RPG in recent releases, including, but certainly not limited to, RPG Open Access, which can greatly simplify your RPG logic. Database has some great new features to offer as well as well as a long list of other functions supported in 6.1 and those found in 7.1.

So what's keeping you--or other shops you know about--at V5R4? Inquiring minds want to know.

MySQL Is Back as Zend DBi!

In January  we blogged about Oracle giving the cold shoulder to the IBM i world by announcing they would no longer be supplying a compiled IBM i version of MySQL. Today we have an update on that subject, at long last.

MySQL became popular among IBM i shops because of the popularity of PHP on i. While PHP certainly doesn't require MySQL, many open-source PHP applications that have caught on in IBM i shop (e.g., Joomla, Drupal and SugarCRM) are written to use it. Indeed SugarCRM has become so popular among i shops that they have produced an IBM i specific version. The availability of the DB2 for i Storage Engine for MySQL also made it easier to integrate those applications with more traditional IBM i applications and databases.

Back in January, we speculated that IBM and Zend were in discussions about a potential solution to the uncertainty caused by Oracle's actions. Now, we finally have an answer. Zend has agreed to step up to creating, maintaining and shipping compiled versions of the MySQL code to run on IBM i.

Zend has decided to call this distribution Zend DBi--we don't understand why, really. But not to worry, the intention is that the code that runs on IBM i coming from Zend will be the same as MySQL on other platforms. Zend will simply be compiling and packaging the pieces. Required code changes will be made available to the MySQL open-source project as required under the terms of the GNU GPL license.

Zend will distribute the new Zend DBi code as part of Zend Server and will also make it available for download by IBM i shops as a stand-alone package, much as we had downloaded MySQL from the Oracle in the past. And the storage engine that helps to integrate MySQL with DB2 for i will continue to be supported and made available by the DB2 for i folks in Rochester.

So it came to pass as we predicted it would; it just took a little longer than we had thought it might. Hmmm, it seems the idea was conceived in January and arrived in October. That's about the right gestation period. Welcome to the world, Zend DBi!

It's Time for a Name Change!

Now before you get all bent out of shape about the possibility of yet another name change for our favorite system, that's not what we're talking about this time. What we're talking about is the terminology we use.

Back in October at our RPG and DB2 Summit, our friend and proud DB2 apostle, Mike Cain, made a statement that we thought worthy of a larger audience. We can't  recall exactly how the roundtable conversation reached this point, but the overall  thrust can be summarized along the lines of "How can we convince people from other platforms that we have a real database?" 

Mike's answer was a simple one: STOP TALKING ABOUT FILES, RECORDS AND FIELDS. We  need to change the way we talk about it if we want other people to take it seriously. In Mike's (and indeed our) experience, Oracle and other database users are often convinced that what we have is little more than a flat file system on top of which has been cobbled some half-baked database mechanism. If you think  about it, it's hardly surprising. We constantly talk old-technology terms like  files and records, so we shouldn't be surprised if others think that that they are the foundation of the system.

Of course nothing could be further from the truth. What we have is a fully relational database system which, when called upon, can cleverly disguise itself as a flat file system! Those of us who use the platform can understand what a terrific advantage this is--but it's understandable that others would view it with suspicion.

So here's the thing--keep calling the system an AS/400 or iSeries (or whatever) if you  must, but whatever else you do, when engaging in conversation with an Oracle/SQL  server/MySQL/whatever devotee USE TERMINOLOGY THAT THEY UNDERSTAND. Talk to them about your Tables (files) and Rows (records). Don't even _mention_ record-level access--they can't do it, so at best they won't care, and at worst will think  that your database is out-of-date. 

Remember--perception is everything--the fact that record-level access is a useful feature is irrelevant. Having a full-fledged relational database is the only thing that matters when making comparisons with other platforms. Also remember it's not only techies who notice the difference in our terminology from  those who work on the so-called "real database" platforms but also managers, CIOs,  CTOs, etc. They may not know a row from an index, but often they recognize those as database terms.

In fact, we'd go so far as to suggest that you should begin to transform your DB lingo in everyday conversations, even with other i folks. Why? Becuase unless it is ingrained into you, it will be tough to suddenly remember to use new terms consistently when talking to non-i folks. We're working on it ourselves and we know how hard it is when the old words we've used for decades trip off the tongue so easily.

Note that this suggestion has nothing to do with whether you actually use SQL to either define or access your data. Regardless of how you create or access the  data, you have Tables, Rows and Columns. (For those who are interested in reading  more of our thoughts on DDS vs DDL, take a look at the EXTRA article we wrote on the subject. 

So here's your handy-dandy cross reference to the SQL terms you should be using and their related "old" names (Try it--you have nothing to lose but your "old-fashioned" label!):

• A Library is a Schema or a Collection
• A File is a Table
• A Record is a Row
• A Field is a Column
• A Logical File is a View (when talking about how the program views the data)
• A Logical File is an Index (when talking about performance)

Logical Files do present a dilemma in terminology--they can be either an Index or a View. In practice, it's often a "strange" non-standard combination of Index and  View. An Index in SQL is used almost exclusively to improve performance when accessing data via SQL (which sadly on other platforms is the _only_ way to access data!) while a View in SQL is used to present data differently to the user or a program (e.g., by using select/omit or restricting columns or joining to other tables, etc.).

Think about how your everyday language could be impacting the perception of our system in the eyes (and ears) of those CIOs and CTOs not fortunate enough to have experienced i.

A simple change in terminology just might make a big difference.