User Groups Remain Vital

Last week we were speaking at the annual OMNI User Group event in Chicago. In common with other groups around the country OMNI is experimenting with different locations and styles of events in order to help lower their prices and (hopefully) attract more attendees. This year the event was held at the IBM facility in Schaumburg, a very different location from the more usual hotel or convention center. Judging from the attendance though it seems to have worked. We understand attendance was higher than in previous years and our sessions were all very well attended. We were also delighted to see that IBM i's chief architect Steve Will attracted a good crowd for his keynote session at the end of the day.

As usual Steve did a great job, and the IBM i success stories he relayed were heartening to the faithful. One rather sad note in his presentation was his comment as to how hard it is to get companies to agree to allow IBM to use their names. Not just as references, but at all! Why? Because IBM i is their competitive advantage. They know their competitors are wasting millions of dollars trying to get other systems up to the level of capability, reliability and affordability IBM i offers them. Why on earth would they want to share that information with them?

On the Subject of User Groups

Tomorrow (Wednesday 26th), we are partnering with the good folks at TUG in Toronto to offer a one-day mini-Summit event. Two tracks of RPG-oriented sessions will be coupled with a lunch time "chat" with the RPG compiler's lead architect Barbara Morris. TUG has always been at the forefront of providing innovative educational offerings to members. The group already offers low-cost night school classes to help members bring their skills up to date. This is the latest and it looks from the number of people registered as if it will be successful and hopefully the first of many.

OMNI and TUG are just two examples of vibrant local IBM i user groups. They are certainly not alone. This year we've already worked with WMCPA, the Wisconsin area group, NEUGC, the northeast user group consortium, OCEAN user group in southern California and AMCU in Atlanta, as well as the Fort Wayne user group.  Sadly, we have also heard of local user groups that continue to struggle to stay afloat and some that have lost the struggle.

Local user groups can be a valuable way to keep abreast of both local business trends as well as IBM i technical information and networking with IBM i peers. Online resources are great but can never replace the face-to-face interaction with fellow i fans.

We've said it before and hate to sound like a broken record. But if you don't participate in your local user group, you should. If they aren't offering the kinds of topics or activities you need, contact them and tell them what you need. And if you don't have a local user group in your area, maybe it's time to start one. There are people who can help. You could begin by starting a conversation on the subject here on our blog or on the InterLUG mailing list run by David Gibbs.

IBM Mobile Database Syncs with DB2 on IBM i

Following our recent blog post on mobile computing and IBM i, we were contacted by our old friend George Farr. As some of you may know, George moved out of the IBM i Rational team a while back--remember the letters "IBM"stand for "I've Been Moved"--and joined the DB2 team. He's now the product manager for DB2 on mobile devices.

Luckily for us, George hasn't forgotten his roots and wrote to tell us that he had made sure that his first new product (IBM Mobile Database) would sync with DB2 on IBM i. The product is free of charge and allows you to sync to both DB2 and Informix databases. The product is part of the "IBM solidDB" family and you can find the details on this page. If you want to just jump into the details try this link. We had a lot of trouble finding these documents, but it turns out the trick is to Google with the following: "IBM Mobile Database" site:ibm.com. Note the quote marks and the "site:" part. Without those you'll get a lot of hits but nothing terribly useful! To download go to this Web page. You'll notice on the right-hand side a download link for the binary and for a sample development set-up for Eclipse. Hopefully one of our friends that works with Android will give this thing a try and get back to us with a report. Aaron Bartell are you listening?

We've also been thinking a lot about database administration of late. Several of our clients now have really huge amounts of data and are beginning to wonder if they need a dedicated DBA. We started off intending to write a blog comment on the topic, but it turned out there was a lot more to say than could really be accommodated in a blog entry, so instead you'll find it in an article in the most recent edition of the magazine's IBM i Extra e-newsletter.

Another History Lesson: Sorting the Basics

Before the actual post begins, a very happy, but belated, Programmer's Day to everyone! Programmer's Day is the 256th day of the year (of course!).

This week's blog was written by Jon (with American punctuation and spelling contributions by Susan) for reasons that will soon be obvious.

Last night I was busily coding my brains out on a new RPG Open Access handler and needed to use RPG's good old SortA op-code. That got me thinking about sorting in general and the fact that many of today's RPG programmers probably don't understand the mechanics behind sorting. In fact I find that many of today's programmers don't understand the underpinnings of much of what goes on behind their code, but we'll get back to that later. In the meantime, we needed a topic for this week's blog and so ...

For me it all began a long time ago on a different planet, well--at least in a  different country. As a beginning IT pro I started out in the world of punch cards which was how all data entry was handled at my first job. In fact all data storage was in the form of punch cards. Customer addresses, account balances, invoice line items were all on punch cards. At the time a few systems around used magnetic tape as the primary storage media but they were reserved for large systems used by banks and large manufacturing companies. A few disk systems were also around, but their capacity and cost meant that all but the biggest shops used them primarily for the operating system, program storage and work files for use during processing.

Needless to say as the junior in the department I got all of the jobs the senior staff didn't like doing. As a result one of my earliest duties was to be responsible for sorting the cards into the order needed for processing. For example, to take all of the batches of transactions that had been accumulated during the week and sort them into customer number and invoice number order so that a weekly customer sales report could be produced and a summary card produced for each invoice. The card sorter in our shop ran at 750 cards per minute (cpm). That was scary fast considering that you were expected to be able to add cards to the input hopper and extract them from the output hoppers all without stopping the machine. It took me a week or three to get the hang of doing that without jamming the machine and wrecking a bunch of cards. At 750 cpm you could mess up quite a few before the sensors registered the jam!

So how did mechanical sorting work? Well, let's take a customer number as an example. A heap of cards was placed in the input hopper and the column selector (yes you could only work on one column at a time) was set to the right-hand position of the number (i.e., the least significant digit). Once the start button was pushed, the cards shot though the machine and dropped into the relevant hoppers 0 through 9. You then gathered the cards carefully in order and placed them once again in the input hopper, being careful to ensure that all the 0s went first followed by the 1s, 2s, etc. By preserving the groupings like this you ensured that this time the cards in the 0 hopper were in themselves in sequence 00s, 01s, 02s, and so on. This continued until the entire customer number had been processed at which point the cards were in sequence. Or at least that was the theory. Since we were dealing with mechanical processes it was not unheard of for a card to be mis-selected and end up in the wrong hopper. So the next task was to take the cards to the collator and run a sequence check, manually correcting any issues found. Finally the cards were ready for processing and my part of the job was done.

Interestingly, I have found uses for this basic knowledge in other areas over the years. On one occasion a customer had to provide the auditors with the original customer order slips for specific invoices (most auditors didn't trust these "new-fangled" computer systems). There were thousands of them, just in boxes by the month. It seemed like it was going to be a lot of work, but we applied the same sorting process to them, grouping by first the last digit, then the next, and so on until they were in sequence. then we just handed the boxes to the auditors and told them to help themselves to whatever they wanted.

Of course modern memory-based sorting methods don't work exactly the same way, but I still feel that my knowledge of the fundamentals is helpful. A knowledge of punch card coding helped me understand the structure of coding systems like EBCDIC and ASCII. That in turn helped me to appreciate systems like DBCS and UCS--not to mention being able to derive easily memorized wifi passwords--well, they are easy for me to remember anyway!

I really hope that devices like the Raspberry Pi, which we blogged about earlier, will help more people get involved in the fundamentals again. That reminds me--we just got our notification that we can order ours--must remember to do that.

 

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.