How Old Is Your OS?

If your shop is at V5R4, then hopefully it comes as no surprise to you that regular software maintenance (SWMA) for V5R4 ends September 30 of this year. Lest you find yourself thinking, “But we need more time - why doesn’t IBM extend that deadline?” please note that this IS the extended deadline. V5R4 has been supported years longer than earlier releases for various reasons.

If you really can’t move to 6.1 (or 7.1) by September and must still have support, IBM announced last week the ability to purchase service extension for up to three years. Your support cost will be increased and over regular software maintenance. Hopefully this will help to serve as an incentive to move to a currently supported release (at last!). If you want more details about the extended support, take a look at the IBM announcement. Another document with some additional details is here, along with details for the service extension support for V5R3.

“V5R3?!?” we hear some of you saying. There are many reasons/excuses for not moving beyond V5R4 as we have explored before but surely anyone could have moved to at least V5R4 by now, right? Apparently not.

As a matter of fact, we recently talked with an ISV who has customers whose systems are still at V3R7! Not many fortunately, and the ISV’s software is not supported at that release. But they do know of a much larger number of customers who are at various release levels between V4R2 and V5R3.

Now, as surprised as we were to find evidence of V3R7, we’re sure this isn’t a record. We’re confident that some of our followers probably know of (perhaps even work at) shops earlier than V3R7. So there’s your challenge: In the comments below, let us know of the earliest active version of OS/400 (it was stilled called that in those earlier releases) that you know about.

 

 

 

Looking Back on 25 Years

 

 

 

 

 

 

This week we return to the subject of the IBM i 25th birthday bash with some more personal reminiscences.

One shared memory is of the first time we met Malcolm Haines in the U.K. before he moved to a marketing role in the U.S. We had heard about Malcolm's incredibly successful Graffiti campaign in the U.K. and while doing a one-day event in London had asked our hosts if they could introduce us.

Long story short--we had a fascinating meeting with Malcolm (the first of many) and arranged to get some copies of the advertising collateral sent to us to help inspire the troops back home. It is amazing to us looking back to realize how powerfully these messages still resonate.

One example: "Shouldn't the system run without an army?" is every bit as relevant today as when it was first used. In fact you might ask why IBM isn't still using it, but we digress. You can see images of three of the posters used in the campaign on the IBMi25 Facebook page but since you have to dig through the "Recent posts by others" to find them, Trevor Perry also posted them here.

Jon's Memory Dump--Breaking Things

It never occurred to me that quite a lot of my work on the compiler would be spent "breaking" it! Why? Because the new S/36 compatible compilers had to mimic the behaviour of the originals. But the original compilers were written in assembler and, due to memory limitations, took quite a lot of shortcuts en-route to the executable program. Often memory patching techniques were used to ensure that a particular path was followed if certain conditions existed. The problem was that the compiler writers often made the assumption that one of a finite number of alternative paths would have been set up and therefore (assumedly to save a few bytes) had not coded for the possibility that the programmer might have managed to code something that fell through gaps in syntax validation and resulted in a "none of the above" condition. Some of the time this would cause an error to be signalled later in the process, but it was not uncommon for it to produce an executable program. Just not one that the compiler writers had even intended.

So why does this cause problems? Well one of the first lessons I learnt when working with compilers was that by the time we discovered that we had a compiler bug, at least a dozen programmers had decided it was a new "feature" and were using it in production code. Sometimes the bug had the potential for causing significant problems and so we fixed it and dealt with the fallout. More often we had to retain the aberrant behaviour and sometimes allowed the programmer to specify that they wanted the correct behavior via a compiler option. In the case of the S/36 compilers there was a lot of aberrant behavior--some of which was even documented. So we had to do our best to "break" the correctly working compiler code (which was based on the S/38 compiler) and modify it to make the same mistakes that the real S/36 compiler had made. This wasn't always possible but we tried.

Susan's Memories of Rochester, Minn.

I mentioned in an earlier post that I became fascinated with the AS/400 before it was AS/400--back when it was code-named Silverlake in the Rochester lab. After spending a few weeks on residency in Rochester and then several months traveling around the world teaching IBMers about the system-yet-to-be-named, my fascination turned into an obsession. I was more convinced than ever that the developers in Rochester were the smartest people I'd ever hope to spend time with.

But I grew up in the South--in South Carolina and Georgia --I had rarely even visited parts of the country where snow covers the ground for months at a time. Was I obsessed enough to actually move to Minnesota to be around the home of AS/400? Apparently so.

