⇓   ⇐
  ←Part 2  Part 4→
by George Stachnik

In the first two articles of this series, we focused on accounts, groups, POSIX directories, and files. These make up the framework of your MPE system. In this article, we'll begin to turn our attention to the practical tools that you use to manage that framework and the programs that operate in it. We'll begin with one of the most important system management tools available to the HP 3000 system manager: MPE program capabilities.

If you're the system manager of one or more HP 3000s, it's your responsibility to make sure that the system and its resources are always available to your end users when they need it. In that context, there are a number of important questions you should be asking yourself. For example: We will begin to explore the answers to these questions in this article (and in the remainder of this series). We'll first discuss the most basic (and powerful) tool set in the MPE system manager's arsenal--MPE program capabilities.

Table 1 contains a list of all 21 MPE capabilities supported on MPE/iX. (If you're using a Classic HP 3000, your system supports only 17 capabilities. The last 4 capabilities shown in Table 1 are supported only on PA-RISC models of the HP 3000.) Each capability is identified by a two-character abbreviation. For example, SM is MPE shorthand for system manager capability, PM refers to privileged mode, and so forth.

Each capability acts something like a shutoff valve that can be used to determine what users and programs can and cannot do on your system. If you or a program you are executing is associated with a certain capability, that means you can do things you would not be able to do without it. Every MPE user is associated with his or her own capability list, assigned when the user is originally defined. Similarly, every MPE account, each MPE group, and each executable (that is, every program file) on your HP 3000 has a capability list. You can see these lists using MPE commands. For example, Figure 1 shows the LISTACCT command being used to display the capability list associated with an account called STACHNIK on my system.

Figure 1: The :LISTACCT command

Accounts and users can have any combination of the capabilities listed in Table 1. When the system manager creates an account (see Part 1 of this series, published in the June 1997 issue of Interact), he or she can, at that time, specify a list of capabilities using the CAP= parameter of the NEWACCT command.

Similarly, a capability list can be associated with a user name by specifying the CAP= parameter of the NEWUSER command. The system manager has the option of changing his or her mind and altering the capability list associated with an existing account or user. This can be done by using the ALTUSER or ALTACCT command. Capability lists are specified using the CAP= keyword for all of these commands.

The situation for MPE groups and programs is similar but somewhat more restrictive. The first six rows of Table 1 are special in that these capabilities (and only these) can be assigned to MPE programs and groups. These six program capabilities are IA, BA, DS, PH, PM, and MR. This month, we are going to focus on these six capabilities. (We'll return to this subject next time and cover the remaining user and account capabilities).

The default capabilities for groups and programs are IA and BA. In other words, when you create an MPE group (using the :NEWGROUP command), you will also automatically create a capability list for that group. If you don't use the CAP= keyword of the :NEWGROUP command to specify which capabilities you want assigned to the group, then by default your new group will have only two capabilities--IA and BA. Similarly, if you're a programmer and you write a program for the HP 3000, your program will have only IA and BA capability unless you specifically assign additional program capabilities.

Table 2 contains a list of the six program capabilities and a more detailed description of how each is used. Since IA and BA capabilities are the defaults, the only groups and programs on your system that will not have them are ones in which the system administrator or programmer has specifically disallowed them. So, let's begin our examination of capabilities by seeing what IA and BA allow you to do.

IA and BA Capabilities

In the first article in this series, we briefly mentioned that there are only two ways programs can be executed on the HP 3000, interactively or in batch mode. MPE users typically use the system interactively by logging on using a :HELLO command. This establishes a session, during which the user can execute programs and interact with them (performing tasks such as entering transactions, looking up information in databases, and so forth). A person logged on as a session can execute programs using the :RUN command (or in a variety of other ways we'll discuss in a future article.)

However, you may not want some tasks handled interactively. For example, sorting a file of a million records or compiling a large COBOL program is typically not done interactively. Not only would it take too long but these tasks could put a performance burden on your system that might be unacceptable to you, especially at busy times of day.

On MPE systems, long, time-consuming tasks are often handled using batch jobs. A batch job is probably best described as a canned session. It's defined using a small file that contains a series of MPE commands. This file can be created using an editor (MPE's own editor will work, although it's rather old-fashioned.) You can use your favorite desktop editor just so long as you have a way to transfer the file from your workstation to the 3000. (We'll discuss the mechanics of this in a future article).

The commands that you want your batch job to execute are sandwiched between a !JOB statement and an !EOJ (end-of-job) statement. (See Figure 2.) In this example, the job will log on to the system using the same user and account I specified in my :HELLO command when I logged my session onto the system. In the figure, user, account, and passwords are specified as part of the !JOB statement. Note that I've censored the passwords because this is my actual system and my actual account. In fact, the passwords can be left off the !JOB statement altogether under certain circumstances. (We'll discuss these in a future article.) Once the job logs on to the system, it will execute the commands that follow the job statement--in this case, it will run the SORT program and then use the TELL command to send us a message saying that the job worked properly.

Figure 2: Streaming a batch job

Batch jobs are entered into your HP 3000 using the :STREAM command. Figure 2 shows how you use the :STREAM command to submit the job to the system. Note that MPE assigns a unique job ID number to my job (#J94). Once the job has logged on to the system, it executes the SORT and the TELL commands (note the message that comes from J94 displayed on my screen when the SORT has finished). The management of batch jobs is a science unto itself (one that we'll get to in a future article), but for now, we need to focus on only one aspect of it. How can you control which programs are executed interactively and restrict some programs to a batch environment?

This question is important because the HP 3000 executes batch jobs in the background. This limits the impact that batch jobs have on your system's performance. For example, suppose you need to perform some heavy resource-intensive tasks such as sorting million-record files or printing large reports. If you do those while logged on interactively, other users who are trying to work at the same time may find that suddenly the computer seems to be slowing down. These kinds of tasks should be handled in batch mode where they are much less likely to have a performance impact on other users. IA and BA capability make it possible for you to control whether or not a particular program can be executed interactively or in batch mode.

When a program is created for use on an HP 3000, one of the final steps the programmer takes is to assign a list of capabilities to that program. As we saw in Table 2, there are only six program capabilities from which to choose. By default, both IA and BA capabilities will be assigned, but the programmer can assign other combinations.

If the programmer allows both IA and BA to be assigned, then the program can be executed either interactively (from a session) or in batch mode (from a job). If the programmer chooses to remove IA capability (leaving BA), then the program can be executed only from a batch job. An interactive user trying to execute a program that does not have IA capability would receive an error message. Similarly, if the programmer chose to remove BA capability (leaving IA), the program would be executable only by online sessions.

Note that the program's capability list is being checked here--not the user's capability list. In other words, if a program has BA capability (but not IA), the program can be executed only in batch mode, regardless of whether or not the user who is trying to execute the program has IA, BA, or both. The user's capability list is used for a different purpose, as we'll see in a bit.

There is, of course, one more option. The programmer might choose to remove both IA and BA capabilities. You guessed it--that means the program could not be executed at all. This may seem pointless (and it is) but it is worth mentioning in this article. You wouldn't believe how many calls the HP Response Center gets each year from people who complain that such-and-such a program won't run, only to discover that the program has neither IA nor BA capability. In a future article on MPE program development, we will discuss the mechanics of assigning capabilities to programs.

DS Capability

The next capability we examine is DS capability. DS is used to allocate additional memory for programs that may need it, and as with many of the HP 3000's features, there's some history behind this. The original Classic models of the HP 3000 were 16-bit machines. This means that when you ran a program on a Classic HP 3000, roughly 128 KB of RAM was set aside for use by that program. This block of RAM is called the stack, and in 1972 (when MPE was originally designed), 128K was a staggeringly large amount of memory. It seemed ridiculous to think any application would ever need more than that.

Well, even MPE engineers make mistakes. Before long, it was clear that some programs were going to need more than their allotment of 128K. So, the MPE engineers created something called extra data segments. Programmers creating applications that needed more than their 128K allotment of memory could use a series of special MPE interfaces called intrinsics (similar conceptually to UNIX system calls) to allocate more than 128K.

Now keep in mind that in the 1970s and early 1980s, RAM was an expensive resource, and HP 3000 systems didn't have very much of it. System administrators were, therefore, suspicious of programs that could get more than their fair share. If an entire system has only 1 or 2 megabytes of RAM (keeping in mind that those 1 or 2 megabytes are shared by all your users), then you can see why it could be very dangerous to allow some programs to go back for a second helping. So, system managers told HP, We need a way to control which application programs can use extra data segments and which ones cannot. And that's just what DS capability is all about. Programs that have DS capability can use intrinsics to allocate additional memory in the form of extra data segments. Those that don't have it cannot.

Of course, today's PA-RISC models of the HP 3000 have very large memory configurations, and when a native-mode program runs on a PA-RISC model, a stack is allocated for it. However, the size of the stack is measured in multiple megabytes--it's much larger than it was on the older Classic systems. So, you may be wondering, What's the point of extra data segments today?

The answer is simple--upward compatibility. Many HP 3000 applications continue to operate in compatibility mode, even today, at least part of the time. When an HP 3000 executes a compatibility-mode application, a 128-KB stack is allocated for it, just as it would have been allocated on a Classic system. Compatibility-mode applications are running as though the system were still fashioned from 16-bit hardware (albeit very fast 16-bit hardware). The extra data segment facility continues to work as it always has in order to provide compatibility with the old Classic MPE hardware.

PH Capability

PH stands for process handling. Whenever a program is executed on an HP 3000, a process is created on behalf of the program. The term process is best understood as an event, rather than as an object. A process lasts as long as the program is executing, and it disappears when the program terminates. A process is the event of a particular program being executed at a particular time by a particular user. Each process does have a number of things associated with it. These include large objects in memory (like the stack and possibly extra data segments) as well as entries in the system tables to keep track of the process.

From a programmer's point of view, each process represents a single thread of execution. If a user (let's call him George) is executing a program, you can think of George's process as a little man (or woman, if you prefer) threading his or her way through the instructions of that program. The important point is that there is only one little person for each process. George is doing his work serially, one instruction at a time, in a prescribed order.

Most tasks--for example, balancing a checkbook, changing a tire, or building a model airplane--are best thought of as a series of steps you perform serially, one at a time, in a prescribed order. But you also can handle some tasks more efficiently in parallel, doing more than one thing at a time. For example, cooking Thanksgiving dinner involves performing several tasks simultaneously. You usually get the turkey started, and then while that's cooking, you turn your attention to the vegetables, or the rolls, or the other dishes. At any given moment, you're juggling multiple tasks. If you didn't cook the dinner that way, the mashed potatoes might be ready an hour before the turkey, which isn't what you want.

Similarly, some programming tasks are best handled in parallel, and one way of doing this on the HP 3000 is to use multiple processes. Using MPE intrinsics, you can design programs in such a way that they run other programs in turn, thus creating other processes. The HP 3000 executes them all simultaneously.

Juggling multiple processes at the same time is often called multitasking, and it is not unique to the HP 3000. UNIX programmers have long been using the fork and exec system calls to achieve similar results. MS-DOS programmers are more inclined to think of multitasking as some kind of exotic new technology, since few MS-DOS applications use it. Support for multitasking is much stronger in the newer PC-based operating systems such as Windows 95 and NT. MPE has supported multitasking from its inception, and the intrinsics used to create and manage processes are collectively referred to as the process handling intrinsics.

Consider the implications of process handling from a 1970s system administrator's point of view. We saw that system administrators were suspicious of programs that used extra data segments, because they could get more than their share of the system's memory resources. So, imagine their attitude toward process handling. Programs that can spawn additional processes can not only take up additional memory resources but also additional CPU. Just as DS capability is required for a program to be able to use extra data segments, PH capability is required for a program to be able to create additional processes.

MR Capability

MR has the distinction of being an acronym buried within an acronym. MR stands for multiple RIN, and to understand what multiple RINs are, we must first understand what RINs are. RIN is an acronym for resource identification number, and to explain it, I'll give an example of how it might be used.

Suppose you have an application being run by thirty users simultaneously. If the software that one of the end users is running encounters an error, you would normally want to display that error message on a terminal. Of course, you could display it on the end user's terminal, but end users tend to be nontechnical people, and they're inclined to just ignore error messages they don't understand and go on with the business of trying to get their jobs done. So let's suppose that this application writes all the error messages to a special terminal. Nobody actually logs on to this terminal--its sole purpose is to receive error messages coming from the application. It might sit on the system operator's desk, next to the system console.

This sounds like a good idea, until something goes wrong that affects all your end users--something like running out of disk space, for example. When this happens, the users will all try to write error messages to the message terminal at the same time. Instead of helping to sort out the situation, this can actually make it worse. The messages can overlay one another or get garbled in such a way as to make it impossible to figure out what's going wrong. The answer is to give the application program a way of controlling the use of this terminal. This is achieved by forcing each user to reserve the error message terminal before writing the message to it. In this way, if all thirty end users encounter an error at the same time, they can queue up and write their error messages one at a time.

To make this scheme work, the system administrator assigns a particular resource identification number (RIN) to the error message terminal. Before an application program can write an error message to the terminal, it first reserves the RIN (using an intrinsic), which is its way of saying, I'm using the error message terminal. Nobody else can write anything to it until I'm done! Then it writes the message--and finally frees up the RIN, effectively saying, OK, I'm done.

In the early days of MPE, RINs were widely used to lock a variety of system resources--terminals, files, records within files, and so forth. Today, the RIN mechanism has largely been replaced by other mechanisms (for example, specialized mechanisms for locking files, databases, and parts of databases). In order to maintain compatibility, however, the RIN mechanism is still around, and it's used primarily by older applications.

Now that you understand what a RIN is, what is MR capability? You don't need a special capability to lock down a RIN. Any program is permitted to do that. But you do need MR capability to lock down more than one RIN at a time. The reason is that locking down multiple RINs opens you up to the deadly embrace problem. A deadly embrace results when two programs try to lock two different RINs at the same time. An example will serve to show how dangerous this can be. Suppose we have two programs (we'll call them MOE and LARRY) and two RINs that we'll call #1 and #2. Now suppose that MOE locks RIN#1 and tries to lock RIN#2. Ah, but LARRY is using RIN #2, and so MOE must wait until LARRY is done. But LARRY (who, remember, has RIN #2 locked) is also trying to lock up a RIN. Guess which one? You guessed it--#1. So what's going to happen? MOE will wait until LARRY frees up #2. But LARRY's not going to free up #2 because he's waiting for MOE to free up #1. But MOE's not going to free up #1 until LARRY frees up #2, but LARRY . . . . Well, you get the idea. This situation is so dangerous that computer scientists have given it a special name--the deadly embrace.

