RPG: A Rose by Any Other Name ...

Today’s IBM i 25 chapter begins by musing about the meaning of RPG’s name. In one of our earliest blog posts back in July 2007, we blogged about the name of the RPG language and whether it should have a new one to match its new personality. We had suggested “Borg” since RPG seems so good at assimilating the best features from other languages. Many of you offered alternative suggestions.

In reading today’s anniversary chapter, Susan learned something new—although Jon claims he knew it long ago. When RPG IV was introduced, the name “RPG” was officially declared to be no longer an acronym—or, more correctly as Scott Klement pointed out recently, an initialism. For those who didn’t realize this, to be an acronym, apparently it must be pronounceable as a word, such as NATO. If it is simply spelt out, as RPG is, it’s technically an initialism.

While the letters RPG may not officially stand for anything any more, RPG, the language, means a great deal to many thousands of programmers around the world and the users of their rock-solid, efficient, modern business applications.

In many ways it’s a good thing that RPG no longer stands for “Report Program Generator” because it has been many, many years since RPG’s primary function was reporting. It has evolved radically over the years.

If the picture that comes to your mind when you think of RPG is of columnar logic with multiple conditioning indicators and nary a hint of SQL, it’s time to wake up, Sleeping Beauty—you’ve missed a lot in the last 25 years. IBM i’s modern RPG IV is barely recognizable as a relative of the AS/400’s original RPG/400.

Today’s RPG logic is written in free format. It also utilizes libraries of homegrown, open-source and third-party functions in addition to RPG’s own library of more than 70 BIFs (built-in-functions). As a result, what would have been dozens of lines of indicator-laden, columnar “old-style” RPG are replaced by simple, powerful expressions.  And RPG’s data access has “grown up” too. Support for a huge variety of native data types and a deeper level of integration with SQL than is seen in almost any other language makes RPG a natural partner for IBM i’s integrated DB2 database.

Still think that RPG = Green Screen? Think again. Many shops are running interactive Web and mobile applications with logic powered by RPG. Or if you prefer, RPG code can easily provide the business logic underpinnings of Web services, stored procedures and other services to applications written in PHP, Java, Python, Ruby, .NET, etc.

Inevitably there are things that RPG doesn’t understand natively and that IBM cannot add to the language in a meaningful timeframe. The pace of change in today’s IT world is just too fast. That’s why Open Access was recently added to the language. It allows for the development of drivers to add new functionality while maintaining RPG’s powerful data marshaling capabilities. For example, you can write a driver to call a currency conversion Web service from RPG, allowing any RPG program to treat access to real-time currency conversion data as if it were a huge database in the sky. Simply set the key values for the currencies involved and issue a CHAIN operation. The conversion rate is returned as if it were being retrieved from a database column.

In our next EXTRA article, due out in the next couple of weeks, we’ll take a look back at 25 years of RPG. We’ll post the link in the comments section here when it’s available, so check back if we’ve piqued your interest. Or follow us on Twitter @JonParis or @SusanGantner.

And don’t forget to join in the celebration with all 25 chapters leading up to IBM i’s 25^th  birthday at  http://bit.ly/ibmi25.

In the meantime, it seems a shame to waste a perfectly good initialism as RPG. Maybe we could unofficially assign one—or a few. How about Renegade Programming Gurus? Robust Programming Genus? Real Problems Gutted?

 

 

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! 

IBM i 25 - Join the party

In celebration of the 25th anniversary year of IBM i, we're joining IBM and many others in reminiscing about our experiences with this fabulous platform which has defined our careers. Check out the IBMi25 Facebook page (bit.ly/ibmi25)  - you don't need a Facebook account to see it - for some very clever vignettes and videos about our platform. Join the party.

We are still covering our earliest AS/400 experiences and, so far in the story, we haven't met each other yet. So we're including remembrances for each of us individually - Jon is first this time! 

Jon - Joining IBM and COMMON in Toronto

As I mentioned at the end of the previous "history" post, after 18 months on contract I joined IBM full time. The actual hiring was somewhat rushed through as (unbeknown to me at the time) my manager had decided that I was the prefect person to present two sessions on the new COBOL compiler at the upcoming COMMON conference in Toronto. As far as I can tell his decision was based entirely on the fact that my background was as midrange systems user and not a Lab Rat. It certainly was not based on my public speaking skills. The last time I had done any public speaking was more than 5 years earlier.

