October 2014

PHP

March 06, 2014

We recently had an email from a fellow RDi user asking if we knew what had happened to the HTML editing capabilities that had been in WDSC. He had not needed to use them since switching to RDi and now needed to use them. The simple answer, sadly, is that when IBM made the move from WDSC to the RDx versions, the additional Web tooling was dropped from the base package. We blogged about it a while back. The tooling has always remained available but in the higher priced configurations of Rational Developer.

After further research to establish that nothing was available in the basic RDi tooling, we went in search of some Eclipse plugins. Our initial attempts were not very helpful as "HTML" as a keyword to search the Eclipse market brings up hundreds of options. Not only that, but as it happens RDi is not based on the latest-and-greatest version of Eclipse (Kepler), but on the previous version (Juno). This increased the difficulty of the search. Another challenge is that it wasn't immediately obvious to us which of the tools was free and which for-fee. So, we did what we often do under such circumstances and reached out to the RDi community on midrange.com to see what others were using.

Several people suggested that we install the Eclipse Web Tools Platform extension to give us both HTML and additional Java capabilities, so that's the direction we chose. But that still left the "How" part and although we have done this before, each version of Eclipse is a little different. That's when another suggestion from the RDi group helped out. This time they pointed us to the Useful Stuff blog, which provided step-by-step instructions with images for _exactly_ what we needed. We followed the instructions and it worked beautifully.

Of course it's always dangerous to let Jon lose on anything like this as he inevitably gets into "Ooo, that looks interesting" mode. This time he decided that while he was extending his workbench he should try adding some PHP support. He's been using both Zend Studio and the PHP version of NetBeans, but thought it would be nice to have a single IDE for those times when he's working on a project that uses PHP, HTML and RPG. Because Zend Studio is based on the Eclipse PHP Development Tools project (PDT), it would (or should) be a familiar environment and indeed that is the way it turned out. For those of you thinking of following in his footsteps, we offer one word of caution: To find the PHP tools you can filter for "PHP" (just as the Useful stuff blog suggested you filter for "Web" earlier,) but when you do, you'll see two sets of options. You do _not_ want the ones identified as SDK. Just pick the three items identified simply as PHP Development Tools (PDT) and all will be well.

Once we have had a chance to work a little more with these Web tools we'll report back. In the meantime if you find any other Eclipse projects that are useful for RDi users, please let us know. We are already familiar with those from SoftLanding and TaskForce's iSphere (which we hope to review soon) but are always happy to hear of others via the comments section.

November 07, 2013

At
conferences, during classes and often in our email there's one
statement/question that we get asked over and over: "I
know I've let my skills get rusty, I know there's a huge list of things I
should learn, but where do I start? It is all so overwhelming."

It
is a good question, but the answer is really quite simple. When faced with the
task of eating an elephant there is only one way to deal with it--one bite at
a time.

But
there's a problem with that basic premise. With an elephant, of course, there are
at least some obvious potential starting points. Nibble your way up from the
tail, or gnaw your way from the tip of the trunk, just for starters. With the
type of list most of the questioners are faced with, however, the choices are not
quite so obvious. SQL, XML, Web services, mobile apps, HTML, CSS, Javascript,
Ruby, etc. Where to start?

To
an extent it depends on where you are right now, and whether
your current job is steering you in a specific direction. Of course if the
latter is the case, the answer is probably a lot more obvious. By "where
you are right now" we are talking specifically talking about your RPG
skills. For example, if you have yet to embrace the use of subprocedures as a
way of life-- not just for reusable components but as a vehicle for structuring
your programs--then that is clearly an area that you need to address.

But
perhaps the choice is actually easier than that? We think we could make an argument
that your first step should be to learn a new language. After all, if you
haven't got your head around subprocedures yet then perhaps it is because, like
many others, you simply can't see the point. You've managed with subroutines
and dynamically called programs for years - why bother to change? Our good
friend George Farr often recounts that when people tell him how much they
enjoyed his "Java for RPG Programmers" book, he frequently asks if they are doing much Java programming. The answer is
invariably the same "No, but it made a huge difference to the way I code
RPG!"

Java
is, of course, a perfectly valid language to learn, as indeed are Ruby (now
available for IBM i) and Python among
others. But as we've stated many times, we still feel that PHP is the
best choice for most RPG programmers. Why? Because you can use it as a
procedural language and gently ease your way into object-oriented (OO) programming
without have to totally rewire your brain. We know that many reading this will
say that learning to program in OO is easy; why the big deal? We're happy for
you. We really are. But personally we have not found that to be the case. As
Jon has often publicly stated, "I consider myself to be a failed Java programmer."
He learned the syntax and can write and read Java code but doesn't _think_ in
OO terms. Slowly but surely PHP is helping to remedy that situation. It also also improved his RPG!