Some of my friends enjoyed laughing at my attempts to buy a snow shovel after moving to Rochester (saying to the sales person when asked what kind of snow shovel I needed, "there are different kinds?"). But I did manage to live there, snow shovel(s) and all and I loved it--not the weather, but the place and the people. By the way, it's May 1 today and I see that Rochester is expecting around 4 inches of snow tomorrow. You definitely don't move to Rochester for the weather!

I worked in the AS/400 Technical Support Center in Rochester, the home of one of my heroes in the community at the time, John Sears. I found that John was indeed inspiring but there were many others in Rochester--in the support center as well as in the lab--who were equally inspiring, the many unsung heroes toiling away in the background creating amazing software. I found it impossible to be there and not be impressed at the brilliance housed in all those blue buildings (and the white buildings across the road).

My office happened to be just a few doors down from the ITSO--the group responsible for the famous Redbooks publications. As interesting as the Redbooks they wrote were, they didn't hold a candle to the experience of working with the people who wrote them. Technical field staff (aka SEs) from IBM offices all around the world came to the ITSO for extended residencies or multi-year assignments to dig into the new technologies being implemented by the developers nearby and make them practical for use by mere mortals. It was like working next door to the United Nations. I met and worked with people from places I barely knew existed and found kindred spirits from around the globe--all united by a similar obsession with (in the immortal words of Malcolm Haines) "the best computer a business can buy."

Some of the international assignees from the ITSO found a way to stay around after their assignments and have gone on to play important roles in the life of the system and the community. Perhaps the most recognizable name today from among those is Ian Jarman. Now, where have we heard that name before?

 

Back to the Future with RSE

If there's one thing that folks in the IBM i community love, it's a name change, right?

Well, here's one that we never thought we'd see - one that puts us back to where we were a few years ago. Nope, IBM i is not changing its name to iSeries or AS/400 (but that would have been a good April Fool's joke a few weeks ago, wouldn't it? Wish we had thought of that.)

We're sure you have all followed carefully the progression of packages and names for the Eclipse-based development toolset from WDSC (WebSphere Development Studio Client) to RDi (Rational Developer for i) and then to RDP, or RD Power as some prefer (Rational Developer for Power Systems). 

We're kidding of course. From the number of questions we get personally and see on forums, Internet lists, LinkedIn groups, etc., the litany of names has been a big source of confusion for many.

Guess what--we're going back to RDi again. Rational Developer for i. They've added "RPG and COBOL Tools" to the end of it, but still, it would seem that V9.0 (for those who have lost count, the current version is V8.5.1) will be called Rational Developer for i - or, we presume, RDi for short, as before.

We haven't seen any information yet on pricing, but we're hopeful that there won't be a significant increase beyond perhaps the (sadly) all-too-predictable 15% that seems inevitable with each turn of the crank.

As far as enhancements to function for IBM i RPG and COBOL developers, we haven't seen a lot. It appears that IBM Data Studio is now packaged with the new version vs being a free download that you could install yourself at 8.5.1.

Also listed are "Significant improvements to Remote Systems Explorer qualities of service." This sounds like lawyer-speak for bug fixes. We hope we're wrong but don't hold your breath. Then again, bug fixes would also be welcome.

There are two new packages, in addition to the basic RDi package:

1) Rational Developer for i RPG and COBOL + Modernization Tools, Java Edition - this would appear to replace the Rational Developer for Power Systems Software Power Tools for i.

2) RPG and COBOL + Modernization Tools, EGL Edition - this would appear to replace the oddly named RDi SOA toolset, which never changed to RDP when all the similar products did, for some reason.

From what we understand, if you have Rational Developer for Power Systems (what we've referred to as RDP) and have an active SW maintenance agreement, you will be entitled to a no charge license to the V9.0 RDi package. Someone reported on the WDSC-L list on Midrange.com that it will require a new Activation Kit to be used to install it, however.

Likewise, if you have a license to the RDP Power Tools, you're entitled to V9.0 RDi  + Modernization Tools, Java Edition, and if you have a license to RDi SOA, you're entitled to V9.0 RDi  + Modernization Tools, EGL Edition - both assuming active SW maintenance, of course.

So is all this good news, bad news or no news?

Until pricing is clear and, of course, we see how well the actual V9.0 code performs, it's hard to say. The new packages do seem to more accurately reflect what people really need. AIX/Linux developers have their own product and IBM i folks have RDi - as we did before. If you want/need more significant Java and/or EGL support, there are additional features for that.

Anything that simplifies the ordering process is a step in the right direction of course. But will the Rational reps stop trying to write up orders for RAD when IBM i shops call to get "Rational" to develop their RPG code? We can but hope!