As the day approached I became more and more terrified. I think I barely slept for the two or three days prior to the event. That terror climaxed as I walked into the room and found myself faced with more than 100 eager faces - all waiting for me. I fumbled my heap of foils - scared silly that I was going to drop them and lose the sequence. "Foils" ? In those days of course there was no Powerpoint (or Keynote in my case) and no laptop connected projector. Just black and white transparencies and an overhead projector. I remember very little about the sessions - way too nervous I guess - but apparently I did well enough that over time I was tasked with more and more presentations at various customer briefings and User Group events.

That COMMON conference was a milestone in a number of ways.  For one it was the first to ever be held outside of the United States, second it was the first to feature the AS/400. I'll leave Susan to tell you about the other distinction that this conference held.

It was around this time that I first made contact with the lovely lady who is now my partner in every sense of the word. I was tasked with acting as the liaison between the COBOL team and the Rochester education groups. That included the folks in the Business Partner teams as well as the education groups who were responsible for updating users and the field force on upcoming product releases. This was when I first got to know people like John Sears and Ed Simon who many of you will remember from COMMON and the IBM Tech Conferences. It was in this role that I first communicated with Susan. We didn't meet (and then only a brief corridor introduction) until the subsequent COMMON conference in Chicago. At this point I should note that Susan remembers none of this which merely goes to prove that she is far more memorable than I am!

Susan - Introducing the Latest in Programmer Tools
In the fall of 1988, COMMON was in Toronto. It was an exciting time for those of us who had eagerly awaited this brand new system, the AS/400. This was the first COMMON conference after the announcement and for many attendees, it was their first chance to see and interact with one.

It was for that reason that a handful of intrepid IBMers (including me) decided to hold an impromptu "hands on experience" for attendees with the new programmer tool on this system - PDM. Since it was impromptu, we had lots of hurdles to overcome, including getting the AS/400 system we were to use down the hall to an appropriate room. Since the system was brand new and much in demand, you'd think we would have been very careful about this move. We weren't. We pretty much shoved the system (obviously one of the smaller boxes - well, small in its day) down the hall, sliding it along the carpet. It fell over a few times in the process. But of course, it got to the other end and IPLed just fine - just one of many stories of the ruggedness of AS/400. We had a few instructor-led exercises for attendees to go through to experience the new PDM tool for the first time. This was the beginning of the notion of holding lab sessions at COMMON - a traditional that carries on still today.

Of course, the irony of the many hoops I jumped through to convince programmers to use PDM in 1988 will not be lost on many of you who know that I'm currently spending a lot of time convincing people to stop using PDM & SEU and use RDP/RSE instead. But it's really not incongruous. PDM & SEU were the latest technology for AS/400 programmers in 1988. RDP is the latest technology for programmers on IBM i today. I'm still doing the same thing, 25 years later!

Close Encounters of the AS/400 Kind

As Steve Will revealed in his blog yesterday, there's going to be a lot going on in the IBM i world over the next few months to celebrate the "birth" of the AS/400 25 years ago. Yes it has been 25 years and boy does that make us feel our age a little today.

We've decided that we'll use this blog over the next few months to post a few of our own memories, so instead of writing this as a joint effort and letting you work out who-wrote-what we're going to write these pieces from our individual perspectives. What about your own early AS/400 experiences? Please tell us about them in the comments section of the blog.

Susan's Early AS/400 Encounters

25 years seems like a long time, but as they say, time flies when you're having fun! And my years on this platform have seen tons of fun.

After a few years as an IBM customer in Atlanta where I developed a passion for the System/38, I joined IBM as a S/38 specialist Systems Engineer (remember those?).  Within IBM, I started to hear rumors about a new system being developed in Rochester, Minn., which would merge the S/36 and S/38 platforms. When I learned the new system would be based on S/38, that was enough for me. I made it my mission to get to Rochester to have some kind of role working with that new, future system.

I don't remember now how I learned of the opportunity, but I discovered they were looking for Systems Engineers to visit Rochester for a few weeks to work on the new system code named "Silverlake." I jumped on that with both feet. My application must have sounded a tad desperate, because I later heard from one of the people who screened the applications that the reaction to mine was "Hey, we've got a live one here!" 

I was one of the first to participate in the residency to work with Silverlake. I was in awe of the Rochester lab and the brilliant, dedicated folks who worked there. I didn't think I could get more enthusiastic about the system but I was wrong. Being in Rochester was just where I belonged.