Regardless
of your choice of language, we want to make one clear cut recommendation. Sign up with Learnable. It is our go-to
resource for all new technologies. Learnable offer books and online classes in
everything from PHP to Ruby and HTML to Javascript and mobile app development.
At $29 a month (or $15 a month if you sign up for a year), it is a bargain
basement way to jump start your new skills. That membership gives you access to
their entire library plus the ability to download two books a month. Considering
most technical books are $40 and up that is worth the price alone. As a minimum
sign up for the mailing list where an introductory price of $99 per year is offered from time to time.

So, don't delay: take your first bite!

P.S., while researching the origin of the elephant idea we came upon Mikki's blog and
her post on this topic.
It has nothing to do with computers, but those of you who feel overwhelmed in your personal lives and professional lives may find it an interesting read.

October 22, 2013

Two inspirations for this week's blog. First at last week's RPG & DB2 Summit our introductory session on mobile computing drew one of the biggest audiences of the week. Then when digging through the mountains that pass for our inboxes after such events, we came upon the latest issue of PHP Architect magazine. Just by chance it included a number of mobile related statistics which made for interesting, and perhaps slightly scary reading. "Scary"? Yes, because they highlight the fact that if you are not already thinking mobile you're in grave danger of finding yourself in panic react mode any day now.

Here's just a few of the stats that gave us pause for thought:

Almost half a billion tablets will ship in 2013 and 2014 alone. (Source: Gartner)

That is _billion_--a simply staggering number!

Four out of five consumers use smartphones to shop. (Source: comScore)

60 percent of mobile shoppers use their smartphones while in a store and another 50 percent while on their way to a store (Source: Deloitte Digital)

When you take into account Google's stats, which suggest that 90 percent of people move between devices to accomplish a goal, whether that is on smartphones, PCs, tablets, or TV (Source: Google), you begin to see that mobile devices are rapidly becoming part of a continuum.

Work that is begun on a PC browser may well end up being completed on a mobile phone or tablet, perhaps while commuting. Admittedly many of these tasks will involve shopping and/or Facebook status reports, etc. But to think that the same kind of workflow requirements will not rapidly permeate the workplace is simply putting your head in the sand.

An indication of the potential impact is reflected in the statistic that 25.9 percent of all emails are opened on mobile phones, and 10.2 percent are opened on tablets. (Source: Knotice). Many of you may discount this as reflecting personal communications rather than business, but we think you'd be wrong. Our children and grandchildren have all but given up on email. They text, they Facebook, they. ... In fact whenever we send an email to our youngest son or our oldest granddaughter, we have to text them to tell them to check their email!

There were many other interesting stats included in PHP Architect's summary including the rather strange one that by the end of 2013, there will be more mobile devices on Earth than people, according to Cisco.

It seems to us that we all need to think about what mobile can do for (and to) us. What can it do "for" you? Well don't just wait for someone to come to you with a mobile app requirement. Instead you should take the initiative to show what you can do _before_ they ask. We talked about this in more detail in an earlier blog post titled "Surprise Someone!" because that's what we think you should do. The users may never think to come to you--the RPGers--for a modern mobile app. But you're in the best position to provide it. And, believe it or not, you can do it; it's probably much easier than you think. Better you surprise the users than management surprise you by telling you that you have no role to play in the new mobile world!

What can it do "to" you? Well bring your own device is fast becoming a reality for many businesses with all the compatibility and security issues that entails. The temptation to save money, and ignorance about the inherent security risks, will in many cases result in senior management dropping the potential for a really nasty mess into your laps. You need to be ready. And we don't just mean that you've made a decision about which 5250 emulator <shudder> you should supply to your users!

And talking of nasty messes--one final stat: 75 percent of Americans take their phones to the bathroom (Source: Digiday).

February 26, 2013

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.

September 04, 2012

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.

July 10, 2012

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?

February 21, 2012

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!

November 30, 2011

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!

November 23, 2011

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.

November 02, 2011

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!

IBM Systems Magazine is a trademark of International Business Machines Corporation. The editorial content of IBM Systems Magazine is placed on this website by MSP TechMedia under license from International Business Machines Corporation.