Managing the HP 3000 Part 2

⇓ ⇐

by George Stachnik

For compatibility reasons, MPE XL continued to use the rules and conventions of the Classic MPE V file system when it appeared on PA-RISC systems in the late 1980s. The HP 3000's file system began to more closely resemble the UNIX file system in 1992, when Release 4.5 of MPE/iX superseded the Classic file system with the more UNIX-like Hierarchical File System (HFS).
It's important to understand that although the HP 3000 has been modernized over the years, many HP 3000 applications have not. Most MPE applications were designed and built under the constraints of the Classic MPE V file system. Just as fleas in a flea circus will not jump out of a jar when the lid is removed, most MPE applications continue to adhere to the rules of the Classic file system. For this reason, we'll begin our introduction to the MPE file system with an explanation of the Classic file system structure and its rules.
On the HP 3000, data and programs are kept in files, much as they are on UNIX systems or on PCs. At the end of each month, our hypothetical time-sharing system manager can easily determine how much of his disk space is being taken up by files belonging to each of his clients (i.e., how many megabytes are being occupied by the users in each account) so they can be equitably billed based on resource utilization.
The Classic MPE file system is a simple three-level hierarchy, with all files residing at the third (lowest) level. At the top of the hierarchy is an arbitrary number of accounts. Each account in turn acts as a directory pointing to an arbitrary number of subdirectories that are called groups in MPE terminology. To learn about how the :LISTFILE command can be used to display information about the files in MPE groups, see the section entitled Files and Disk Space.
Figure 1 shows the accounting structure for a hypothetical time-sharing HP 3000. At the bottom of the figure are the files. For example, the lower right-hand corner of the figure shows two files named MYFILE and FILE1. The top of the figure shows the accounts, including those belonging to TOM, DICK, and HAROLD. The HAROLD account contains a number of groups, including three that are called GCURLY, GLARRY, and GMOE in this example. The HAROLD account also contains three corresponding users named MOE, LARRY, and CURLY.

Figure 1: The "Classic" MPE File System

