For some time now, AS/400 developers have been using the APIs in Client Access to create a communications mechanism for their client server applications. This method made a lot of sense for developers, as it eliminated the need to create or use third-party middleware that would do the same thing. The only problem with this model was that Client Access hadn’t been adopted by the entire midrange market. Instead, a slew of emulation and connectivity tools hit the market and blurred the choices facing most AS/400 shops, as many settled on RUMBA, WRQ’s Reflection and the like while spurning Client Access and its emulator, PC5250. Combine these market forces with the overhead associated with the APIs, and you’ll realize why Client Access was locked into a no-win scenario. Right?
Wrong. Alert developers who were already developing software based on these APIs got a glimpse of IBM’s long-term goal when they read about Operations Navigator. When IBM released OpsNav several years ago, I think it’s fair to say that most AS/400 sites didn’t give it a second thought. It wasn’t so much that a GUI for viewing spool files wasn’t going to be nice to have, it just certainly wasn’t earthshaking. It was clear, though, that IBM finally had a single place where it could tie all OS/400 functions together in a graphical Explorer-like interface.
Rochester likewise trimmed down Client Access to Client Access Express, allowing OpsNav to communicate with the host that much faster. Indeed, as long as IBM standardizes on OpsNav, it doesn’t even make sense for third-party tools that work with OS/400 to consider using their own middleware, since that is exactly what Client Access Express has become for OpsNav. To make it even more enticing, IBM gives OpsNav away as a free component of Client Access Express, making it a no-excuses reason to begin using it. The same is true for using Client Access Express as middleware—you install the free components (OpsNav and/or ODBC), and you’ll have all of the communication engine APIs at your disposal.
Some interesting scenarios result from the OpsNav initiative. The third-party emulators that were once so popular stand to lose the most in this brave new world. Since IBM made OpsNav a free part of Client Access Express, it can be installed anywhere, including on PCs that have another emulator already running. In the short term, these emulation companies cannot create software that is competitive with OpsNav, so many people will wind up using everything (including emulation) within Client Access Express.
In the long term, 5250 emulation will become a thing of the past, and OpsNav and Client Access Express will then truly be one product.
You may be wondering why this connection exists—why wasn’t OpsNav developed on its own without this dependence on Client Access? First, you must remember that OpsNav development was begun years ago, and IBM correctly assessed that Client Access already had 70 to 80 percent market penetration. Since the APIs had already been developed, using them was the path of least resistance for the OpsNav team. The software was created using C++ (Java wasn’t in vogue then), and eventually IBM encouraged other developers to create their own plug-in software.
Now that IBM has begun writing enhancements in Java, one might assume that OpsNav will ultimately be used anywhere, whether Client Access Express is installed or not. The truth is that there are over 2 million lines of C++ code that OpsNav is based on, and it all depends on Client Access Express APIs. It would take years for IBM to rewrite this in Java, and IBM is surely asking itself: to what end? OpsNav is based on the look and feel of Microsoft Windows, and I don’t see many people throwing away their PCs any time soon. These two companion products are here to stay in their current environment, and the goal is the advancement of Operations Navigator.
LATEST COMMENTS
MC Press Online