As IBM readies Unity for the Windows 95/NT beta release, a question needs to be raised by Client Access professionals: What’s in it for me? No serious look at Client Access/400 could be complete without a critique of Unity.

A couple of years ago, rumors started filtering down that Rochester was working on a new front-end for the AS/400. The idea, according to the rumors, was to eliminate the old non-programmable terminal interface entirely and to build up a single elegant GUI for all OS/400 tasks. This project, according to rumors, even had a code name: Project Unity.

In the meantime, a lot of us who have been waiting for the Client Access Win95/NT client have been in a quandary. Was Unity going to be a part of Client Access Win95/NT client? If so, the beta code we were being fed by IBM seemed pretty anemic. For instance, last issue we reviewed the System Object Access (SOA) module of the Client Access Win95 client. SOA is an interesting product. It provides a GUI for the operational tasks of the AS/400. But—when you dig beneath the surface—SOA is not much more than a screen-scraper. Was this what Project Unity was all about?

Well, now it seems that Unity does officially exist at Rochester, and the project is finally coming to Client Access Win95/NT client beta. Many of the questions that have nagged us are being answered. IBM has even put screen camera captures on its Web site to show us how Unity works.

So what does Unity look like? How is it different than the current GUIs in Client Access Win95/NT client beta? All of these are interesting questions that—in a very real sense—highlight the problems that all of us face as we develop real AS/400 Client Access applications. Let’s look at Project Unity from this perspective—what will Unity teach us about moving applications to a real Client Access environment.

Unity’s Explorer Interface

The first thing you’ll notice about Unity is the Win95 Explorer metaphor. (See Figure 1: Unity Profile Manager.) That is, Unity starts out with a two-paneled representation of AS/400 services displayed in a hierarchy. As you click on the icons within the hierarchy, you are led deeper into the structure of OS/400. For instance, in Figure 1 there are eight sets of services listed under the icon representing a Boston AS/400: Database, File Systems, Jobs, Messages, Output, Printers, System, and Users. If you click on the System icon, you’re led to a second hierarchy: Alerts, Authorization Lists, Hardware Inventory, Problems, Software Inventory, and System Policies. Click System Policies and you continue your journey.

On the surface, this hierarchy may appear to be no more than a new analogy for old AS/400 branching menus. But this isn’t the case at all. A menu is really more akin to an HTML page of URLs than an Explorer hierarchy; the links within a menu have no inherent structure, and can in fact be self-referencing. However, a Win95 Explorer hierarchy provides a single, structured representation of every service available to Unity, and represents everything within that structure as an object that can be manipulated.

If you stop to think about this difference in approaches, the organizational task that faced the developers of Unity is exactly the same task we Client Access programmers face when we’re moving from menu-based systems to the Windows 95 Client Access paradigm. The task is more than screen-scraping the menus: it’s providing object-like organization in logical hierarchies. This means that we’ve got to analyze and organize our project’s applications into logical groups from the get-go, instead of tacking them onto a menu-like drop-box of available options.

How new is this approach? Is it the right approach? Does this represent a new standard around which we should be rallying, or merely one more “standard” that isn’t standard at all?

If you remember Windows 3.1 and NT 3.5, the only place where this kind of hierarchical structure previously existed was in the File Manager. Maybe that’s why IBM took so much time before releasing Unity, perhaps there was uncertainty about the direction NT was going to lead the GUI. Now that it appears that NT 4.0 will be using the Windows 95 GUI, it seems a sure bet that the Explorer paradigm will succeed as a standard, and that Rochester’s development efforts will continue to integrate OS/400 functions in a unified manner. For those of us who develop Client Access applications, emulating the Explorer interface will now become one of the first lessons we should learn.

But there’s a larger lesson for developers too. IBM integrated its design of Unity to fully complement the Windows 95 platform. It didn’t try to re-invent the wheel, or try to reimagine the “ideal” interface. It used Win32 OCXs to create the design and developed the OCXs along the way. By doing this, Client Access becomes a real extension of the client’s desktop, not an attachment of some foreign OS. This, of course, has always been the problem with AS/400 connectivity products in the past: things on the AS/400 worked differently than on a PC client. Consequently, when we as developers tried to integrate PCs with the AS/400, we always seem to get it backwards. That is, we always tried to make the user’s desktop look and feel like an AS/400 terminal. Now it appears IBM is giving us a product that gets this relationship right: it integrates the AS/400 to the desktop, and not the other way around. It’s about time, and with the new APIs and OCXs that Unity will be providing, it shows us that it really can be done with some elegance.

Program Granularity and Tight Control Over Function

Within Unity, IBM has also reformulated how an AS/400 application should interact with the client. In previous incarnations of GUIs for the AS/400, including SOA,

