When I was at COMMON in Anaheim in the fall of ’98, I asked an IBMer what the future of OfficeVision/400 was going to be. When she told me that OV/400 would be “phased out” in another couple of releases of OS/400, I wasn’t surprised. It did make me wonder, however, just what all those AS/400 users who depend on OV/400 to get their jobs done were going to do. When I asked the person from IBM what was to become of all those folks, she said, “Our recommended path will be to move them to Domino.”

That answer left me with a lot of unanswered questions, not the least of which was, “What are users supposed to do about the tens of thousands of documents they defined in OV/400 and use every day?” After all, Domino doesn’t have any kind of native word processing functionality.

Over the last year and a half, IBM has been dancing around this issue and has not given any real answers. There are many reasons for this, but I think it’s mostly because IBM wanted to downplay all the potential work that awaited OV/400 users and avoid public acknowledgment that it had made such a huge blunder. After all, why on earth would a company dump a product that was so integral to the way of life of such a large portion of its users? What was IBM thinking? IBM had already irritated the IS user community beyond belief when it forced users to migrate from CISC to RISC, but at least that decision wasn’t political. Moving from 32-bit to 64-bit architecture made good technological sense.

But the reasons for junking OV/400 were more financial than technical. IBM spent a considerable amount of money when it purchased Lotus Development
Corporation—money that can be recouped only by pushing AS/400 users (and everyone else) to Domino. By dropping support for OV/400, IBM appeared not to care about how much work it was making for hundreds of thousands of OV/400 users.

A Lot of Work

IBM didn’t provide a solution for migrating the tens of thousands of documents those users had created to a new platform, either. In fact, it pretty much ignored the whole issue altogether for the better part of a year. When IBM did finally acknowledge the migration problem, the solutions it offered were less than ideal and involved a considerable amount of work on the part of IS staff to migrate OV/400 documents to alternate formats other word processors could use. What’s more, none of the recommended solutions could offer even a third of the functionality found in OV/400, such as data merges. This meant a lot of extra

work for IS shops in getting those documents converted. I don’t know about you, but if I worked in a shop that had 800 form letters, 2,500 user-defined documents, multiple application help-text documents, and thousands of mailing labels, all defined in OV/400,
I’d be really upset by the prospect of all that work awaiting me.

Data Text Merge

Well, take heart. A product that should be available by the time you read this is a light at the end of a dark and dreary tunnel. Called Data/Text Merge (DTM), this new product from Inventive Designers (www.inventivedesigners.be/), makers of EverGreen/400, will allow you to move your users from the now-defunct OV/400 with absolutely no extra effort on your part! Pretty much every capability that you have in OV/400, including the Print Document (PRTDOC) and Merge Document (MRGDOC) commands and the four main document merge types (Direct Merge, Multiple Letters Merge, Column List Merge, and Dependent Column List Merge), are all supported. In fact, as of this writing, more than 80 percent of OV/400 features are supported, with the remaining 20 percent expected to be supported in future releases.

Beyond just supporting what already exists in OV/400, though, DTM is positioned to be ready for whatever the future brings. DTM, written in ILE C, fully supports the new Extensible Markup Language (XML) standard. XML is defined by the World Wide Web Consortium (W3C) and is supported by a large number of companies, including IBM, Sun Microsystems, and Microsoft.

It’s also quickly becoming the de facto standard for all data presentation technologies. This support provides assurance that the technology behind DTM will continue to exist far into the future, because DTM uses XML as its basic architecture.

This also means that, right now, DTM not only supports your existing OV/400 document types, such as RFTAS400 and RFTDCA, but also can easily convert them to other common document types, such as Rich Text Format (RTF), XML, and HTML. So, using OV/400 documents in products such as Microsoft Word or Corel WordPerfect will be a breeze.

What It Means for You

So what does DTM mean to your company? It means that you have available to you a product that almost completely replaces OV/400 with little or no additional work on your part. The interface looks amazingly like OV/400, too, so your users will be able to move from one product to another with a minimum of fuss. DTM also supports Domino on the AS/400, so if you are moving to Domino, you can still use your OV/400 documents with it.

If you are an OV/400 shop, you owe it to yourself to look into this product. It could potentially save you and your staff hundreds, if not thousands, of hours of work. Look for an in-depth review of DTM in MC’s sister publication, AS/400 Technology SHOWCASE, in the spring of 2000.

Shannon O'Donnell has held a variety of positions, most of them as a consultant, in dozens of industries. This breadth of experience gives him insight into multiple aspects of how the AS/400 is used in the real world. Shannon continues to work as a consultant. He is an IBM Certified Professional--AS/400 RPG Programmer and the author of an industry-leading certification test for RPG IV programmers available from ReviewNet.net.