⇓   ⇐
  ←Part 4  Part 6→
by George Stachnik

In our previous articles, we have explored MPE special capabilities. This month, we will pay special attention to OP capability, and touch on the subject of system backups. OP capability was originally conceived to solve a specific problem: how to back up a system without giving the operator unrestricted access to all the data to be backed up.

All computer systems need to be backed up regularly. Although today's computer hardware is far more reliable than the processors, disk drives, and memory boards of days gone by, disks still crash, processors still fail, and memory still occasionally goes haywire. The HP 3000 has all sorts of mechanisms in place to help protect your data from random acts of malfunctioning hardware, but thus far, nobody, not even the MPE lab, has been able to construct an absolutely safe system. A regular backup schedule is a necessity.

So, what's the best way to do a full backup? The act of backing up a computer to a secondary medium (such as tape) involves writing a copy of every single file, database, and program to a backup device. But that presents a security problem. In order to copy every file on your system to tape, the person doing the backup would seem to need read access to every file on your system. Indeed, many operating systems do require that the user doing the backup have full access to all the data. Some implementations of UNIX still work this way, requiring that backups be performed by a superuser with unlimited access to the system.

Now, there is nothing wrong with this approach, as long as you trust your operator. In today's world, though, system managers are very busy people. Console operations (including routine backups) are often delegated to entry-level employees. I've seen some installations in which backups are handled by part-time employees, some of whom may even be high school students. Do you really want these people to have unlimited access to the data on your system? MPE provides a solution to this problem, but to understand how it works, we need to explore the idea of backups.

On the HP 3000, there is more than one way to write data to a backup medium. The simplest way is to use the FCOPY utility program. Using FCOPY together with a :FILE command, (see the sidebar The Mechanics of Backups) a user can write a single file to tape, as long as he has read access to the file. This can be useful in situations in which you create a tape that will later be accessed by another system. Standards for this kind of tape are applicable across multiple kinds of systems. For example, a tape created with FCOPY can be read, under certain circumstances, by IBM mainframes running the MVS operating system.

FCOPY, however, clearly is not an adequate tool for doing a system backup. In that case, the :STORE command represents a vast improvement over FCOPY. The :STORE command allows a user to store more than one file to tape. Using MPE wildcard characters, the user can specify a file set (which may include all the files on the system) and write all the files in the set to tape.

In order to use the :STORE command, an end user needs to have either IA or BA capability (one or the other of these is required to log on), as well as ND capability. ND stands for nonsharable device and it's required to write to any device (such as a tape drive) that can be used by only one person at a time. If you have these three capabilities, the :STORE command will allow you to back up files--but with one important restriction. You can only back up files to which you have read access.

Although this is useful, it does not solve the problem of who is going to do backups. To do a proper system backup, you need to have access to all the files on the system. Fortunately, the :STORE command has one additional feature that does solve the problem. If you have OP capability, then :STORE will give you access to all the files in the system--but for one purpose only--to back them up to tape. You cannot print them, display them, change them, or access them in any way other than to back them up to tape.

This is the single most important difference between SM capability and OP capability. With SM capability, you can use any MPE command or program to access any and all data on the system. You can display the contents of files, run programs, even change them. With OP capability, you can use the :STORE command to copy the data on your system to tape. But OP capability does not enable you to change the data or display it.

