Connecting COBOL through XML
6.5 users give patches cold shoulder

Community crafts XML expertise

On the very day we posted our story about a new third party solution for COBOL-to-XML on the 3000, a customer posed a problem that would require that solution. Or a few others for the do-it-yourself shop, if your HP 3000 budget has been reduced.

"There's some companies that need the exchange of information with our HP 3000, and they are asking us to send/receive XML files for their transactions," said Eduardo Garcia. Several experienced managers offered a mini-clinic on how to handle this format and what XML offers.

"XML is not magic," said Mark Wonsil of 4M-Enterprises. "It’s just ASCII. It is a method to markup documents that has been commandeered to handle data, albeit in a less than efficient manner. MPE can create ASCII files and hence XML files. Your only real limitation is size."

Contradicting some user reports about HP 3000 integration difficulties, Wonsil said that standards for XML make it an able tool to use under MPE/iX.

"Others have chimed in about 'integration' issues, such as different element names, but that is not directly related to XML or MPE," Wonsil. "The W3C recognized this issue and people use XSLT to transform element names today."

Computer services coordinator Eric Bender said XML drove the college off the 3000.

It was the absolute necessity for us to introduce an XML transfer  mechanism into our student records system by summer 2007 that finally tipped the balance in the decision-making process to migrate the system  off the HP.

Unfortunately, in my humble opinion, it’s the inability of the HP 3000/MPE environment to  easily be adjusted to innovation and new standards such as XML that will eventually sound its death-knell. The HP 3000 is increasingly coming to  resemble a very robust 80-year old — but in the early stages of dementia.

OpenMPE board member Matt Perdue, who pointed out our May 3 article on XML, disagreed with the dementia label for the 3000:

First, the HP3000/MPE environment does not have an inability to easily adjust to innovation and new standards — it is simply a question of what your management is willing to spend for either in-house or third party developed solutions. Witness the posting on The 3000 NewsWire [blog] about this very issue — a company has ported their XML enabling software to the 3000. It looks like that company’s management feels there is a market worth addressing and investing time (and therefore money) in selling to that market. It also looks like [former HP 3000 GM] Winston Prather’s statement of the “eroding ecosystem” has not been proven to be true: the ecosystem just grew by yet another third party offering.

Second, far from being a very robust 80-year old (it’s a robust 30-something year old) the 3000/MPE is very, very far from the early stages of dementia. I’d suggest the only dementia the 3000/MPE is suffering from is the dementia suffered by management and other individuals at various levels in various companies with regards to extracting every bit of value possible from the dollars spent — and the 3000/MPE has excelled at this for at least the last 25 years or so.

Mark Landin offered a review of the steps to use XML on the 3000, if you've got access to Perl expertise.

XML is just a file format, similar to HTML. You can open any XML file in, say, Notepad and pretty much figure out in just a few minutes. So, to start with, there is nothing “magical” about XML. The trick to XML is that the file describes itself. Part of the XML document you are sending or receiving includes a schema of sorts. That’s the powerful part of XML. XML-enabled applications are able to read this schema and therefore understand the rest of the document!

I don’t know about any specific packages for the 3000 that do XML data interchange, but I know you certainly whip something up in Perl. Perl runs fine on the 3000s, talks to IMAGE easily, and also has many toolsets that remove a lot of the drudgery of XML. The bonus is that if the company you are dealing with has defined their XML formats (which I’m sure they have), someone even moderately skilled with Perl could probably hack together what you needed. Perhaps someone has even written Perl code to handle this specific XML format for Windows applications. Since Perl runs on so many platforms, Windows Perl code often runs on the 3000 with a minimum of effort.

Of course, for this to work, you need to understand XML documents, and know Perl. But it really shouldn’t be that hard to find a contractor with those skills if you lack them in-house.

Comments