the user was provided with a display frame or window into which parameters could be typed. Then, when the OK button was pressed, the parameters were passed onto OS/400 through a remote procedure call, and OS/400 itself sent back any messages that were generated. This made life simpler for OS/400 communications management because the complete requirements for any particular OS function were passed along with each submission. Unfortunately, however, this also made programming within the GUI extremely cumbersome. There was little opportunity to provide context-sensitive editing within a panel, and the panels themselves—by necessity—tended to hold a lot more information than could be easily handled in the event-driven model. This was especially true in the pure screen-scraping implementations, there wasn’t much granularity in the applications, and they worked exactly like their NPT command counterparts—they tended act like dumb terminals with pretty faces.

Unity’s modular implementation, by comparison, seems much more tightly integrated with OS/400. For instance, the Change a User panel (shown in Figure 2) develops a logical progression of steps towards the goal of maintaining the profile of the user. Functionally, this panel provides a parallel component to the old OS/400 command CHGUSRPRF (shown in Figure 3). However, the Unity implementation seems to provide inherent logic in the organization of the command’s subfunctions (such as Groups, Personal, Security, Jobs, and Networks), and each click of an associated button provides a tighter control over the process of changing the user profile.

Rochester orchestrated this new level of granularity by creating new APIs for OS/400. This is probably a major reason for the delay in Unity’s release; new APIs require extensive testing. The results are dramatic. There is no question that the representation of functions to the operator is much simpler, better organized, and more easily managed in Unity. From this perspective alone, the increased ease of use from Unity may have been worth the wait. And for developers who are contemplating a similar conversion of their own custom OS/400 commands, Unity provides a good model from which a lot can be learned.

Is Unity Worth It?

How significant will Unity prove to be? The more you work with the Unity GUI, the more you realize how your previous vision of the AS/400 has been colored by NPT commands. Unity doesn’t seem like new coat of paint over the same old architecture, but a real change in the way we relate to OS/400. A good example of this sort of change can be seen in Unity’s System Policies icon.

Every AS/400 site on the planet has a policy for backing up the system. The policies vary, but the OS/400 commands are usually the same: SAVOBJ, SAVLIB, etc. Various iterations of these commands become the glue that preserves our systems in an emergency and guarantees we still have a job the next day if the system inadvertently crashes. Generally, these backup policies are not set in stone, but are orchestrated through custom menus or through OS/400’s Operator Assistant.

Of course, no IS manager in his or her right mind would turn over the process of archiving the AS/400 to a novice operator. The commands are somewhat complex and, without proper supervision or documentation, the chances of a novice completing a useful archive are, regrettably, remote.

By comparison, Unity’s GUI implementation of a backup policy provides equivalent functionality and a much easier interface. With the System Policies object, the Backup Policy is one available option. When activated, the Backup Policy provides a list of multiple backup practices, displayed as object icons in a window. (See Figure 4.) In this

example, there’s a daily backup policy, a weekly policy, and a monthly policy. By double- clicking on one of these policies, the rules of a particular backup policy can be quickly modified. (See Figure 5.)

Within this configuration, group parameters are organized in a logical fashion in tabs along the top of the window. These tabs include the What, Where, and When parameters, as well as general Global parameters. Individual parameters within a particular group are also “framed.” For instance, in Figure 5 there’s a frame called “Select data to save” that surrounds the selections that the configuration controls.

What have we really gained from this orderly presentation of a backup policy? First of all, we’ve received an encapsulation of our backup process that is easy to access, quick to modify, relatively intuitive to comprehend, and functionally equivalent to the various confusing and complicated OS/400 commands that previously graced our AS/400 operations menus. Secondly, Unity’s paradigm implements the policy in a way that is easy to communicate to our staff, makes training a new SYSOPR easier, and can free the more experienced operators to perform other duties. In other words, by integrating the AS/400’s user interface into the client’s GUI, we’ve eliminated a tremendous overhead of user training and expertise, and provided more robust tools in the process.

When will Unity be ready?

Parts of Unity are currently available. The remainder of the features will be available next year. If you’re really interested in how it’s going to affect your site, you should check out IBM’s Web site for Unity at: http://as400.rochester.ibm.com/products/unity/homepg.htm How much functionality will Unity have? IBM has said it will provide new functions to Unity over various releases, at the same time replacing GUI functions previously supported by SOA and other utilities. Of course, this means more waiting for Unity, but from all appearances, it looks like Rochester is going to teach us a lot about building Client Access applications in the process.

Figure 1: Unity’s Profile Manager Figure 2: Unity’s Change a User Panel

Figure 3: Displaying OS/400 Change User Profile (CHGUSRPRF) Command Figure 4: Unity’s Backup Policy Options

Figure 5: Modifying a Backup Policy