Cad Guidebook: A Basic Manual for Understanding and Improving Computer-Aided Design (15 page)

3.2.3 Command Interface

Operating systems generally have a command “interpreter.” This is a type of
computer language that works “directly” with
the operating system. A part or
“module” of the operating system is “invoked” to interpret the commands of the
user. These commands can be interactive, meaning the user is typing the com-
mand and then the computer acts on the request. The commands for the inter-
preter could also come from a file. This is an important function for automating
tasks that the user does not want to keep typing manually.

In many cases, the use of this automation process is “hidden” from the
standard CAD user. Instead, a CAD administrator or someone from the computer
systems department would probably use the command interface to define func-
tions, and then the standard CAD user would be given a means of requesting the
function (such as through an icon or pull down menu). Of course, even standard

Computer Software Basics 51

CAD users can derive some benefit from being at least somewhat familiar with
the command interpreter capability. This would facilitate understanding what the
operating system is capable of doing, and it could facilitate assisting the adminis-
trators of the system.

There are a number of names and capabilities associated with the command
interpreter and its language. For workstations, the most common reference is to
the shell program or shell scripts or just scripts. The shell is seen as a program
that is sort of a shell around the real program that is controlling the CPU, mem-
ory, and storage, and it provides a more direct interface between the user and the
operating system. These shell programs come in a number of “flavors” based on a
succession of versions of the Unix operating system. Some versions of Unix gen-
erally were coming from AT&T’s Bell Labs and its descendants as System IV,
System V (“System 5”), etc. Other versions were coming from the University of
California at Berkeley as BSD (Berkeley Standard Distribution). One flavor gen-
erally had a shell program called “sh”; the other had a shell program called “csh.”
Later, versions of this operating system somewhat merged the shells into a “ksh.”
The programs that can be written to work with these shell programs can be quite
powerful, and the “scripting” of unix is a renowned capability for the operating
system.

There are also a number of terms applied to the dominant operating sys-
tems for PCs. Most early PCs worked with the program called PC-DOS (for Disk
Operating System), and the PC-DOS program had a command interpreter. Main-
frames and early microcomputers also had programs called DOS and/or OS, but
this book will be assuming that DOS means the Microsoft PC operating system
program. The PC-DOS command interpreter could be programmed through a
type of file called a batch file; it ended with the .BAT file extension (batch pro-
gramming was another mainframe term for many years, but again that will be
ignored in this work). Thus, it is not unusual to have the use of the command
interpreter capability be referred to as the “DOS prompt” (even though Windows
has long since replaced DOS), or for files that drive many command interpreters
to be referred to as “batch files.” Since Microsoft has controlled most, if not all,
of the development of the PC command interpreter capability, there is far less
confusion about their content (as would be the case with the sh/csh/ksh situation
with Unix). However, since the PCs were not generally driven as much by script-
ing (for interactive commands as well as shell scripts), the PC would generally be
considered less capable with respect to the command interpreter in comparison
to Unix.

3.2.4 Network Management

As mentioned in the chapter on computer hardware, a significant portion of a
computer’s function is in conjunction with a computer network. The network is

52 Chapter 3

the way that computers communicate with each other at high speed. This is only
possible if the operating system is “aware” of its connection to the network, and
if it is, in turn, “known” to the other devices on the network.

At the operating system level (which is a fairly high level with respect to
networking), most computers communicate with each other and with users via
node names. Since most network architectures are based on allowing many com-
puters to communicate to many others (as if they are all equals), one can envision
a number of islands with wires connecting the islands in a vast web of connec-
tions. In this sort of a logical arrangement the islands are called nodes. Thus com-
puters on a network are often given node names. These names identify the
computer to other users and other computers, although the node name is usually
mapped to be equal to a unique numbering system (refer to Chapter 2 on com-
puter hardware for the addressing schemes).

Beyond just knowing the “node names” of the other systems on the net-
work, the operating system needs to define what privileges are granted to users
that access the system from across the network. Usually there are reduced privi-
leges for these “remote” users, as opposed to the local user or users. With most
operating systems, there is usually a means of “crosslinking” or “linking” or
“mounting” data on disk drives from one computer on the network to another
computer. This is extremely valuable in setting up computer software like CAD
systems for a group of users. In this case, the drawing and 3-D model files can
appear to the user to be stored on their personal computer, but in reality it is being
kept on a secure computer file server with proper backup systems. This can be
done by making an entire disk drive appear to be a local device, when it is really
on a file server computer (the typical PC network approach). This can also be
done by making a directory or folder appear
to be a local directory, when it is
really a directory on a file server (the typical Unix network approach). In either
case, the operating system must be set up properly to permit this sort of data
sharing.

