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.

Going Mobile With PHP

In last week's blog entry, we mentioned that we have been getting increasingly involved in mobile applications. For those who have not yet studied the subject, it's important to understand that mobile applications fall into three major categories: browser based, hybrid and native.

The browser category pretty much explains itself, except to note that the browser is always "sandboxed" to some extent and cannot access certain hardware features. These restrictions are slowly being removed and the advent of HTML5 will hasten this process, but it's unlikely that they will ever be as capable as fully native applications. They also are limited in capability when disconnected although once again HTML5 holds out hope there. The major advantage is that, provided you use a Javascript framework to handle device differences, you can program in the same language that you use for your regular Web applications (e.g., RPG, Java, PHP, etc.).

Native apps are written to run on the device itself and can access all of its functionality. The biggest challenge with native apps is that to write for Apple's iOS devices (iPhone, iPad, iPod Touch) you must program in Objective C. To write for Android devices, you typically use Java, and for Windows mobile devices C#. Three different languages and three different development environments. Multiplatform tools such as Phonegap are emerging and gaining in capability and performance, but they basically require that you can write complete apps in Javascript. While we know basic Javascript, writing a complete app using it wasn't on our to-do list.

Hybrid apps typically utilize a native application framework whose components can be configured and controlled by some form of server-based interface. This allows you to use the native capabilities that are unavailable to a browser-based application, but of course you can only ever do things that the framework provides. Similarly stand-alone operations are limited to those supported by the framework. Like browser-based apps, hybrids have the advantage that you can usually use your existing language of preference to provide the server support.

We wanted to develop some native apps, but which language to learn? Which platform to target? Since we own an iPad and an iPhone, iOS was the obvious choice but Objective C is ... well ... different. This weekend we came upon a new tool that has just been released into the Apple App store--Kodiak PHP. As most readers will know, having basically failed at Java we have embraced PHP in recent years and have done quite a lot with it. Could we really use it to produce a native app on the iPad? The answer appears to be yes and no.

The yes part is that the Kodiak team succeeded in porting the Zend PHP engine to iOS and it runs beautifully and amazingly quickly. The built-in support for SQLite allows us to use an on-board database. We have yet to work out how to tie it in to the address book, etc., but the database access itself works very well. The color-coded editor has a "swipe" keyboard extension that makes block selection a breeze and also makes all symbols available without having to switch the keypad mode. That is a great help and makes the editor usable for off-line development even without an external keyboard.

The no bit is partly a function of the immaturity of the product and partly a function of Apple's rather strict rules on what native apps can and cannot do. For example, while you can enter and execute scripts in the editor you cannot download existing scripts. There are many ways to get round this limitation. The one that has worked best for us is i-FunBox, which allows your Mac or Windows machine to interface with your iOS device. You can drag/drop your PHP scripts directly into the application's associated folders. Other options also exist, and admittedly this one's user interface is a bit klutzy, but the free ad-supported version works very well for us and the ads aren't at all intrusive. The tool also supports the (de)installation of iOS apps, music files, videos, etc., but we haven't used that capability yet.

There is also a teeny tiny problem in the current implementation in that HTML Form submissions aren't working in the current release. At least we can't get them to work. That kind of limits the apps you can build! Based on the speedy response we have had from the support team when reporting other issues we expect to see a fast resolution of this problem and with that out of the way can start to do some serious development. The other major issue right now is the lack of documentation--there really isn't any. The basic interface is intuitive and presents few problems. The included sample scripts also demonstrate a few features, but nothing that shows how to access native functionality such as the camera or GPS. The probability is that the PHP wrappers for that native functionality have yet to be built. Without any documents that is tough to say.

In summary, we're excited at the potential this application presents. Its price is low enough ($10) that even if we can never produce a real native application it will have been money well spent as it provides a really easy way to dynamically test PHP constructs under circumstances (like too cramped aircraft seats) where using the laptop is just not practical. Also, it's just plain fun! Give it a try. We think you'll be impressed. The company's home page includes a video of the product in action. If you try it out, let us know what you think via the blog comments.

