In the October 22, 2009, APIs by Example column, I present a homegrown version of the Additional Message Information panel. This panel lets you display and optionally reply to a message residing in a message queue, based on the qualified name of the message queue and the message key identifying the specific message to display. The usefulness of such a facility is prompted by the ability of some jobs and print APIs that return the name of the message queue assigned to a job or printer as well as the message key when the job or printer is currently waiting for a reply to a message.

Today, I present an example of how to use one of the aforementioned APIs in collaboration with my Additional Message Information panel, thereby providing a functionality similar to the one offered by many native IBM Job and Writer CL commands' list panels, including an option 7=Display message. Because I currently have no access to a system at release 6.1, which is required to take advantage of the Message wait message key information added to some of the Job APIs at that release, I decided to create a utility based on one of the Writer APIs, which for some time now has included this information. Say hello to the Work with LAN Writer (WRKLANWTR) command.

Programmers are notorious for their dislike of documenting code. (I'm no exception! Comments in code aren't too bad, but writing documentation for users?!) Nonetheless, we all have to do it, right? I know that in our shop, we need to create "run books" that explain step-by-step how a user is to perform a particular task, such as entering an order or adding a customer.

Written documentation works OK for plain-text screens. But it never works as well as demonstrating the process for the user, where he can see the screens as I'm typing the commands. With GUI software, being able to see the actual screens is even more important. For example, written software that has instructions like "click the doo-hickey that looks like a curly arrow" can be hard to follow.

Therefore, I'm proclaiming that the age of video documentation has officially begun! With video documentation, you can easily create a step-by-step tutorial for your users and show them exactly what the screens look like, and they can watch it anytime. Best of all, it's free!

Q: We've been using your "Excel from RPG" stuff, and love it. But I've been unable to figure out a way to lock cells in a spreadsheet with POI! We're generating a form in which users can fill in some fields, but we don't want them to change others. How can we lock the cells against changes?

A: Locking cells in HSSF is easier than you might think. You first have to protect the sheet by calling the protectSheet() method of the HSSFSheet class and assigning a password that will be needed to unlock the sheet from within Excel. Once you've done that, call the setLocked() method for each cell style used in the sheet. For the cells you want to be locked, you have to create separate cell styles from the ones for the cells you want unlocked.

Last year, I published several special RPG & DB2 Summit podcasts in which experts from the RPG & DB2 Summit conference discussed some of the hot issues that today's IBM i programmers face. Because these podcasts were very popular, we've decided to do it again!

This podcast features Paul Tuohy interviewing Susan Gantner about using MySQL on i. Since we have our familiar integrated DB2 database, why would we ever want to use MySQL on i? To the IBM i faithful, is MySQL a blessing, or is it heresy?

*Listen to the podcast...