Another issue that may arise with respect to network management is li-
cense management. Some commercial software programs, and “large” CAD soft-
ware in particular, are controlled by a set of licenses stored on the network. The
number of licenses is predetermined by the company’s purchase of the software,
the more the customer pays, the more licenses that are available. Then, as the
CAD system is used by more users, the number of available licenses decreases.
Since these users are usually accessing the program from the network, it is a net-
work function to keep track of how many licenses have been paid for, and “check
in” and “check out” the licenses to users across the network. This process is usu-
ally controlled by a special kind of program called a “daemon” that is somewhat
detached from the operating system once it starts. It “polls” or regularly commu-
nicates with the various computers on the network and manages the process of
letting individual computers run certain functions. The daemon or “license dae-

Computer Software Basics 53

mon” usually keeps track of the licenses that the CAD system allows by a “pass-
word” file. This file has long strings of numbers and letters that are created from
encryption of a particular customer’s system (usually using the Ethernet address
of the network interface circuit board on the license “serving” computer).

3.2.5 Device Management

The chapter on computer hardware discussed the peripheral devices that are typi-
cally found on computers that run CAD software. The presence and behavior of
these devices must be managed by the operating system. Each time a new device
is added to a computer system, the operating system needs to know it is there so
that its function can be integrated with the other devices on the system.

There are a number of levels of operation that are important with respect to
device management. The lower levels do most of the work of having data prop-
erly flow to or from the device, but it is the operating system that actually allows
users or application programs (such as CAD software) to make use of the hard-
ware. Just because a new disk drive is physically attached to a computer does not
necessarily mean that a file could be created on it.

Hopefully the device management operations of the computer can be preset
for a specific CAD software system or platform. After this initial configuration,
there may be no need to alter the configuration. But, support for the computer
hardware in the operating system is a somewhat never-ending story, particularly
for the PC class systems. In this case, there are so many manufacturers of so
many different devices that can be attached to the PC (which can be advanta-
geous in a general sense), that it is difficult to guarantee that the system will func-
tion satisfactorily over a long period of upgrades. Generally with the unix
workstation computer systems, there is a much more limited choice of devices,
but then there tends to be fewer problems with sustaining stable operation since
the limited list of devices is often carefully checked out or verified for good be-
havior by the computer workstation manufacturers. In fact, the choice of periph-
erals may be limited to just components from that particular manufacturer.

3.2.6 Queue Management

On a computer system, a queue is a capability that involves performing specific
tasks in a self-sustaining background mode. This means that the computer can
work on a task behind the scenes while the user goes on with other activities. The
most common use of the queue system is printing or plotting. In this case, the
user requests that something (such as a drawing) be printed on a hardcopy device.
The operating system receives this request from the program (such as the CAD
software) and then it sends the data to the device. The queue system is also capa-
ble of keeping track of multiple requests. The requests are serviced one at a time
(as if standing in line or as the British say “standing in a queue”).

54 Chapter 3

Managing the queue systems is usually a major function of the operating
system. There are many choices in how these queues are configured. For in-
stance, some printing or plotting may be done on devices that are locally attached
to a computer system. In other cases, the devices may be on a print server, or the
devices may be attached directly to the network. In all these cases, the operating
system for the local system as well as the file server must be set to handle the
printing and queuing operations. For most CAD users, the typical arrangement is
for there to be various smaller printers that are available for check prints or per-
haps for screen dumps; while the network would also have available production
quality devices for large plots of drawings. The operating system would be used
to set up different queues on the various computers in this approach. Typically,
the administrator for the operating system would give these different queues dif-
ferent names, and a certain amount of disk drive space would be allocated for the
queues to hold data. Then these queues are then available for programs on the
computer system to utilize.

Another issue to consider for queues is the type of data format sent to the
devices. Some printers would accept simple ASCII data files, while others would
only accept specific plotter languages.

Although the use of prints or blueprints is generally being replaced with
electronic formats and viewers, the same queue management issues are going to
arise. In this case, there has to be proper digital archives for keeping and tracking
the electronic format files, and the access of these archives is going to be con-
trolled via the operating system.

3.2.7 File Management

The final issue to discuss with respect to operating system software is file man-
agement. This is clearly the most important type of management that users need
to understand to maximize effectiveness with the computer system.