The :STORE command, when used in conjunction with OP capability, allows an end user to do system backups. :STORE has some limitations, however. For example, :STORE will not back up files currently in use by other users who may be logged on. For this reason, if you are using :STORE, you need to chase everybody else off the system and do the backup while you are the only user logged on. Since backups can take several hours (depending on the size of your system and the speed of your backup device), this limitation is unacceptable in many shops. For all practical purposes, backup time represents downtime for your system, and if you are trying to provide around-the-clock service (24x7) to your end users, planned downtime is not acceptable. For 24x7 situations, many backup tools (including HP's own TurboSTORE) allow you to do online backups--that is, to back up files without having to chase other users off the system.

Another security risk is associated with backups, and system managers need to be aware of it. Suppose your operator has :STOREd the data on your system to tape. With OP capability, your operator can use the :RESTORE command to bring the data copied to tape back to your system. This is the main purpose of the :RESTORE command; if a file becomes corrupted, the operator uses :RESTORE to restore it from a (presumably noncorrupt) backup.

Normally, the :RESTORE command restores files in place. In other words, if a file called MYFILE.PRIVATE.SENSITIVE is stored to tape, then :RESTORE writes the backup data back where it came from originally--the PRIVATE group of the SENSITIVE account. But if the user doing the restore has SM capability, he can do something else. He can restore the data on the tape to a different group and account. And that turns out to be a potential problem.

Let's look at one scenario. Suppose you have two systems--one used for production and one for development. On production systems, most people are very careful about who gets SM capability--the operator, for example, has OP capability (not SM). But on development systems, some system administrators might figure, Well, what the heck, it's a development system; how much harm can be done by a programmer with SM? So, you give SM capability to all the programmers on the development system.

Now suppose one of your programmers gets hold of a backup tape from your production system. It does not even have to be a current backup--it can be an old one--so long as the data on it is still sensitive. The programmer has it long enough to :RESTORE some of those sensitive files. They are not restored onto the production system (where they belong) but onto the development system. With SM capability on the development system, the programmer can restore whatever data is on the tape and even hide the data by using different filenames, or by placing it in accounts where it does not belong (and where you are not likely to notice it). Once it is restored, the programmer can read it, print it out, sell it to your competitors, or whatever else he likes.

The bottom line is that OP capability is a tool for ensuring the security of your data against operators. But it is not a panacea. You still need to have systems in place to keep track of your physical backup media. If you do not know where all your backups are (including the old ones), then you are inviting trouble of a very serious kind.

Next month, we will to continue to examine MPE basics. Beginning in the next issue, we'll start looking at how the HP 3000 ensures your file security. We'll do this by examining the MPE security matrix, and just as important, by seeing how unscrupulous users may exploit security exceptions.

The Mechanics of Backups

Backing up files typically involves the use of a :FILE equation. File equations are among the most commonly used (and useful) tools available to the MPE user. They are the glue that binds programs (including your applications) to the files and devices on your system. A file equation can easily be created using the :FILE command. The :FILE command is typically used with two operators, like this: 
:FILE BACKUP;DEV=TAPE
The first operator (in this case, BACKUP) is called the formal file designator. On the HP 3000, whenever a program opens a file or a device, the program refers to it using a formal file designator. So the above file command is assigning the formal file designator BACKUP to a file or device.

The second operator can include the name of a file or the name of a device, or it can contain file attributes that will be used when the file is opened. In the example above, the second operator is DEV=TAPE. We are assigning the formal file designator BACKUP with a device called TAPE (presumably, our system's tape drive or DAT device).

File equations can be used with application programs. So, for example, the output of a COBOL program can be directed to a tape device using a file equation such as the one we have seen. Of course, few application programs write data to tape anymore. Occasionally, though, I still find applications that need to write a single file to tape (usually so that it can be shipped to another data center, where it will be read by another computer). This can be accomplished using MPE's FCOPY utility. The following example shows how a file equation can be used, together with FCOPY, to copy the contents of a file called MYFILE.MYGROUP.MYACCT to the tape drive. 
:FILE BACKUP;DEV=TAPE
:FCOPY FROM=MYFILE.MYGROUP.MYACCT;TO=*BACKUP
The asterisk (*) in the FCOPY command tells the system that BACKUP is not the name of a file, but rather a reference to a file equation. So, in this example, FCOPY reads the data stored in MYFILE.MYGROUP.MYCCT and writes it to the device defined in the BACKUP file equation. In this case, that device is the tape drive.

Before any data can be written to a tape, somebody has to mount a reel of tape (or insert a tape cartridge) on the tape device. When the FCOPY command shown above is issued, this message appears on the HP 3000's system console: 
?12:20/#S212/158/LDEV# FOR BACKUP ON TAPE (NUM)?
The message is asking the system operator to mount a tape on a tape drive, and then tell MPE which tape drive (there may be more than one!) to use for this request. Let's take this message apart, piece by piece.

The message begins with a question mark (?), which indicates to the operator that it is not just informational; it demands a reply.

The second word in the message (#S212) tells the operator that Session Number 212 issued a request to use the tape drive.

The third word (158) identifies this particular request. The operator will use this number when he responds to the message.

Finally, the message LDEV# FOR "BACKUP" ON TAPE (NUM)? tells the operator to mount a tape and then tell the system which tape drive the tape is on. On the HP 3000, every device (every disk drive, every terminal, and every tape drive) is identified by a number called a logical device number, or LDEV# for short. This message is asking us to tell MPE the LDEV# of the tape drive we want it to use for this request.

If you were the operator for this system, you would respond to this message by mounting a reel of tape on an old-fashioned reel-to-reel tape drive (if that is what is installed on your HP 3000) or by inserting a DAT cartridge into a DAT device (if you are using a DAT drive). Then you would tell MPE the LDEV# of the device you chose to use. (Remember, every device has its own LDEV#.)

To do this, you type control-A (holding down the ctrl key and the a keys simultaneously). Control-A can be entered only at the console; if it is entered at any other terminal, the HP 3000 will ignore it. Whenever control-A is entered at the console, a special equal-sign prompt is displayed. The operator can use this prompt to enter special commands that do things that you want to do only from the console (such as shut down the system or restart it, to respond to outstanding console messages). The =REPLY command can be used to respond to an outstanding console message as follows: 
=REPLY 158,7
In the above example, we are saying that we are REPLYing to message number 158 (the number appearing in the message displayed above), and our reply is 7. In other words, we are telling MPE that we have mounted the tape on LDEV# 7. As soon as the REPLY command is entered, MPE will start copying the data in MYFILE.MYGROUP.MYACCT to the tape on LDEV 7.

In today's data centers, tape is rarely used in this way. Tape (typically DAT cartridges) is generally used as a backup medium instead. The mechanics are the same. The only difference is that the :STORE command is typically used instead of FCOPY. For example, the following commands are used to back up all the files on the system to a tape device: 
FILE BACKUP;DEV=TAPE
STORE @.@.@;*BACKUP
The string @.@.@ tells the :STORE command to back up all the files on the system. This string includes three uses of the MPE wildcard character @. MPE uses the @ in much the same way that UNIX or MS-DOS use the asterisk (*) to represent all the files. Table 1 shows some examples of how @ might be used.

Shortly after the above :STORE command was entered, a message appeared on the console, as we saw above. When the operator mounts a tape (or cartridge) and responds to the message using an =REPLY command, :STORE begins copying the files to the tape.

Table 1: Uses of @
@ Denotes all the files in the current group and account.
@.@ Denotes all the files in all the groups in the current account.
@.@.@ Denotes all the files in all the groups in all theaccounts on the system.
f@ Denotes all the files beginning with the letter f.
@.@.AD@Denotes all the files in all the groups in all accounts whose names begin with AD.
x@2 Denotes all the files beginning with x and ending with 2.
George Stachnik, the director of Hewlett-Packard's Technology Closeup series of television broadcasts, holds the title of Chief of Customer Communications. He works at Hewlett-Packard's campus in Cupertino, California.

Previous articles in George Stachnik's series Managing HP 3000 Systems--for Complete Novices (June, July, August, and October 1997 issues of Interact) appear on the Interex Web site.
  ←Part 4  Part 6→
⇑   ⇐   [3khat]3kRanger   [3khat]3kMail   Updated