I did go back home to Atlanta, but not before lobbying (more like arm-twisting or maybe just begging) to become part of a group Systems Engineers who would travel the world for several months before June 1988 to do pre-announcement teaching to IBMers about the technical details of the Silverlake system. I made the team and in the months leading up to the announcement of what became known as AS/400, I was in my element. I discovered that I was not only enamoured with the system, but also with teaching--something I had not done much of until that time.

I had been working on and around the AS/400 for so long by June 1988 that the announcement itself seemed almost anti-climatic to me. Even so, I had found my niche and was thrilled at the thought of the future before me. Not long after, I moved to Rochester--it was inevitable--and found that I even loved Rochester itself--all except for the weather!

I'm no longer in Rochester and no longer with IBM, but I'm still every bit the AS/400 (aka iSeries, aka IBM i) lover that I was 25 years ago. And I'm still thrilled at the future of this platform.

Jon's Road to AS/400dom

Back in 1986 I was working as a consultant, mostly specializing in converting systems from other manufacturers to the System/38. However, at the time I first heard about the possibility of a contract at IBM I was working on a System/36. IBM, it turned out, were looking for someone who knew COBOL on the S/36 and S/38 and who also had some exposure to the internals of compilers. IBM wanted someone who could take over the maintenance of the S/36 and S/38 compilers to allow their existing staff to work on a "new product." Like most in the community, I had already heard the rumors of a new system that would replace the S/36 and S/38, so the possibility of working alongside its developers was intriguing.

Perhaps I was the only one they interviewed that had the required qualifications. Or it could have been my telling the interviewer that it would be good to have the opportunity to fix a few of the bugs in the S/38 COBOL compiler that I had discovered over the years. Either way I got the job and started work in February 1987. The first bug I handled on my own? A problem with S/38 COBOL reported by the Dallas Cowboys!

Over the months I picked up bits and pieces about the new system, including the fact that the testing was all being done on modified S/38s--there was no actual AS/400 hardware in Toronto. Even then I wasn't allowed to actually see the system it was locked away in a separate area of the machine room under additional security. This always struck me as somewhat amusing because there was really nothing to see, and, from what we read in the trade publications, the press already knew far more about the system than we lowly lab rats did.

After the AS/400 server's formal announcement things relaxed a little and having (I guess) proved myself on the S/36 and S/38 compilers I was asked to do some work on the COBOL/400 compiler. One of the first tasks I got involved with was checking the compiler and run time error messages. As part of automating the foreign language translation of the messages the English versions were being "sanitized" to get rid of words such as "execute" that caused translation problems. Some of the sanitized messages were funny, but the best we encountered was one where the term "Secondary card hopper" had been converted into the politically correct--but completely meaningless: "Not so important card hopper."

After 18 months on contract I joined the lab full time, but that's a story for another day.

Mentoring and More

We were particularly pleased to see the comments to our blog two weeks ago on training new RPG programmers. It's always gratifying to know that you are not the only people in the world who think that educating our replacements is a good idea. Maybe some of you want to work forever--not us--we have many things we'd like to do.

Among the comments was one from Torbjörn Appehl who mentioned that in Sweden a company named Tieto had recently undertaken a program to train young recruits in the joys of RPG. We mentioned this story last year in our blog, but at the time didn't know the name of the company, etc. Now, thanks to Torbjörn, we have been able to look at the company's website and we highly recommend you to pay a visit too. This is a company to be watched. If you don't live in one of the countries Tieto serves, you're forgiven for going off and weeping quietly in a corner as you bemoan the state of IT companies in North America and probably elsewhere.

So many companies seem content to simply deal with resource shortages by outsourcing, which is not only a short-term solution, but also one that in our opinion is also shortsighted. Do we really want our children to be the hewers of wood and and drawers of water for the rest of the world because we were not willing to invest in them? On the Tieto website pay attention to the mention of mentoring programs and other similar investments the company makes. Do you know of anyone in North America doing that? Or are most, as we suspect, simply bemoaning the skills shortage, which is not just an IBM i and RPG issue, and doing nothing about it.

This issue is fresh in our minds as it came up during the roundtable discussion that opened the annual WMPCA Spring Conference, which we are attending this week. Present at the meeting were a number of present and former students of our friend Jim Buck, who we mentioned in the earlier blog entry. Some of them described the importance of mentoring and internship programs to their success and how hard such opportunities were to come by. Jim is currently working on ways of extending the reach of his programs and we hope to work with him on that. Something needs to happen.

