Architecture 101 What do users want for text processing?
From "VS Workshop",  Access to Wang, October 1988
[ Prior Article ]     [ Return to the Catalog of articles ]     [ Next Article ]

It seems as though all of the VS Word Processing users I talk to are considering some other processing approach. Many point to missing features in VS/IIS, slow response, or dependence on a central processor. Others wish to use specialty text processing products that are frequently PC-based. Still others have been reading about PC Local Area Networks (LANs) and feel that that is the inevitable course of automation. This month, I would like to contribute some observations to these issues, based both on my contact with a large-scale text processing installation and with my own use of text processing tools.

For purposes of this comparison, I divide text processing system options as follows:

• The centralist approach: A single VS serves all users.

• The standalone system: Single processors are used without direct connection to others.

• VS departmental processing: A hub of small VS systems each serving a group of users.

• Interconnected PCs: A central source - such as a digital PBX or a Local Area Network - connects standalone processors.

• PC/VS integration: Resources are shared between both environments.

In each case, these systems will be compared for editor features, ability to share information, operational simplicity, reliability, printing features and convenience, portability, and special needs.

I do not pretend that these are the only options available for text processing; I simply think of them as the likeliest choices among all options. Each option described here works in native mode; that is, it is not dependent on file conversions or other simulations and thus provides an understandable environment for the casual user.

VS Word Processing: the centralist approach

At the top end of the usage ladder lies VS Word Processing implemented as a large central processor. In this approach, all users edit, store, and print from a single processor. With the ability to support upwards of 180 simultaneous users with shared storage, printing, and support, it is clearly the large-scale solution to text processing needs.

Perhaps the greatest single advantage of centralized text processing systems is in their economy of support needs. With only one source for text processing, technical support needs are reduced and a smaller support staff is needed. (In many installations, there is no technical support; the users themselves cover that need.) Similarly, users can be trained in large groups since the face of the system is the same to all.

The centralist approach also offers some advantages in backup, shared document access, and accounting. A single operator can quickly and safely back up the entire system, allowing for potential gains in safety and data integrity. The availability of a large number of files on-line also allows easier sharing of information and re-use of prior research efforts. Central processors also make it easier to capture usage information and bill it to clients or departments.

Disadvantages of the centralist approach include the limited editing features of VS Word Processing and the load additional terminals place on the central processor. Users in large VS environments battle for processing resources during peak usage times. Naturally, interruptions to the central processor - such as for maintenance - knock all processing out the window.

Standalone text processing

At the opposite end of the spectrum lies the standalone system. This might be a PC-based processor with local storage and printing or perhaps an older dedicated text processor. Such units might have batch communications abilities with other systems, but are essentially on their own.

The operational use of standalone systems can vary tremendously. Dedicated processors - such as the WPS or Wangwriter systems - often provide elaborate prompting and clear use. On the other hand, most PC-based system wake up with a DOS prompt and expect the user to understand syntax to begin their task. Newer users find the latter approach unfriendly, but often adapt rapidly.

Again, other operational features of standalone systems vary with the product and its implementation. It is probably safe to say that standalone systems represent a compromise in printing features and convenience: rich features but constrained by access and the economics of purchasing a larger number of printers. It is also clear that most specialty text processing applications for specific user needs are going to be PC-based, so these needs might warrant such an environment.

Shared access between standalone processors usually consists of diskette exchanges - the so-called "Sneakernet" system. This is usually suitable for only the simplest uses, since is becomes impossible to tell which of perhaps many versions of the same file is the true and current version. Still, the portability and universal nature of diskettes makes this occasionally attractive; for example, I can do routine business writing at home by simply sticking a diskette in my briefcase.

Standalone systems work best in those rare instances where they serve only a few users and no one expects to share documents. I see them primarily as replacements for typewriters in small offices, or in the hands of independent professionals such as writers.

Hybrid VS approaches: departmental processing

The rich assortment of low-end VS processors and the unique transportability of VS software among all systems raises the possibility of using small VS processors supporting groups of users. With comparatively easy access across systems via Wang Systems Networking, this appears to be a very interesting solution indeed.

The chief advantage of a departmental VS strategy is the redundancy of resources and, therefore, support for basic access to processing resources. Users would probably always have some access to a system, even if it was not their usual system. Naturally, it would be helpful if most documents from other systems were universally available, so some analysis and development time might be needed to provide that access.

In most other ways, departmental VS processing would be expensive and cumbersome to administer. Most of the advantages of central storage, support, and backup would be lost, since processors might be strung about the building. While file transfer is available, in its usual form it is far from easy to use and not acceptable for the casual user. The limitations of VS Word Processing are also still present, so specialty needs and desires cannot be accommodated. Finally, my recent experience confirms that multi-CPU text processing environments are confusing to the users, particularly when files must be obtained from other systems; the interconnection of the systems is not clearly understood.

Interconnected PCs: the heir apparent

If 1988 is not the year of the LAN, it is most certainly the year of the LAN proposal. I can't begin to recall all of the "hallway meetings" I've attended where a particular user or department head wants a LAN soon. As a perceived defender of the centralist approach, I sometimes feel like I'm swimming upstream at Niagra Falls.

In the rush to adopt LAN technology, other forms of PC interconnection have been largely overlooked. These include switching methods such as dedicated data Private Branch Exchange (PBX) systems, mixed voice and data over telephone circuits, and multiplexed local asynchronous connections. All of these options offer some form of file and printer sharing and vary mainly in administration, cost, vendor support, and user features. In most cases, all should be considered for any environment where PC resources must be shared.

While PC interconnection approaches have matured rapidly over the last year, they are still are distant from the service level a VS user might expect. Again, the issues of data integrity, user support, and reliability are still valid; it simply takes more support effort to administer LANs and switching systems. I'm prepared to think that it might soon be worth that effort, however, since many user features are superior to a VS-only environment.

I look at LANs as another form of departmental processing with the server replacing the VS. Thus, some of the disadvantages remain: unclear connections with other systems, greater support needs, etc. On the positive side the features of PC-based text processing are retained, with the additional benefit of some amount of centralized storage, backup, and printing. Naturally, files are easily moved to other locations by diskette if necessary.

Integration: the final step

One of the more interesting events of the last year was Wang's development of PC/WP+ and the VS integration that that might ultimately represent. Like most other minicomputer fans, I feel that the VS's role in text processing should be that of file server; that is, a central repository for work in process with little burden on other processing resources. (This is not a new idea, considering that all Wang devices have local processors to shoulder some of the processing task.) PC/WP+ uses this approach by providing a PC-based editor for VS text files.

As presently delivered, PC/WP+ allows the local processor to edit a file that is resident on the VS. Utilities also allow a PC/WP+ local file to be transferred to the VS and converted. Other utilities allow VS files to be stored in a generic format on PC disks.

The advantages of this approach include retention of central control for data integrity while still off-loading the processing task to the PC - a much better use of technology. While the editor features of PC/WP+ are probably short of industry leaders like Microsoft Word or WordPerfect, they are certainly better than VS/IIS or older standalone units.

Since PC/WP+ is a new product, it will be a while before its effect can be analyzed. In the meanwhile, other options to text processing will continue to evolve. The next few years should tell us what directions will survive in office automation.