The only way to break out of a deadly embrace is to cancel both users (which may entail rebooting the system!). It takes careful thought on the part of application designers to avoid these deadly embrace situations, so the MPE architects require that only programs with MR capability can hold more than one RIN.

PM Capability

Of the six program capabilities, PM is the most dangerous. PM stands for privileged mode. A program that has PM capability has the same access to your system as MPE itself. PM programs can access system tables (or corrupt them!) and read (or change!) the names of the accounts, groups, and files on your system (including the passwords!). If that's not enough to terrify you, when PM programs go awry (and they do), they can take down your system--even force you into a reload.

Most operating systems have a mode similar to privileged mode. Whether it's called Supervisor State (IBM's name for it), SuperUser (the UNIX name), or something else, the principle remains the same. System integrity is meaningless if access to this mode is not strictly controlled. Simple application programs do not (or at least should not) require PM capability. Of course, there are exceptions. Many software vendors have used PM as a means of engineering programming shortcuts to give their applications a performance boost or some other feature. If you're an application vendor, this is one way to differentiate yourself from your competitors, but it is dangerous. PM programming practices that work on one release of MPE may fail on the next release, potentially causing system aborts and data corruption.

In an effort to bring some standardization to the use of PM, HP has introduced a series of application program interfaces called architected interfaces, or AIFs. These interfaces are like intrinsics in most respects, but unlike them, they allow you to perform tasks like accessing the accounting structure, passwords, and other security features. Therefore, AIFs can be used only by programs with PM capability.