Need Some Help?

Many of the companies we work with either don't have Help Desk software or have a homegrown application that is muttered about in dark corners. Most of the time the inhibiting factor is the cost of commercial packages. Recently though we've become aware of several free offerings in the PHP world that render that part of the equation moot.

So for those of you in the "we can't afford it" category, here's a couple for you take a look at.

First up is Mantis/400, which in its native IBM i version is distributed and supported by Curbstone, which, having used Mantis internally for some years, ported it to the IBM i and enabled it to directly use DB2 tables. In this regard it remains the only package we are aware of that can do this.

Next on our list is osTicket and we have to say that we really like the clean user interface this system provides. It gets good reviews and seems to have many happy users. However, getting new releases out on time does not seem to be a strong point. The developers seem to get tied up in real paying work--go figure! Apart from being prettier than Mantis, the major difference is one of focus. Mantis is developer centric whereas osTicket is end-user centric and can be used as a direct customer support site as well as for entry of issues by in-house staff.

The latest one to show up on our radar is HESK--thanks to Dan Devoe for pointing this one out to us. HESK is similar in look and feel to osTicket and also has a strong end-user orientation. Since it seems to be the free part of a commercial offering, we suspect that updates may be a little more timely--a thought that appears to be born out by the activity level on the support forum.

Both osTicket and HESK use MySQL and would therefore require IBM's DB2 storage engine in order to store some or all of their data in DB2 tables. Since they are free, it is hardly a barrier to implementation.

Hero Opportunity?

Both osTicket and HESK have such strong end-user orientation that they would be useful additions to any customer facing online systems your company may already have in place. Good self-help facilities can be a major selling point for any company and can also help identify product deficiencies and market opportunities that can otherwise be missed. This is just another of those opportunities to be a hero to your users by demonstrating that your IBM i system can be a vital part of the growth of your business.

A quick rant from Jon: Am I the only one who is constantly frustrated by the "automation" of some of life's basic requirements? For example, a couple of weeks ago I was soaked to the skin by a washroom tap whose sensor was so badly aligned that you had to have your hand almost touching the tap's opening before it would activate--and of course when it did. ... On a similar note, am I the only one who is unable to get a self-flushing toilet to flush when it should? I encountered one recently that flushed six times before I was ready for it! And don't get me started on those silly plastic seat wrap things. When we were at a conference at a Las Vegas hotel the auto-sensing paper towel dispenser was mounted in such a way that it was actually impossible to enter the bathroom without activating it. And on and on. Am I just becoming a crotchety old man, or are others as frustrated by these unwanted additions to our daily lives as I am?

Our Technical--and not so Technical--Reading List

This week we thought we would stray a little outside of the technical world and respond to one of the questions we are often asked. Actually it is more often phrased as a statement than purely as a question "You guys must read an incredible amount of stuff to keep up with all the new things in the IBM i world." This is often followed by "How do you decide what to read?" or "Do you ever read anything except technical stuff?"

Let's start with the technical stuff. We follow some dozen or more online forums ranging from Midrange.com to Code400 to those on SystemiNetwork. We also subscribe to more than 40 technical newsletters covering topic areas from Web design to mobile apps to general IBM i and (not surprisingly) programming in RPG, PHP, etc. Do we read all of these completely? No; there aren't that many hours in the day. We find that skimming the content often reveals trends that we should dig into more deeply.

Of course there are a few writers that we consider "must reads." Scott Klement is the first person to come to mind, followed by Aaron Bartell  and for PHP-oriented topics, Alan Seiden and Mike Pavlak. Trevor Perry is always worth reading; even if we don't always agree with him we have to admire his passion!

We have, of course, large heaps of technical books around the place--more recently the PHP, Web and mobile-related heaps have been growing. Actually since we buy more and more books in e-reader format these days the physical heaps aren't growing as much as they used to, thank goodness. Many of the recent additions to the library come from the folks at Sitepoint. In particular we've added "JQUERY: Novice to Ninja" and "Build Mobile Websites and Apps ..." both of which are excellent introductions to the topics and well priced, as are most of Sitepoint's offerings.