Another comment on the blog came from Christian in France who works for a French training company that runs introductory IBM i and RPG training two or three times a year for clients whose companies have recruited young programmers. We were particularly pleased to see Christian's comments regarding modern programming practices and tooling.

In part he said: "Of course, we use SQL and free RPG, even if we have to talk about DDS and fixed form RPG. Our tools are system i Navigator and RDP, no choice!..."

"As you can see, it is possible to teach 'IBM i', it's a wonderful system with many advantages that can be interesting for young people, but we have to show them the 'sunny side'."

The "sunny side" indeed Christian! No young programmer in their right mind is going to be interested in RPG II style fixed-format coding and SEU. You'll be lucky if you keep them for a month, even if they are an unpaid intern! Show them modern RPG and RDP and you'll find a very different response.

Thanks also to the others who commented on the blog. We really appreciate your feedback.

Another point that came up during this evening's discussion was that most IBM i programmers aren't just programmers. They're really business analysts that implement the results of their analysis in RPG. This in some ways reinforces the point we made about retraining experienced business people and teaching them how to program. It was the way Jon's father broke into programming and we know many other people whose entry into the world of computing took a similar path. Now if only we could work out a way to make that happen on a large enough scale to make a dent in unemployment levels and the RPG programmer shortage that would be progress!

Educating New RPGers

We had a discussion with a client this week that we've had many times before. It usually starts off with a question about what language they should use for future development--the implication (sometimes stated) is that RPG isn't an option.

Why? Not because it's an old language, not that it can't do the things they need it to do, but because it has become too hard to find RPG programmers. More specifically, it has become even harder to find RPGers who are willing and able to do modern things.