Controlling Which Programs Have Program Capabilities

It's clearly important for you, the system administrator, to control the six program capabilities, particularly PM. Consider this scenario. One of your users goes to a trade show, where he meets with other HP 3000 users. He comes back with an HP 3000 store tape full of interesting software, including a program called HACK. This program, written by an HP 3000 hacker, was designed to read the HP 3000 accounting structure and print out a report of all the passwords on your system. What can you do to protect yourself and your system from programs like HACK?

The first line of defense is to keep such programs off your system. In the good old days, this was relatively easy to do. By restricting access to the tape drive, you could protect yourself from errant software, because tape was the only medium that could be used to copy large binary objects like programs onto the HP 3000. With the tape drive safely locked away in the glass house of your data center, you were safe from programs like HACK.

In today's world of networked computers and desktop workstations, though, this is no longer enough. Programs like HACK are usually distributed on floppy disks or ZIP drives, where they can be loaded onto a programmer's desktop computer and then copied across the network to your HP 3000. Indeed, on most UNIX systems, once a program like HACK is on your system, there is little you can do to stop people from running it. Fortunately, your HP 3000 system gives you one more tool.

Remember that the six MPE program capabilities can also be associated with MPE groups. There's a good reason for this: An MPE program that has been created with a special capability such as PM cannot be executed on an HP 3000 unless it resides in a group that also has the capability. So, if your user comes back from a trade show bearing a PM program like HACK, even if he can figure out a way to get it onto your system, he cannot run it unless he can get it into a group that has PM capability.

Therefore, as a system administrator, one of the most important things you can do to ensure the integrity of your system is to monitor and control the list of groups that have PM capability. Normally, this list should be very short. System groups such as PUB.SYS must have PM capability, and one or two groups in the TELESUP account also need it. Some application programs may need it, depending on how clever your application vendor has been. But end users should not have save access or be able to copy programs into these groups. All of these groups should be read-only to everybody but the system manager himself. The real danger lies in the end users' and programmers' home groups--places where they can store data of their own. In other words, any group that users can write to which also has PM capability is a potential time bomb on your HP 3000.

From time to time, good MPE system administrators should print out a report showing all the groups on their systems and highlighting the ones that have PM. You can do this with a batch job that does a :LISTGROUP @.@, but there are utilities and shareware programs (including some in the Interex Contributed Software Library) that make this job much easier.

In Part 4 of this series, we'll continue our discussion of capabilities by examining the remaining ones and learning what it means when they are assigned to a user or an account.

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.
  ←Part 2  Part 4→
⇑   ⇐   [3khat]3kRanger   [3khat]3kMail   Updated