Do we ever read anything non-technical? Sure. In a blog post a few years ago, we talked about our fascination with "Predictably Irrational" and "Freakonomics." Susan has actually re-read "Predictably Irrational" since then and enjoyed it as much as the first time. She has also been enjoying some books by Malcolm Gladwell: "The Tipping Point" and "Outliers" and she has "What the Dog Saw" and "Blink" waiting in her "to be read soon" stack. We also want to re-read our friend Bob Tipton's great book "Jump!: Get Unstuck" before we see him at the upcoming RPG & DB2 Summit, where he'll be our keynote speaker. He might quiz us on the content!

What about reading purely for fun? Absolutely. We recently discovered Kathy Reichs and are thoroughly enjoying her books. We didn't know it when we started reading her, but her main character, Temperance Brennan, is also the main character in the TV series "Bones". But if you don't like "Bones" don't let it put you off trying the books; they are really quite different. "Bones" has just been TV-ized. We have also enjoyed most of the Jack Reacher books by Lee Child, which we began reading at the suggestion of friend and colleague Paul Tuohy.

Jon is a huge fan of Terry Pratchett and even persuaded Susan to read "Nation" which she enjoyed even though she's not into the fantasy genre. This is interestingly one of Pratchett's young reader series, which may say something about our maturity level. If you haven't read it give it a try. It will challenge the way you view religion and society as well as being a darned good read. Jon was glad he didn't realize it was for young people or he might have missed it!

Jon has just finished reading "Randy Bachman's Vinyl Tap Stories," which is a collection of the stories Randy tells on his weekly radio show. If you are a music lover this is a "must listen." Until recently you had to listen to the live stream or on satellite radio in the U.S., but past shows are now available on CBC's website. Next on his reading list is "Outwitting Squirrels" by Bill Adler Jr. ,which from a brief glance is hilarious--and hopefully helpful!

So what else should we be reading? Any and all suggestions welcome.

Educating ... Jon (Among Others)

Educating ... Jon (among others)

This week we want to cover two topics related to education. The first relates to education in the formal sense, the second to that gained in the school of hard-knocks.

Back in our Oct. 25 blog post ("IT Must Be Magic") we continued a discussion on the shortage of young people entering the IT field. Those of you interested in the topic should check out part of an InfoWorld article titled, "11 programming trends to watch." The whole article is well worth reading, but the section headed "Programming trend No. 8: Traditional education fades from relevance" really grabbed our attention. Until we read this we had thought that hijacking talented high schoolers en route to university was something that only happened in the sporting world. Apparently not. It seems that some high-tech firms are actively pursuing the same approach. Interesting.

The article also references a Fast Company piece titled, "Silicon Valley's New Hiring Strategy." Has this approach been triggered by the shortage of IT grads or has experience simply shown that a degree in IT doesn't really prove that you can program in today's fast moving world?

This weekend Jon was doing some work with embedded SQL and had an "interesting" time debugging problems with one particular program. It hasn't done anything to improve his love/hate relationship with SQL, but he can explain why himself:

Susan has always been our in-house SQL person, but I've been doing more and more of it lately, particularly in PHP. I've also been using more and more of it in my RPG code. I want to like SQL--I really do. I have long been convinced that it's the right way to go--not for everything, but certainly for set retrieval and processing. I still have a gag reflex when faced by some of its more arcane syntax, but I am fighting that. Then just when SQL was starting to win me over ...

The embedded SQL query I was building was a simple one. Just a straight SELECT with a simple WHERE clause. In the past I've often done such trivial retrievals with a SELECT * into a DS defined by referencing the external file definition. But while I was building this particular one I found myself hearing the voice of IBM's Mike Cain telling me not to waste time retrieving data I didn't need. OK, I thought, I'll be a good boy and SELECT just the columns I need and specify them in the DS--how hard can it be?

