[Access to Wang masthead]

A Glimpse into the UNIX Universe
From "Special Report",  Access to Wang, July 1993
  [ Prior Article ]     [ Return to the Catalog of articles ]     [ Next Article ]  

After seemingly endless discussion and hype, it appears UNIX is finally gaining momentum in the host-based market previously dominated by minicomputers like the Wang VS. UNIX vendors have made good progress in identifying and solving weaknesses in UNIX's commercial applicability, and the user community is beginning to notice. Managers everywhere are being deluged with information on the inevitability of Open Systems (a.k.a. UNIX) and are responding by demanding such solutions from the IS staff.

Perhaps your organization is one considering such a change. Successful conversions can be found everywhere and vendors are always willing to expound on the benefits of their products, but many questions remain. What will be the effect to the people of your organization? What will your end users see when they turn on their terminals each day? What does your technical staff need to know, and how can the achieve this understanding?

This article will analyze the components of UNIX systems and their implications to the choices facing an organization considering a change to UNIX. A comparison with like components in the Wang VS, Local Area Network (LAN), and PC environments will be drawn as an aid in understanding this rich environment.

Origins

To understand the needs and expectations of VS users and the choices facing them in the UNIX environment, it is necessary to review some history of both environments. In the late 1970s there was a tremendous surge in minicomputer-based commercial development, much of it intended to replace applications previously running on mainframes. Like other systems of that generation, the VS was designed as an interactive system for business applications. Entrepreneurs like Dr. Wang capitalized on management discontent with the speed and cost of systems development, offering excellent price and performance and a programming environment that speeded development and reduced application backlogs. The VS required little involvement from technical staff to use, and many systems continue to be operated today by end users with little systems training. The menu-oriented environment of the VS is especially appealing to those without interest in the technical aspects of computing.

In contrast, UNIX was born in the think-tank environment of Bell Laboratories early in the 1970s. At the time of the rise of the VS in the late 1970s, UNIX was already a mature system in the academic world and was beginning to attract the attention of the business world. Its users were primarily academic professionals that used the system as a form of communication with others in their fields; as a result, UNIX has a strong orientation to text-processing tools and mail exchange with other systems. An illustration of this orientation toward message exchange is the fact that the system date and time are stored internally in Greenwich Mean Time and converted to local time for displays, allowing worldwide file exchange with comparable dates and times.

At the time UNIX was developed, video terminals were rare, so all commands were designed to be brief and powerful to minimize the effect of slow terminals. System administration was performed by graduate students and others in university computing centers, and these administrators frequently had extremely technical backgrounds. Elegance of design and a terse command-driven style were the preferences of these early users, and mastery of cryptic commands was a source of pride for them.

Though UNIX was not explicitly designed for the business world, it has several interesting aspects that make it a likely candidate. UNIX was the first large-scale operating system to have published specifications, allowing universities and computer vendors a chance to mold it to their desires and expectations. UNIX was also one of the first operating system written in a high-level language. Development of UNIX and the C language are intertwined, and this tight integration makes it easier to extend the functionality of the operating system through routine programs. In fact, many of the standard UNIX utilities are actually small programs contributed by a large and active user base.

UNIX is designed as a series of layers, where only the center layer - the kernel - requires machine-specific code development. This layered approach allows rapid movement from one hardware architecture to another, increasing the likelihood that manufacturers will "port" UNIX to their environments. Thus, UNIX is considered the most portable of all operating systems.

To summarize, VS users expect to be able to work with the operating system directly and without extensive training, while the native UNIX environment (the command prompt) requires more understanding on the user's part. It's important to remember the chameleon-like nature of UNIX, though; with the availability of powerful tools and an understanding of the internals of UNIX, it is possible to make UNIX appear almost any way you like it. An example of this principle is the wide range of tools for system administration provided by equipment vendors: each superimposes a comfortable application over the underlying base of standard UNIX commands, simplifying the process of operating the system. (See related article on system operation, above.) Since the heart of these tools is UNIX itself, this type of systems software can provide benefit to the administrator without sacrificing portability.

RISC and the Effects of Competition

If the portability of UNIX made it attractive to customers and vendors, the development of Reduced Instruction Set Computers (RISC) made it economical. RISC designs reduce the number of types of system calls available, instead concentrating on doing the most popular operations very quickly. Proprietary minis such as the VS - now known as Complex Instruction Set Computers (CISC) - were designed with over 300 system operations, and many of these operations required large amounts of time from the central processor. RISC designs typically have less than one hundred system calls - though most vendors have added back fifty or more complex instructions that are related to commercial or scientific needs. This reduced overhead, combined with faster bus speeds and other improvements, has boosted the power of small systems to impressive levels.