You'll note that in this example we've set up a one-to-one relationship between the groups and the users. That is, the users MOE, LARRY, and CURLY each have groups that are called (respectively) GMOE, GLARRY, and GCURLY. Typically, every user on an HP 3000 will have a corresponding group called a home group. In UNIX terminology, the home group is similar to the idea of a user's working directory. So, for example, let's assume that the system manager has set up the GMOE group as MOE's home group. This means that when MOE logs on to the system (using the command :HELLO MOE. HAROLD), his session will automatically be associated with the GMOE group of files.
Whenever you log on to an HP 3000, your session must be associated with a group. Normally, this will be your home group. There's no rule that says every user has to have a home group (although that is the way things are usually done). If the system administrator does not assign a home group to a particular user, that user must specify a groupname at logon time. For example, if CURLY.HAROLD had no home group, then he'd have to include the name of one of the groups in the HAROLD account in his :HELLO command in order to log on. For example, :HELLO CURLY.
HAROLD,GMOE would begin a session for CURLY but would associate it with MOE's group.
Now, you might be thinking to yourself that MOE might not want to allow CURLY to log on to his group. After all, MOE's group contains MOE's files, and CURLY might not have any business looking at them. For this reason, groups can have passwords associated with them. If a group has a password, users will be prompted for it at logon time, with one exception: If you're logging on to your home group (i.e., if you don't have to specify the groupname when you log on), then you won't be prompted for the group password. For more information on how to display passwords and other information relating to groups, see the section entitled Listing Groups.
By the way, you may have noticed that in the figure, all the groupnames begin with G. Don't let that confuse you; there's no rule that says groupnames have to begin with a G or with any other letter. I have just done it that way here to avoid confusion between usernames and groupnames.
Groups contain pointers to files. In the Classic MPE file system, files can reside only within groups. Groups contain nothing but files, and groups can reside only under accounts. Similarly, accounts contain nothing but groups, and accounts can reside only under the root.
If you have UNIX, MS-DOS, or NT experience, you might be thinking that there are a number of obvious parallels between MPE groups and the concept of directories in those other operating systems. Groups and directories are similar; both are ways of grouping together files. But there are also many important differences. For example, the UNIX and MS-DOS directory structures can be many levels deep, with directories containing subdirectories, those subdirectories in turn containing more subdirectories, and so on. The Classic MPE accounting structure is limited to only three levels--accounts, groups, and files.
Similarly, MPE accounts have much in common with UNIX or MS-DOS directories. But keep in mind that MPE's accounts and groups contain more information than the file directories found in UNIX or MS-DOS. Under those other operating systems, directories contain collections of pointers to other directories and files, as well as permission bits that determine who has access to each file. But MPE accounts and groups also contain information about users, passwords, quotas, capabilities, and more.
If you have a UNIX background, Classic MPE's two-level hierarchy might seem confining. Actually, the Classic file system is considerably more restrictive than we've seen so far. For example, under Classic file system rules, all filenames, groupnames, and accountnames can be no longer than 8 characters.
Classic MPE filenames share this 8-byte limitation with older versions of MS-DOS and MS WINDOWS. (MS-DOS's three-character filename extension is not used in Classic MPE.) As is the case with MS-DOS, uppercase alpha and numeric characters are the only kind that can be used in Classic MPE filenames.
Security is even more restrictive. In the UNIX and MS-DOS file systems, a user can have access to files in any directory on the system. Under MPE, most file access is restricted to your own logon account. So, for example, a user logging on as MOE.HAROLD would have access to files in the HAROLD account, but not in other accounts on the system.
Compared to the relatively free-form conventions of the UNIX file system, the Classic MPE file system was restrictive indeed. Returning to Figure 1 for a moment, note that in addition to the TOM, DICK, and HAROLD accounts, there's also an account called SYS. Every MPE system has a SYS account--it's where all the files associated with the system (not with any client's account) are kept. The files that make up the MPE operating system itself reside in the SYS account. Like other accounts, the SYS account has a number of groups in it, and SYS files are stored in these groups. So, for example, most of the software that makes up the MPE operating system can be found in the PUB group of the SYS account.
Figure 1 also shows that the HAROLD account contains, in addition to the GMOE, GLARRY, and GCURLY groups, a fourth group called PUB. Typically, every account contains a PUB group. Usually, PUB groups contain files that are shared among all users of that account. Programs that are sharable among the users of an account are often stored in the account's PUB group.
Classic MPE's three-level hierarchy uses a relatively simple file-naming convention. Referring once again to Figure 1, suppose that you are logged on as CURLY.HAROLD, and your session is associated with the GCURLY group (your home group). The figure shows that the GCURLY group contains two files called FILE1 and MYFILE. Because these files reside in the group that you're logged on to, you can refer to them as FILE1 and MYFILE. So, if you wanted to display the contents of FILE1, you could use MPE's :PRINT command to do so by entering the command
:PRINT FILE1
But suppose you wanted to print the contents of a file in another group. For example, Figure 1 shows a file called QUERY that resides in the PUB group. You cannot refer to this file simply as QUERY because MPE would assume that you were trying to refer to a file called QUERY in your logon group (i.e., in the GCURLY group). You'd have to refer to QUERY as QUERY.PUB--that is, you'd have to include the groupname. So, for example, to run a program that's stored on your system in this way, you'd enter the command
:RUN QUERY.PUB
Or simply,
:QUERY.PUB
Suppose you wanted to refer to a file in another account. For example, as seen in Figure 1, there's a file in the PUB group of the SYS account called COMMAND. COMMAND happens to be a program, bundled with every HP 3000, that can be used to examine the contents of TurboIMAGE databases. If you wanted to run this program, you could do so by calling it by its fully qualified name.
COMMAND.PUB.SYS
The fully qualified name of a file consists of its filename, groupname, and accountname, in that order, separated by periods. You must use the fully qualified filename when you are referring to files in accounts other than the one you are logged on to. If you want to refer to a file that's in a group other than the one that you're logged on to (but in your logon account), then you must refer to it by its filename, followed by its groupname, separated by periods (e.g., QUERY.PUB).
Let's next turn to the users shown in Figure 1. The HAROLD account has a user who has logged on as MGR. HAROLD. Each account has a special user called the account manager. The account manager is often named MGR.<accountname>. Account managers have special privileges not extended to ordinary account users. Let's look at an example.
Ordinary account users like CURLY. HAROLD can usually read and write the files and programs stored in their own groups. They can also read (but not write) the files in the PUB group of their own accounts or in the PUB group of the SYS account (PUB.SYS). But the account manager, MGR.HAROLD, can read and write files in any of the groups in the HAROLD account. Furthermore, MGR.HAROLD has the capability of creating and deleting users and groups in his or her own account. So, for example, MGR.HAROLD can create or delete users in the HAROLD account, but not in the TOM or DICK accounts.
The SYS account is managed by a user typically named MANAGER.SYS, who has all the capabilities of an account manager plus the ability to create or delete other accounts. In this example, TOM, DICK, and HAROLD were created by MANAGER.SYS. To see how this is done, see the section entitled Creating, Deleting, and Altering Accounts and Groups.
Today, typical MPE systems have one or more accounts associated with each application on the system. In addition, there is also an account called TELESUP which contains software used by HP support.
Finally, let's turn our attention to the POSIX environment. We've seen that the Classic MPE file system is somewhat restrictive when compared to UNIX. UNIX allows filenames to be longer than 8 characters and to include lowercase characters. UNIX allows a directory structure that is much deeper than Classic MPE's three-level hierarchy. But, more important, by 1991 most of the program development going on in the commercial arena (especially within Hewlett-Packard) was being done on UNIX workstations like the HP 9000 Series 700. Software written for UNIX could not be easily ported to the HP 3000 because of differences in application program interfaces (APIs) and differences in the file system.
In the 1980s, the Institute of Electrical and Electronic Engineers (IEEE) had set up a series of committees (the POSIX committees) to attempt to standardize UNIX. Although this effort is widely viewed as a failure today (at least in the UNIX community), HP and other vendors of proprietary systems, including IBM and DEC, were able to leverage IEEE's work. By 1995, virtually all of the big proprietary operating systems available from these vendors (IBM's OS/400 and MVS, DEC's VMS, and HP's MPE) were mostly compliant with POSIX.1 and POSIX.2. This means that all of these operating systems (as well as most UNIX systems) supported the same C compiler and the same basic APIs from that compiler. All provided support for a UNIX-like file system structure and naming convention, and all supported a UNIX-like shell program compliant with IEEE 1003.2. For an overview of how this works on the HP 3000, see the section entitled The POSIX Environment.

Files and Disk Space
When you log on to an HP 3000, you must specify a username and accountname as part of the :HELLO command that logs you on. If the user you specify has a home group, your session will automatically be associated with that group. Otherwise, you'll have to specify a group as part of your :HELLO command. Either way, your session will be associated with an MPE group.
MPE's :LISTFILE command can be used to display the names of the files in your group or in other groups on the system. Figure 2 shows the simplest form of the :LISTFILE command, which simply lists the names of the files in your group. Used in this way, :LISTFILE is roughly analogous to MS-DOS's DIR command or UNIX's ls shell command.

Figure 2: Displaying Filenames

:LISTFILE is a fairly versatile command. For example, it can be used to display more details about each file or to list the names of files in groups other than your logon group.
To display the names of files in groups other than your logon group, you can use MPE's wildcard characters, the most common of which is the at sign (@). This symbol is used to represent large collections of files in much the same way that the asterisk (*) is used in MS-DOS or UNIX. For example, if you wanted to use :LISTFILE to display a list of the names of all the files in the PUB group of the SYS account, you'd enter the command
:LISTFILE @.PUB.SYS
Use the @ wildcard character to qualify the names of files to be displayed. The table provides a few examples of ways the @ wildcard character can be used with the :LISTFILE command.

Table 1: Using Wild Card with LISTF
Command Action

:LISTFILE F@ Lists all the files in your logon group with names beginning with "F"

:LISTFILE @Q Lists all the files in your logon group with names ending in "Q"

:LISTFILE @X@ Lists all the files in your logon group with names containing an "X"

:LISTFILE MYFILE.@ Looks for files called "MYFILE" in all the groups in your

logon account

:LISTFILE MYFILE.@.@ Looks for files called "MYFILE" in all the groups in all the accounts

on the system (might take a while!)

By default, :LISTFILE lists only filenames. So, for example, suppose you enter the command
:LISTFILE MYFILE.@.@
MPE will dutifully search every account and group on the system for a file called MYFILE. (Note that this may take a while!) If it finds one, it will display its name--MYFILE. It will not display the name of the group or account in which MYFILE was found. This can be particularly irksome if MPE finds multiple files called MYFILE. For each file it finds, it will simply display the word MYFILE--once for each file found--and it will not display the name of the account or group in which the file or files were found.
This may not be exactly what you had in mind. If you were going to go to all the trouble of searching every account and group on the HP 3000 for files called MYFILE, you probably would want MPE to tell you what groups and accounts it had found them in. You might also want to know more about the files, such as how many bytes each file was taking. This is done by telling the :LISTFILE command to display additional levels of information. This is most commonly done using a level number. For example, to tell :LISTFILE to display level 2 information, use the command
:LISTFILE,2
This tells MPE to display the names of all the files in your logon group and to display level 2 information about the files it finds there. Figure 3 gives an example of the level 2 option being used in tandem with the @ wildcard. The command in Figure 3 tells MPE to list level 2 information about all the files in the PUB group of the SYS account. The command is
:LISTFILE @.PUB.SYS,2
Figure 3: Displaying Filenames*More Information

Level 2 reports the names of the accounts and groups being displayed in a header. It then displays one line of information for each file that meets the criteria specified in the command, with the filenames listed in the left-hand column under the heading FILENAME. The example in Figure 3 shows the first dozen files in the PUB group of the SYS account. The files are displayed in alphabetical order. The size of each file is displayed on the right under the heading SECTORS. One sector is equal to 256 bytes.
The column headed CODE often gives valuable information about the kind of information stored in this file. In Figure 3, the file named ADSF has a code of NMPRG, which means that ADSF.PUB. SYS is a native-mode program file. This is an executable program that has been compiled specifically for use on PA-RISC models of the HP 3000. By contrast, the file called ADVWCONV has a code of PROG. This code means the file is also executable but was compiled for use on Classic 16-bit HP 3000s (keeping in mind that this program can also be executed on PA-RISC models of the HP 3000 through the use of compatibility mode). For more details, see the sidebar entitled The HP 3000: Where Did It Come From? Where's It Going? in Part 1 of this series of articles in the June issue of Interact.
The columns headed LOGICAL RECORD have to do with the internal structure of the file. The columns headed #X and MX have to do with the way the file is physically stored on disk. (We'll discuss this information in detail in a future article.)
Creating (or building) new files on MPE is accomplished using the :BUILD command. The simplest form of the BUILD command is shown in Figure 4. The command being entered is
:BUILD MYFILE
Figure 4: Creating a New File

This command creates a new file in your logon group and account. As seen in Figure 4, we then enter the command
:LISTFILE MYFILE,2
This command displays the characteristics of the file we've just created. Note that initially the file does not take up any disk space. You can think of it as an empty shell waiting to house data. In a future article, we'll show how to use programs to write data into a file.

Listing Groups
MPE provides two commands that can be used to display information about groups. Figure 5 provides an example of the :LISTGROUP command. As you can see, the group password is displayed at the top of the right-hand column. As is the case with account passwords, you may not be authorized to display your own group password. (More detailed information on this appeared in the sidebar Listing Accounts and Users in Part 1 of this series of articles in the June Interact.) The total amount of disk space occupied by files in the group is displayed at the top of the left-hand column next to the heading DISC SPACE.

Figure 5: Displaying Information About a Group

Below that are the accumulated CPU and CONNECT times for sessions associated with this group. Whenever you log off the system, the total CPU and CONNECT times logged by your session are added to accumulators at the group and account levels. Below those times are the quotas or limits on CPU time, connect time, and disk space. In this example, there are no limits imposed on this group.
Figure 6 shows sample output for the :REPORT command, which is useful when you need to look at the accumulated time and disk space for large numbers of groups. The figure gives an example of how an account manager might use the :REPORT command to display the numbers for all the groups in a particular account. In this case, the STACHNIK account is being displayed. It has three groups: BIN, PUB, and TEST. The columns headed FILESPACE-SECTORS, CPU-SECONDS, and CONNECT-MINUTES show the amount of space and time that have been used by files and sessions associated with each of these three groups. The top line (with the heading STACHNIK) shows totals in the account as a whole. You may note that the totals don't add up. This is caused by discrepancies introduced with POSIX, discussed later in this article.

Figure 6: Simple Resource Accounting

Creating, Deleting, and Altering Accounts and Groups
If you have system manager privileges on an HP 3000, you have the capability of creating, deleting, and altering accounts and groups. Figure 7 shows the mechanics of creating, purging, and altering accounts and groups.

Figure 7: Creating and Deleting Accounts and Groups

The :NEWACCT command is used to create a new account. In order to use the :NEWACCT command, you must be signed on as the system manager. The example in Figure 7 shows the creation of a new account called MOJO.
Every account must have a special user associated with it called the account manager. When you're signed on as the account manager, you can create or delete users and groups within your account. The account manager's username must be specified when you create the account.
In the figure, we specified the username MGR. So, the command shown in the figure creates not only the MOJO account but also the user MGR.MOJO, giving account manager privileges to this user. MGR.MOJO will have the ability to create or delete users and groups within the MOJO account.
Figure 7 also shows the MOJO account being purged using the PURGEACCT command. Once again, you cannot purge accounts unless you have system manager privileges. Note that MPE does not allow an account to be purged without first double-checking that this is really intended. When an account is purged, all users, groups, and files within that account are also simultaneously purged.
Figure 7 shows something else, too--the mechanics for creating and purging groups. Remember that in order to be able to create or purge a group, you must be signed on as the account manager. The commands for creating and deleting groups are :NEWGROUP and :PURGEGROUP, respectively.
Finally, Figure 7 contains an example of altering the characteristics of an account. The figure shows how to change the password associated with the STACHNIK account to BATMAN. The command used for this purpose is :ALTACCT, and it can be used only by users with system manager privileges.
The :ALTACCT command can be used to alter and display many other account characteristics such as quotas, the security matrix, and user capabilities. In a future article, we'll examine each of these characteristics in detail.

The POSIX Environment
If you have a UNIX background, you'll be glad to know that many of the shell commands you learned on UNIX systems can also be used on the HP 3000. As we've seen, Classic MPE/iX uses a highly restrictive file-system architecture and a proprietary command language. These are unique to the HP 3000.
In Release 4.5 of MPE/iX, the system was enhanced to support a common set of UNIX-like APIs, a UNIX-like command language, and a standardized directory structure. Figure 8 shows some of the ways the Classic MPE file system changed with POSIX. Compare this example with the Classic MPE file system in Figure 1.

Figure 8: Extending the "Classic" File System with POSIX

The first change to note is that filenames are no longer restricted to the 8 uppercase-alphas-and-numerics conventions of Classic MPE. Examples can be seen in the lower right-hand corner of Figure 8, where a file has been created bearing the 14-character-long name this_is_a_file.
The second change shown in Figure 8 is that a new kind of file called a directory is now supported on MPE/iX. The figure shows that a directory called my_little_directory has been created in the GCURLY group. An MPE directory can be used to group together files and other directories in the same kind of hierarchical structure found on UNIX and MS-DOS systems. In the figure, my_little_directory is part of the GCURLY group and contains two files called my_first_file and my_ second_file.
The third change is that files and directories can now be placed in other locations in the hierarchy besides groups. For example, a file called harolds_file now resides in the HAROLD account, even though it's not part of any group in the account. Rather, it is attached directly to the account.
Finally, files and directories can be created so they do not belong to any account on the system. In the upper right-hand corner of Figure 8, we see that all the accounts are attached to a directory structure called the root (which is named / following the UNIX convention). A directory called the_roots_dir has been created and attached directly to the root, and files called roots_first_file and roots_ second_file have been attached to this directory.
With the addition of these POSIX enhancements, the MPE/iX file system becomes every bit as flexible as the file systems found on UNIX systems, with many of the same naming conventions in place. Furthermore, it can be used and managed with UNIX-like commands.
Figure 9 gives an example of the use of the POSIX shell on an HP 3000. The POSIX shell is a shell program, not unlike the shell programs (ksh, csh) found on UNIX systems. On the HP 3000, the POSIX shell accepts UNIX-like commands (compliant with the IEEE 1003.2 standard) and executes them. For example, Figure 9 shows two such commands: ls (analogous to the MPE :LISTFILE command) and ls -l (analogous to MPE's :LISTFILE,2). These commands display the files and directories in the current working directory with varying levels of detail.

Figure 9: Using UNIX-like Commands on MPE

One of the virtues of the POSIX environment is that it includes the Classic MPE file system in its scope. In other words, if you're a programmer using the open systems commands and APIs of the POSIX environment, you would expect to be able to access files in the new POSIX directories, such as my_little_directory (see Figure 8). But the HP implementation of POSIX on the HP 3000 also allows you to access (with some restrictions) and manipulate programs and data in the Classic (i.e., proprietary) file system.
The example in Figure 9 shows POSIX commands being used to display the contents of this user's current working directory. But the current working directory being displayed isn't a POSIX directory; it is actually a proprietary MPE group. The POSIX shell program treats MPE accounts and groups as if they were directories. To a POSIX shell user, the entire MPE accounting structure looks like a collection of files and directories, just as you'd find on a UNIX system.
Note that this group contains two files with lowercase names: myfile and test. By default, the proprietary :LISTFILE command would not display these names at all because they do not conform to the rules of the Classic MPE file system. In order to maintain compatibility, :LISTFILE will not display the names of files that do not conform to the Classic file system's rules--at least not by default.
HP decided to blind MPE (at least by default) to files and directories that don't conform to Classic rules for a very simple reason: Most HP 3000 applications were written prior to the advent of POSIX. They continue to run under Classic rules and would behave unpredictably if they were suddenly confronted with long, case-sensitive filenames and directories.
In a future article, we'll cover techniques that can be used to manage the POSIX environment, including files and directories that don't conform to the Classic rules.

Conclusion
In this first article of the series, we've discussed the basic concepts of the MPE accounting structure. Next time, we'll continue in the same vein as we discuss batch jobs, sessions, and security. After that, we'll look at MPE capabilities and the HP 3000's security hierarchy.

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.

**Table 1: Using Wild Card with LISTF**
Command	Action
:LISTFILE F@	Lists all the files in your logon group with names beginning with "F"
:LISTFILE @Q	Lists all the files in your logon group with names ending in "Q"
:LISTFILE @X@	Lists all the files in your logon group with names containing an "X"
:LISTFILE MYFILE.@	Looks for files called "MYFILE" in all the groups in your
	logon account
:LISTFILE MYFILE.@.@	Looks for files called "MYFILE" in all the groups in all the accounts
	on the system (might take a while!)

←Part 1 Part 3→