Problem was I didn't get the DS right. I was tired and simply reversed a couple of fields. As a result the values I was seeing made no sense. Now I could swear that when I've done something foolish like that in the past the SQL pre-compiler berated me and told me that the structure was not usable. Not this time. Not a word--even though one of the fields was alpha and the other numeric. It seems to me that changes made in SQL in general, and the pre-compiler in particular, in recent years have allowed it to do a lot of implicit casting between different data types. I can only conclude that in that light IBM has relaxed the validation rules. Either that or my brain has gone completely to mush and I am mismembering the "olden days."

I was clearly having a bad day as I also accidentaly discovered that the pre-compiler doesn't issue an error if you specify a column name in a SELECT clause that doesn't even exist in the table in question. The result is an SQL 42703 error at runtime. At least the error message was explicit about the cause of the problem. Maybe I've never made that mistake before, but it really surprised me that the pre-compiler didn't catch it, particularly since earlier it had failed a compile because the table in question was not found in the library list.

What's the point of all this? Other than to demonstrate my own apparent incompetence? Basically I want to warn others not to make too many assumptions about what potential problems the pre-compiler will or will not diagnose. Sometimes our dear old RPG compiler spoils us and lulls us into a false sense of security!

What We Are Thankful For

We live in Canada and consequently our Thanksgiving was in a few weeks ago. However, as in most years, we were working in the U.S. that day, so we tend to celebrate in November. So as we near the Thanksgiving celebration, our thoughts turn to things we are particularly thankful for.

We have many personal things we are thankful for. These include our health (including our wonderful Canadian healthcare system), our families (including four exceptional grandchildren), our home (which we sometimes wish we could spend more time in than we do), and many more things that we could go on for hours listing. We are truly blessed.

But in this post, we thought we'd concentrate on those things related to our work with IBM i that we're particularly thankful for.

First of all, we're grateful to still have work and a good income, despite the state of the economy. We know many who are not so fortunate. Many IBM i shops seem to have decided that an uncertain economy is a good time to exploit their investment in existing applications by moving them forward, enhancing their applications' value and the developers' productivity. That just happens to be our specialty, so it has worked out well for us.

We're grateful that the developers of our favorite programming language--RPG--have never even considered resting on their laurels. They could have simply cashed in on the maintenance revenue stream for applications running the businesses of thousands of companies worldwide. Instead, they have continually made the language more modern (/Free, data structure enhancements), more powerful (native XML processing, enhanced file handling), and especially recently, more easily expandable (via RPG Open Access or OA--more on OA in a moment)

We thank our lucky stars every day for RSE (the toolset currently packaged in RDP, earlier in RDi and WDSC). It's almost painful to recall our days of SEU development, with DSPFFD to get externally described field names and spooled compiler listings to find compile errors (shudder!).

And we're delighted that Rochester has given us a new friend to play with by embracing PHP on our favorite platform. If nothing else, PHP allows us to breathe a sigh of relief that we don't have to keep beating our heads against the Java brick wall. PHP gives us another option for a modern, browser-oriented language environment that lets us use OO to the extent we choose and offers an amazing wealth of open-source tools and applications. All with relatively simple integration to RPG applications and IBM i function. And best of all, it makes sense to those of us with RPG brains.

We said we'd come back to RPG OA. That's simply so that we can remind you that it was about a year ago that we made a plea for rational thought (pun intended) to prevail related to the Ts and Cs for OA. We have seen some progress. A trial version is available, at last. But we're still waiting for the true solution that we still hope will come--OA support to be included free-of-charge with either the OS or the RPG compiler. We have read rumors to the effect that we may not have much longer to wait for this. It would make a really nice present to find wrapped up under our Christmas tree!

Most of all, we're simply thankful to have had the opportunity to make a career working on the best platform on the planet for business applications.