What is the effect of RISC architectures to your shop? One result is that the power and cost of processors continues to drop rapidly, and stiff competition between equipment vendors is improving products at a ferocious pace. Customers are demanding proof that a vendor's solutions are "open" so that they will never again face the constraints of a proprietary environment, and this standards-based world reduces the importance of selecting one vendor's products over another's. It seems that the market has turned rapidly to favor the customer - a sharp reversal from the vendor-dominated proprietary systems market of the past.

Configuring a UNIX system

Those of us used to a sizable central processor may have a shock awaiting when selecting RISC-based systems: their physical size is not a good indication of their actual processing power. Many are little larger than a PC and most do not require a special environment to operate. Though it is still possible that unscrupulous vendors will deliberately undersize a machine in order to show the best price, competition and current price/performance ratios have reduced this practice substantially.

Attaching peripherals is easier than before, since most CPU vendors use the industry-standard Small Computer Serial Interface (SCSI, a.k.a. "skuzzy") standard. SCSI peripherals include all types of storage devices, including disk drives, tape drives, and Compact Disc drives, and the speed and volume of data moved on these peripherals is impressive. Third-party sources abound, but be sure to consider the purchase carefully in light of the service limitations imposed by most major equipment players when problems occur with equipment from other manufacturers. Even when purchased from "premium" source, SCSI peripherals offer far more storage per dollar than VS drives - though you may find you need more disk space than ever before, since UNIX does not offer file compression like that commonly used for VS data files.

Memory usage is another area where VS users will be initially shocked at the quantity required. UNIX operating systems do not make efficient use of memory like the VS architecture, so larger amounts will be necessary. A rule of thumb for host-based applications - such as those ported to UNIX from the VS - is at least one megabyte of memory per user session plus at least twenty for the operating system. Add the overhead of relational data base products and other software and memory needs of 256 or more megabytes are not uncommon. Fortunately, the cost of this memory is small enough that the cost is not a big issue.

Workstation Connection Options