We responded with the same suggestion that we normally do (and we have done here in the blog before. If you can't find RPGers, look for a PHPer (or Java or .Net or a ...) who seems to have a business mindset (vs. wanting to write games or the next Facebook application) and teach them RPG and DB2. If you stick to /Free and other modern RPG practices--at least in the beginning--our experience has been that they not only learn RPG easily, they actually quite like the simplicity of the language. After they are hooked on RPG, then you can (if you must) gradually show them the ancient-style code that you almost certainly still have lying around the shop.

This idea has been used with great success in a number of IBM i shops. However, to our knowledge anyway, they have tended to be relatively large shops where there were a number of people who could share the mentorship role. In this specific case, we're talking about a relatively small shop. So the time commitment to not only teach the RPG language to the newbie but also to mentor them in the intricacies of IBM i, DB2 for i, etc. would require a very signifiant proportion of the shop's developer resources. And that's a problem.

Schools in the the IBM Academic Initiative program rarely seem to teach RPG these days. This is mostly because, as we blogged previously, even when they graduate RPG-literate students, too many potential employers still insist on three to five years' experience. But, even if all of the school programs were as successful in turning out RPG literate graduates as our friend Jim Buck at Gateway Technical College, the time it takes for students to graduate from such programs is longer than some of our clients can wait. They need to build their five-year plans today--before their existing programmers hit retirement age--and they can't build a plan simply based on the vague hope that there will be RPG programmers around to replace those staff.

A dilemma to be sure. What's the answer? We wish we knew, but increasingly we think that this is an area where IBM, perhaps in conjunction with their business partners, needs to take a lead. There are a lot of unemployed folks out there who have extensive business experience. Many of them probably did some programming with TRS-80, Commodore 64s, IBM PCs, etc. in their youth. Maybe--just maybe--they are a resource that could be tapped to help fill the programmer gap. But it will need an initiative from someone of the stature of IBM to make it a reality and ensure that "graduates" of such an initiative would be able to break through the insane experience barrier that so many shops erect around their hiring process.

Have you encountered this problem? Come up with and solutions of your own?  We'd love to hear about them through comments to the blog.

A Hidden Gem in TR6

This week’s big news in the IBM i world is of course the announcement of Technology Refresh 6 (TR6). We’re sure our fellow bloggers Dawn May and Steve Will will give you the lowdown on the wonders within over the coming weeks - but we were drawn to one of the less vaunted items that we spotted in the partner and press briefing materials.

The title of this new offering is “IBM i for Business Intelligence” and we think it has a lot of potential for IBM i shops under pressure to move data off the box. Data is at the heart of any system and it is IBM i’s capability deliver that data reliably day in day out that makes it the “secret weapon”* of many companies. Many IBM i shops are pressured to move that data off i onto other platforms in order to “mine” it for the underlying information it contains. This offering takes the position that if you are going to analyze your data on another box then why not make that other box an IBM i?

Think of it as a Solution Edition package for DB2 Web Query. By that we mean it is a complete package consisting of discounted hardware, software and service offerings all designed to get you up and running as quickly as possible. The packages start as low as $40K and with the amazing horsepower of the new POWER 7+ hardware behind them we’re sure that many customers will find that even the smaller boxes meet their needs for data analytics without disrupting the production system. Not only that, but even the smallest of the packages has more than enough horsepower to also be able to act as a development box, or experimental home for introducing new Web technologies, or ... well you get the picture.

In part our interest in this new packaging stems from the fact that we have chosen data analytics as a focus area for our upcoming Summit event under the banner of “Keep Your i on the Data.” If you know you need to do more with your data then check out the details of some of the sessions listed here. Now that we’ve seen this announcement, we know why our IBM speakers were so keen to suggest these particular sessions!

One other item that piqued our interest was news of the new mobile tooling from Zend. Having watched the video, we have decided that we want to have a chance to play with it some before we talk more on the topic. If you are using PHP, or considering doing so, it is well worth a look.

 

* Ever wondered why you don’t see IBM tell the world about the huge corporations who build their success around IBM i’s legendary reliability? Fact of the matter is that many of those companies won’t let them. They would much rather see their competition waste millions of dollars in ill-fated attempts to use a “more modern” platform. Wouldn’t you feel the same way in their position? Sad though.

 

 

CL Rides Again

Those of you who have followed our writings (ramblings?) for a while know that we have a kind of love-hate relationship with CL. The syntax, while effective for commands, just feels clunky and unnatural when used for an entire program. Back in the pre-RPG IV days we would begrudgingly call CL programs to do the stuff that we just couldn't do in RPG. But as RPG IV evolved, and the number of system APIs increased, there was less and less that we couldn't do directly in RPG. Combine that with the fact that CL effectively stagnated for many years and there was little to convince us otherwise, hard as CL aficionados such as Bruce Vining and Jim Sloan tried to convince us.

But things have changed. Under the stewardship of Guy Vig, CL has been given a new lease on life with enhancements in many areas. It started back in OS/400 V5R3 with additions to the types of variables that could be defined, new looping and control structures, increases in the number of files that could be declared and more. The enhancements continued in V5R4 with the addition of subroutines and enhancements to data definition that effectively provided a form of data structure (DS) definition. Since having to use string/substring operations to fake out DS definitions was one of our pet peeves in CL, this was a big step forward. IBM i 6.1 continued the forward movement with the addition of INCLUDE, the equivalent of RPG's /COPY. It also finally added a CLOSE command--now you can actually close a file that has been opened in the CL program and open another (or the same) file in the program without performing unnatural acts.

Now with the latest round of PTFs to 7.1 a number of our remaining frustrations have been addressed and we really have been forced to start to take more notice of this IBM i stalwart. To use this new CL functionality on a 7.1 system, PTF SI49061 must be loaded and applied*. Note that support is _not_ going to be PTF'd to the 6.1 or 5.4 releases, but you will be able to compile CL code that uses these new functions on your 7.1 system by specifying the appropriate target release (TGTRLS) value.

These latest enhancements provide some major upgrades to CL's string handling capabilities. Even better, because they are almost identical in name and operation to their RPG equivalents, there's nothing much new to learn. The new functions are:

%CHECK    - Check Characters
%CHECKR - Check Reverse
%SCAN    - Scan for Characters
%TRIM    - Trim Characters at Edges
%TRIML    - Trim Leading Characters
%TRIMR    - Trim Trailing Characters 

These new built-ins can be used wherever CL would permit the use of an expression of the same type. For example %CHECK can be used in an IF or WHEN command. %TRIM (and its variants) can be used directly in a character expression (e.g., CHGVAR VAR(&ADDRESS) VALUE(%TRIM(&STREETNAME) *BCAT %TRIM(&CITY)) ) or to set the value of any command parameter that permits expressions (i.e. ,the parameter is specified as EXPR(*YES) ). You can get more details on the %TRIMx functions here and on the %CHECKx and %Scan functions here.

We understand more enhancements are planned for CL in the future, but nobody will actually tell us what they are yet so we'll all have to wait. What is clear though is that the days of CL as a stagnant, unchanging language are over and that we really need to start paying more attention to it.

Many thanks to Guy and the CL team!
 
* Note: The %Trim functions were actually snuck in via PTF back in October 2012 but went largely unnoticed.