Last, but by no means least, we're very thankful to all the readers of this blog. When the IBM Systems Magazine folks asked us to begin writing this some years ago, our first reaction was "but who would want to read what we have to say every week?"  Well, apparently, quite a few of you would. We're gratified and humbled at the number of you reading our weekly posts. Thank you all.

And a very happy Thanksgiving to all--whether in the USA or elsewhere--we all have a lot to be thankful for.

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!

The Law of Unintended Consequences

Most often when we hear this term we tend to think in terms of negatives--for example the havoc wrought in Australia by the artificial introduction of cane toads and rabbits. But as Wikipedia points out  "unintended consequences" can also include benefits. Artificial reefs,and reduced crime rates are just two of the examples cited. Positive unexpected benefits also arise from "fortuitous accidents" such as those that resulted in the invention of Penicillin and Post-it notes. So it is from time to time with RPG.

The ability to call C-style APIs from RPG, for instance, has opened up an incredible range of options for RPG programmers. Sending email, Web programming, Web services, etc., are all examples of the way in which this accidental "feature" has been applied. Indeed, had it not been for the success of this ability, IBM might not have felt inspired to add V5R1's Java interfaces--a capability that opened the door to creating and updating Excel spreadsheets, to name just one.

Now IBM i 7.1 has bought us another such "feature," which we confess we completely failed to notice when we first wrote about it back in April 2010. What is this mystery capability that escaped our notice for 12 months? The answer is the RTNPARM option on the return value for subprocedures. This was developed by IBM as a means of improving the performance of subprocedures that return large values. We won't explain it in detail here. You can click on the link and read about it if you want to know more (go ahead--we'll wait.) In essence what happens is that when you specify the RTNPARM option, although in your RPG code the caller just treats the return value normally (i.e., it assigns it to a variable, tests it, etc.). under the covers, the return value is actually passed as the first parameter.

So far, so good. So what's the surprise? Well it turns out that this solves a long-standing problem that many RPGers encounter when trying to call RPG subprocedures from Java or PHP or when trying to use RPG subprocedures as Stored Procedures.

The PHP/Java problem is that the RPG call toolkit interface only supports the return of a 4 byte integer (a 10i), which means that a subprocedure that returns any other kind of value (i.e., 99.9 percent of them) cannot be called directly from such interfaces. The Stored Procedure problem was even more restrictive--no return values from subprocedures were supported at all. In both cases, enterprising RPGers have been wrappering their subprocedures to convert the return value to a parameter to handle both situations. Alternatively, the stored procedure situation can be resolved by creating a user defined function instead.

A customer recently asked us if the new open source interface toolkit that Zend is starting to use would get round these limitations as he had many, many subprocedures that he wanted to use from PHP and didn't want to have to wrapper them all to be able to use them. It turns out that the new open source toolkit does indeed remove this limitation, but that doesn't directly help Java and SQL users. And that was when the lightbulb went on. If RTNPARM does a "return value to parm" conversion under the covers, then wouldn't it work as a means of getting round the toolbox interface limitations? Turns out that it does. Yeeeee haaaaa!

So, if you have RPG subprocedures that you want to use as stored procedures or call from Java without having to wrapper them, then once you get to IBM i 7.1, RPG's RTNPARM will do the job for you. It even generates the appropriate PCML file. What more could you ask?

Aren't "unintended consequences" wonderful?


P.S. We've mentioned before that one of the things we like about PHP is that it allows us to write procedural code, which for us RPGers feels like "home"--but we are still able to take advantage of OPO (Other People's Objects). Well Zend's Mike Pavlak recently showed us a website that we had previously missed and it is a great resource for locating such objects--phpclasses.org. The site also seems to have some good tutorials and other useful stuff. Check it out for yourself and let us know if you come upon any other useful PHP or RPG oriented Web sites that we may have missed.  

OA and PHP News