Workstations can be attached to UNIX systems through two major connection types: serial connections (RS-232 or equivalent) and network connections. Serial connections are similar to the 2110 asynchronous connections used on the VS, but rely on industry-standard terminal types such as the Digital Equipment VS-102. ("VT-100" terminals are roughly equivalent to the ANSI 3.64 standard, and Wang's 2110 terminal definition is a superset of this standard.) Unlike asynchronous modem connections, most UNIX terminal connections require very few wires to establish a connection - a three-wire setup is common - and most can be located much further than the usual fifty- foot limit imposed by the RS-232 standard.

Network connections offer better speed but require more decisions on the wiring medium and equipment at the desktop. Most UNIX installations rely on an Ethernet network, but distribution through coaxial cable (thinnet or thicknet) is no longer popular. Instead, network hubs allow the use of centrally-located network devices with connections branching to each workstation. These connections are typically made using the 10baseT topology, which uses Unshielded Twisted Pair (UTP) wiring and telephone-type connectors. LAN-grade UTP wiring is only slightly more expensive than voice-grade telephone wire and allows communication at speeds of 10 megabits or more per second, with some new products pushing that speed much higher than that. If you are using baluns (twisted-pair adapters) for your Wang terminal connections already, your wiring may already be suitable for this purpose.

In theory, network services can be extended beyond the limits of the physical network connection; in practice, however, it is usually not cost-effective to do so. Hardware and software products are available that allow dial-up access to a network, but such products are usually expensive and too slow for on-line data entry. There is much vendor and user interest in solving this problem, and products may be available soon that provide a realistic alternative, but for now you should plan for asynchronous dial-up services for all users outside the building.

Terminals, please

Once the connection question is settled there are several choices for workstations, including the following:

Your workstation choices can include any or all of these options. Most commercial sites I have talked to use PCs and terminal emulation software to allow use of PC or LAN-based applications in addition to access to host-based applications. PCs can also allow easy connection to more than one system - including simultaneous access to UNIX and VS environments. For example, many shops that require simultaneous access to Wang and UNIX environments use MS Windows-based emulators and Wang's Winloc software, allowing each terminal session its own window and switching between them as necessary. X terminal emulation on a PC is a good choice for occasional use of X-based applications on the UNIX side, such as some of the systems management packages offered by vendors.

Connecting and Using Printers

The choices for printer connections are largely similar to those offered for PCs, with serial, parallel, or network choices among them. Serial and parallel printer connections are similar to those found in the PC world, with similar distance constraints and wiring requirements. Serial and parallel connections may also be shared with other systems using switch boxes or other devices, but be careful: UNIX print control is not as mature as that on the VS and controlling a wayward print job is not as easily done. Like the VS, serial printer connections must be configured prior to use, and a system restart may be necessary before the changes take effect. Parallel connections are simpler and do not normally require any configuration, since the parallel connection itself handles speed negotiation and flow control.

Network printer connections feature a fast transfer rate and the flexibility to move the printer anywhere on the network without reconfiguring. Like workstations, network printers must have a network card and an appropriate connection to the network; again, 10baseT is the most popular choice. Like all network devices, network printers must usually be located within the building.

The Technical Environment

The native form for UNIX is a command prompt, just as the native form of the VS is the Command Processor - a menu. This fundamental difference in operating philosophy sums up much of the difficulty some technical users will have in adapting to the UNIX world. Those who have used MS-DOS from a prompt - or other command-oriented systems like Digital Equipment's VMS - will find much that is similar with UNIX. All should learn enough about UNIX commands to perform routine file and directory navigation and understand file attributes and security.

I make a distinction between technical and other users in that it is unlikely that most Wang shops would require their end users to use a prompt; menus are more in line with the expectations for this audience. Technical users may also use menus and other tools to simplify their work, but all should understand the underlying UNIX commands that do the real work.

Like so many aspects of UNIX, there is even a choice of command styles available. The system uses an interpreter known as a shell to accept and act on commands typed at the prompt or issued by programs. In the MS-DOS world, COMMAND.COM performs similar functions to UNIX shells. The user's choice of shell environment is part of the user setup process. Popular choices include: the Bourne shell, the first and available on almost all UNIX systems; the C shell, a powerful shell which uses syntax like the C language and is popular with programmers; and the Korn shell, a combination of Bourne and C shell features that is gaining in popularity.

Shell features and syntax varies, but all have some similar functions. All allow the use of variables to contain data and make it available to programs, similar to environment variables in the PC world. Most record prior commands issued from the prompt so that they can be recalled and repeated; some also allow editing on the command line prior to issuing the command. All allow input and output between programs through the concept of standard I/O, a means of joining the output from a process to the input to another process, and redirection, which sends the result of an operation to a file or device; again, MS-DOS has borrowed from these concepts and experienced PC users should recognize the power offered by this capability.

So far I have discussed only the interactive aspects of shell choices - the response to user-entered commands at the prompt. Like all operating environments, UNIX also offers job control languages to tie programs into processes and automate routine activities. In the VS world, Procedure language fills this need; in UNIX, the same shell languages mentioned above can be invoked. Files that contain shell commands are known as scripts. Some care must be taken to be sure that the system understands which shell language you intended. In most UNIX systems, a "comment" at the top of a shell tells the system which shell to use for the script.

Most UNIX commands are actually small programs, such as the cp program that is similar to the COPY command in the PC world. There are many variations on directory commands, each offering a different selection of file information as needed.

Security

In contrast to rumors to the contrary, UNIX offers many powerful security features that, if properly used, should ensure more control of access that the VS or many other environments. One of the reasons this is not always true is that the options are complex and, thus, systems are not always set up carefully. UNIX uses a combination of owner and group rights to control file system access, and a password entry to control logons to the system.

Like any other multi-user operating system, UNIX and the VS both offer password-protected access control - the "login" screen - that is directly supported by the operating system. System administrators can control access to the system through this facility, since the presence of a valid account is necessary before any system resources are released.

Unlike the USERLIST file on the VS, the UNIX passwd file is typically available for any user to read; the information contained in this file includes a full description of the user including their name, address, group affiliations, and an encrypted password. This seems odd to those of us used to hiding this information, but many UNIX tools require read access to this file and vendors tell us that the encryption routines have not been broken. (Actually, most system access violations occur from dogged trial-and-error guessing approaches and poor password choices, not be deciphering encrypted information.)

Most UNIX vendors provide a program that allows end users to change their own passwords and applies some rules to the password choices that can be made by the user. Typical password rules include: not an English word; must be six or more characters in length; mixed case (capital and lower-case letters); at least one number. In some cases, repeated use of the same password (known as "password toggling") is also checked and disallowed.

File Characteristics

Like other operating systems, UNIX stores some information on each file in its catalog. This information include the name, date and time of last modification, date and time of last access, a file access matrix, and the owner and group. The file access matrix is composed of three levels (user, group, and world) that each have three levels of access (read, write, or execute). Directories are a special form of file and have the same information and access matrix. File access control can be accomplished by control of the directories containing the file or by allowing directory or individual file access by ID or group.

One important omission in this list of characteristics is a file type. The VS records the type of file and uses this information to determine what should be done with these files, while UNIX has no such information. One example is indexed files, which are directly supported by the VS operating system but are not part of any UNIX system. The reason for this is a difference in design philosophy: UNIX zealots believe that indexed file support is the responsibility of the application, not the operating system. For this reason, support for record indexing and access is usually bundled with the development language you choose.

While not directly supported by the file system, UNIX does provide a means of determining a file's type: the file command, which reads the file and guesses about its contents. This is most useful in determining whether a file contains text or binary information. UNIX also recognizes a range of special files, some of which are not really files at all but devices (printers, modems, and terminals) that can act like files.

The File Structure

A comparison of the file structures of UNIX and the VS shows some similarities and a large number of differences. Both allow shared access to files and provide a hierarchy in which files can be stored. The VS file structure is fixed at three levels (volume, library, file), while UNIX uses a multiple layer of directories and sub- directories that files can be allocated to. (The "tree" structure of UNIX directories was later adopted by Microsoft for the MS-DOS operating system, and it is much the same as UNIX.) Many VS shops that have converted to UNIX still retain the three-level environment of the former systems for compatibility reasons.

File names represent a large difference with the VS environments. UNIX file names are case-sensitive and can be fourteen or more characters in length. In other words, a file named longfilenam is not the same file as LongFileNam nor LONGFILENAM. Unlike MS-DOS, UNIX does not enforce a name format that requires periods or other characters, so long.file.nam is also valid. (An exception to this convention is "hidden" files; any file whose name begins with a period will be suppressed from most file listings.)

The VS - like MS-DOS - places an eight-character limit on the file name and does not consider the character case; MS-DOS adds a further refinement in the form of a three-character extension that often identifies the type of file. For example, a valid VS file name would be LONGFILE in the SYSOBJ library on the SYSTEM volume, while MS-DOS may have a file named LONGFILE.EXE, an executable program file.

The relationship between physical disk drives and their use is another file system difference. In most shops, VS volume names are associated with physical disk drives; exceptions include those that use volume sets - volume catalogs that index multiple physical drives. UNIX allows all physical drives to be mounted within a single file structure, allowing access without regard to physical location. UNIX also allows many names for the same file, a process known as linking.

System Administration

User administration can vary tremendously according to the shop's needs and environment. At the very least, the user's ID and password must be set up in the password file, a shell environment chosen, and a home directory set up; UNIX uses the home directory to retain a number of user-specific parameters. Entries must be made to set up the user's group affiliations and presence in the UNIX mail system (if required).

Verification of the file system is among several important system administration tasks. UNIX file systems allow many types of file activities, including some that may damage the file system itself, and more vigilance is necessary than on VS systems. Much of the tools required for file system checking is part of the operating system, though sophisticated system management software is also available from other sources.

UNIX provides only minimal backup software and VS users will be disappointed with them; here again, aftermarket sources may be a better solution. The typical backup medium for modern UNIX systems is cartridge tape (either the 8mm video format or Digital Audio Tape (DAT) formats), though some can be found with Quarter-Inch Cartridge (QIC) and reel-to-reel tape systems as well. Since most UNIX environments have more than a gigabyte of disk storage, the capacity of the backup medium is a critical choice.

If capacity limits appear, there are many ways to increase processing power. RISC processors are modular, and a board swap may be all that is necessary to upgrade the CPU. Additional memory and disk drives can be installed with roughly the same effort as that required for PCs. The communications-based approach used by UNIX allows additional processors to be added to the network and dedicated to specific tasks, freeing other processors to carry on without that overhead. Finally, when traffic gets heavy additional networks can be set up and bridges established between them. (As always, be sure to discuss these upgrade options with any prospective vendor - before you need them!)

Onward

UNIX seems an unlikely candidate for the salvation of Wang commercial data processing operations. Its terse, low-budget style contrasts sharply with the menu-driven VS culture and rich operating and development environment. The appeal of UNIX lies primarily in its power and flexibility. It is true that the UNIX environment can be anything you choose to make it; the existence of cloned VS environments in sites that have migrated attests to that. Still, it is important to realize that UNIX must be understood and administered under its own terms, and technical staff will have to be retrained eventually to meet this need.

I would like to acknowledge the help of James McCorison, a UNIX systems and connectivity consultant in the Seattle area, for his real- world perspective on VS site migrations to UNIX.

  [ Prior Article ]     [ Return to the Catalog of articles ]     [ Next Article ]  

Copyright © 1993 Dennis S. Barnes
Reprints of this article are permitted without notification if the source of the information is clearly identified