XML Fixes; WebSphere sMash

Two completely unrelated tidbits this week.

First, as a follow up to our previous blog entry on issues with RPG's XML support bombs.html, there is news this week of another PTF related to XML support. This one fixes a couple of shortcomings in XML-INTO support. Unfortunately it is only available for the 6.1 release, but that's a lot better than nothing. The new support helps in two problem areas. The first is in cases where a element contains both data and attributes:

<Customer type="retail">Smith and Company</Customer>

Until now, XML-INTO was unable to handle this situation and you had to play "silly games" to access both.

The second problem area addressed by this PTF concerns the handling of nested elements that repeat a variable number of times. Currently if you specify the related array as (say) Dim(50), then a run-time error occurs if less than 50 nested elements are present. The only cure for this has been to specify the %XML option "allowmissing=yes". The problem with this is that it doesn't allow you to specify what is allowed to be missing and therefore allows anything to be missing, so it is a bit of a blunt weapon.

We'll be digging into these new options in more detail in our next IBM i EXTRA article (click here to subscribe), but if you can't wait for that, more detail can be found on IBM's RPG Cafe

It's a sMash!

Another thing that piqued our interest this week was WebSphere sMash. IBM describes sMash as, "A development and execution platform for quickly building agile, web-based applications." but since we encountered it in a PHP publication, it was that aspect that intrigued us. In our minds (and we suspect yours too) we equate WebSphere with Java--so the notion of WebSphere embracing PHP was an interesting one. Turns out that sMash supports applications written in both PHP and Groovy (a dynamic scripting language like PHP, but designed to exploit existing Java skills). Not only does sMash support
the two languages, it allows them to intermix just as IBM i allows intermixing of RPG, CL and COBOL. sMash has evolved out of Project Zero--IBM's first foray into what they term a "public incubator," which remains the development base for the project. This is not your father's IBM!

In addition to further cementing PHP as a major player in the enterprise, sMash has also contributed directly to its current and future health. How? Well this particular PHP implementation wasn’t based on the Zend engine as are most others, including our own IBM i implementation. Rather it was rewritten completely in--you guessed it--Java! During testing of this new implementation, several behavioral differences with the current PHP standard implementation were encountered. Since many of these
behaviors weren’t covered by existing PHP test cases, sMash developed many hundreds of new tests, which were subsequently contributed to the PHP test bucket. Isn't symbiosis wonderful!

Once we've had a chance to download sMash and give it a bit of a test drive we'll report back on what we find. We'd been intending to investigate Groovy anyway, so this is an added incentive to do that.

One last thing before we go. We're speaking at the WMCPA spring conference in Delavan, Wis., this week and at NEUGC in Framingham, Mass., next week, followed by our own RPG & DB2 Summit event in Orlando, Fla., the following week. If you’re attending any of these events, drop by and say hi. If you're not currently planning to attend, please consider doing so.      

Avoiding XML BOMbs

We're finding that more and more of our customers are generating and processing XML files on a daily basis. As a result we find more and more questions arriving in our mailboxes. Most we can deal with, but a recent one had us stumped for a while. The problem was that the files received were in UTF-8 format and contained a Byte Order Marker (BOM) in the first three character positions. (If you don't know what a BOM is "Just Google it"; we won't take the time to explain it here.) As a result, any attempt to process the file using RPG's XML-INTO or XML-SAX failed immediately with the program issuing the error message "The XML parser detected error code 302." When you look this error message up, it means that the file did not begin with a "<" character. Duh, well we knew that, but the XML definition said it was OK so ...

We spent some time on Google but didn't find anything that seemed to be related, so in the end we finally resorted to contacting IBMer Barbara Morris, who is on the compiler team. Barbara told us that PTFs were actually available to resolve this issue (they're listed at the end of this entry for those that need them). The PTFs change the way the system handles such files so that the BOM is ignored and the program never sees it.

So, we installed the appropriate PTF, waited until after the next IPL, and then tested the program again. No difference. Hmmmmm. Then it struck us that perhaps the file wasn't defined with a UTF-8 Coded Character Set ID (CCSID). If that were the case then we could hardly expect the operating system to handle the BOM correctly--fix or no fix. A quick WRKLNK and option 8 to display the file's attributes confirmed the diagnosis--the file was using CCSID 819! Because UTF-8 is effectively an ASCII format (as is 819)--a simple CHGATR command (CHGATR OBJ('/partner400/Filename.xml') ATR(*CCSID) VALUE(1208) ) did the trick. We didn't even have to rerun the test program to confirm that the fix worked.  Just taking option 5 was enough to see that the BOM characters had "disappeared." Running the test program confirmed that all was well.

It seems to us that a lot of this could have been avoided if IBM had used a slightly more useful title for the APAR/PTF. If you were looking for a fix to a BOM problem would you have drilled down into a Google hit that showed the title "XLATEMB UNICODE TO NON-UNICODE CONVERSION"? We didn't--and neither did the customer. If IBM had simply included "BOM" in the title, we could all have saved a lot of time. So please IBM, a little more thought in creating the titles for APARs would make life a lot easier for your customers.

We promised the PTFs, so here they are. Many (all?) may have been superseded by now, but these are the starting point. Depending on which release you are currently using you need one of the following:

V5R4:      MF45480
V5R4M5:      MF45502
V6R1/6.1: MF45479

If you have not yet embarked on the XML path, you might want to start with these articles:

Generating XML from RPG Programs the Easy Way
Processing XML with RPG and the follow up piece.

Hope you find this information helpful!