We were both delighted and saddened to see Profound Logic announced at COMMON that they will be reselling IBM Rational's Open Access: RPG Edition (OA) along with their own Profound UI tooling. Delighted because it will make it easier for the folks buying Profound UI to get their hands on the OA product. Saddened, though, by realizing this means it's apparently easier for an ISV to go through the process of signing up to be a reseller (no easy task) than it was for them to try to explain to their perspective customers how to buy it!

You could sense Profound CEO Alex Roytman's frustration in the announcement. For sure he's not doing it for the money, how much can you make on a product that typically sells for less than $2,000. This notion was cemented in our minds by his comment that he still believes the product should simply be delivered free as part of the OS.

We had really hoped by now IBM would have relented and abandoned this pricing silliness, or at least come up with a free trial version, or failing that at least made it simpler to order ... but no. Here we are more than a year after OA's introduction and apparently nothing has changed. Our friend Aaron Bartell can bear witness to that having recently risked his sanity and once again braved the waters in an attempt to order it.

Dear IBM: We love you dearly, but do you have to make it this hard?

On an altogether happier note ...

We appear to be approaching the formal launch of the new IBM i toolkit. By all accounts it will not only improve the capabilities and performance of our PHP applications, but will also herald a revolutionary departure from the IBM norm in two other ways. First, the new toolkit is open source, and second it is RPG-based. Seriously ... for real! The toolkit is being jointly developed by IBM, Zend, and members of the RPG community. Like the EasyCom toolkit that Zend currently delivers, and which it will ultimately replace, this new offering allows for program and procedure calls, access to system resources such as spool files, data queues, etc.

As if the news that the new tools would be coded in RPG wasn't enough, we also understand the performance is significantly improved (it certainly appeared so in the short test drive we had) and the subprocedure call mechanism now allows for return values--real ones--not just the four byte integers currently supported. No longer will you need to rewrite or wrapper subprocedures for reuse on the Web. That's certainly good news as it's been a source of frustration for us and many others who used the PHP or Java toolkits.

Since the community will be able to contribute to this new offering, it will be interesting to see how it evolves. Another point we should note is that it isn't just intended for use by PHP. The underlying mechanisms will be usable from any platform, or indeed between IBM i systems. We're really looking forward to having a chance to play with this new toy and will report back on our findings.

An Update From the Road

Thanks to those who wrote agreeing with us that there's nothing as good as teaching others to cement your own understanding. To Dan: keep working at it; yo'd be amazed at how often we discover a better way to do things when our own "pet" method is challenged by a student. To be honest, we wondered how that post would be received in the light of a discussion that has been going on in one of the PHP groups at LinkedIn. The thread is entitled "Should you teach your co-workers your skill-set?" and we found the responses of some members rather disturbing. Talk about being protective of one's skills! Glad to see that i folks don't seem to think that way. It was particularly surprising considering how much sharing normally occurs in the PHP world.

Right now we're in Manchester, UK, for the Powershift conference, and have just heard some good news. They've just announced that NiSUG (Northern i Series User group) has joined COMMON Europe as the UK representative and will now be known as the National i Series User Group. Good to see that COMMON will once again be represented in the UK. The group has formed many strong alliances within the UK over the years and this can only be seen as good news for friends of the i.

While on the subject of the UK: you don't have to be here long to realize how lucky we are in North America in terms of the cost of Internet access. Six pounds to connect from the hotel for 90 minutes. That's about US $10. Free Internet in hotels hasn't caught on here, except in some of the very inexpensive hotels along the freeway, although we do see it increasingly in restaurants and pubs, so hotels can't be far behind. Luckily, compared with North America, 3G data plans for phones and USB sticks are much more reasonable. Two pounds for unlimited use for a day is a far better deal than the hotel connections.

Once we leave here we're headed for France ... maybe. The protests in France over the government proposal to raise the retirement age to 62 (yes, 62!) are threatening to derail our plans. Literally, since we're due to travel to France by train!

Once more thing before we go. We noticed last week Asna became the latest company to announce support for Open Access for RPG. Wings is the name of the new product and since Ansa is here at the conference we hope to have a chance to see what it offers. Welcome to the club, Asna!