This chapter describes general management of directories and files.
Directories contain information about files on a volume. If you are on a hierarchical directory volume (such as HFS or SRM), directories have additional capabilities. This section shows how to create and access hierarchical directories such as the directory shown in the following figure. In the figure, directory names appear in boxes, and file names are unenclosed.
First, you should change to the root directory of the default volume by executing MASS STORAGE IS. For example:
MSI ":,700"
or
MSI ":,21,0"
You do not need to specify a /, since the directory path is assumed to begin at the root directory when the volume specifier is included.
This statement creates a directory named CHARLIE in this directory structure:
CREATE DIR "/PROJECTS/Project_one/CHARLIE"
The leading slash indicates that the directory path begins at the root of the hierarchical directory structure. Each subordinate directory is listed from left to right, separated by slashes (PROJECTS/Project_one/). The directory being created (CHARLIE) is listed after the directory path.
You can accomplish the same results using the following two statements:
MSI "/PROJECTS/Project_one"
CREATE DIR "CHARLIE"
Both methods place the newly created directory into the directory structure shown in the following figure.
To create files subordinate to a new directory, either establish the new directory as the working directory, or specify the directory path to that directory. Assuming your current working directory is the root directory, you could type the following statement to move into the directory CHARLIE:
MSI "PROJECTS/Project_one/CHARLIE"
Verify the new working directory with a catalog listing by typing:
CAT [Return]
A typical listing would look something like this SRM example:
PROJECTS/Project_one/CHARLIE:CS80, 700, 0, 0
LABEL: Disc1
FORMAT: SDF
AVAILABLE SPACE: 54096
FILE NAME | LEV | SYS TYPE | RECORD LENGTH | MODIFIED DATE TIME | PUB | ACC | STAT |
To create an ASCII file within CHARLIE that is named ASCII_1 and initially contains 100 records, execute this statement:
CREATE ASCII "ASCII_1",100
To create a BDAT file within CHARLIE, which is named BDAT_1 and initially contains 25 records, execute this statement:
CREATE BDAT "BDAT_1",25
When no record size is specified in the CREATE BDAT statement, the default 256-byte record size is used.
To create another directory within CHARLIE called MEMOS, execute this statement:
CREATE DIR "MEMOS"
The additions make the directory structure look like this:
To list the contents of CHARLIE when your current working directory is not CHARLIE, use one of the following methods:
MSI "PROJECTS/Project_one/CHARLIE:REMOTE"for an SRM disc
or
MSI "PROJECTS/Project_one/CHARLIE:,700" for an HFS disc
then
CAT
CAT "/PROJECTS/Project_one/CHARLIE"
This form assumes that you have already designated remote mass storage with some form of the MASS STORAGE IS statement. If you have not, use the form:
CAT "PROJECTS/Project_one/CHARLIE:REMOTE"for an SRM disc
or
CAT "PROJECTS/Project_one/CHARLIE:,700" for an HFS disc
In the first example, the leading slash is not necessary, because :REMOTE specifies the root as the beginning of the path. In the second example, :,700 is the volume specifier for the HFS disc.
CAT ".."
As a type of file, a directory can be managed in the following ways:
BASIC lets you use wildcards with file system commands. Wildcards is the name given to a set of rules for using expressions as substitutes for file names. For instance, using an asterisk (*) as an argument in a file system command means to execute that command with all the matching files in the current directory. Wildcards can process multiple files by using file name expansion. Wildcards can also reduce typing by using file name completion. BASIC/WS wildcards are similar to wildcards used in the HP-UX operating system, and several options in addition to the asterisk are available. For complete information, see the entry for WILDCARDS in the HP BASIC 6.2 Language Reference.
WILDCARDS is disabled at power-up, and after SCRATCH ALL and Wildcard processing must be explicitly enabled.
WILDCARDS UX;ESCAPE "\" Enable HP-UX style wildcards
WILDCARDS OFF Disable wildcard recognition
Certain file system commands can perform operations on multiple files when WILDCARDS is enabled. These commands are PURGE, COPY, LINK, CHGRP, CHOWN, LOAD BIN, PERMIT, PROTECT (on SRM files only), and CAT. All files that match a wildcard argument are processed by the command. For example, you could use wildcard arguments to process the files in the following SRM catalog listing.
PROJECTS/Project_one/CHARLIE:REMOTE 21, 0
LABEL: Disc1
FORMAT: SDF
AVAILABLE SPACE: 54096
FILE NAME | LEV | SYS TYPE | FILE TYPE | FILE SIZE | NUMBER RECORD | MODIFIED DATE TIME | PUB OPEN | ACC STAT |
AGENDA | 1 | ASCII | 254 | 1 |
24-Apr-90 12:01 | RW | ||
MEMOS | 1 | DIR | 12 | 24 |
22-Mar-89 23:12 | RW | ||
DATA1 | 1 | 98X6 | BDAT | 8 | 256 |
1-Apr-90 14:12 | RW | |
DATA2 | 1 | 98X6 | BDAT | 7 | 256 |
2-Apr-90 14:12 | RW | |
DATA3 | 1 | 98X6 | BDAT | 8 | 256 |
3-Apr-90 14:12 | RW | |
DATA4 | 1 | 98X6 | BDAT | 5 | 256 |
4-Apr-90 14:12 | RW | |
DATA5 | 1 | 98X6 | BDAT | 4 | 256 |
5-Apr-90 14:12 | RW | |
DATA6 | 1 | 98X6 | BDAT | 8 | 256 |
6-Apr-90 14:12 | RW | |
DATA7 | 1 | 98X6 | BDAT | 6 | 256 |
7-Apr-90 14:12 | RW | |
DATA8 | 1 | 98X6 | BDAT | 5 | 256 |
8-Apr-90 14:12 | RW |
NOTE |
---|
PURGE "Data*" erases all files in the directory path designated that begin with DATA (eg. Data1, Data2, Data3). Before you execute a command using a wildcard, be certain you want to affect all files designated. |
To copy all of the files prefixed by DATA to /PROJECTS/Project_one/JOHN, type:
COPY "DATA*" TO "/PROJECTS/Project_one/JOHN"
If an exception occurs while processing one of the files, the file name is displayed followed by a warning message. The command continues processing any remaining files which match the wildcard argument. After the command is finished processing the files, ERROR 293 Operation failed on some files is generated. Only one error is generated for a command no matter how many warning messages are generated for that command.
If multiple warning messages are generated, each message writes over the previous message. To avoid missing any warning messages, press [PRINTALL]. [PRINTALL] sends all warning messages and their corresponding error message to the PRINTALL IS device.
Certain file system commands let you use file name completion with wildcards. Instead of specifying a complete file name as the argument for a command, you can specify a wildcard expression that matches a desired file name. The command finds the matching file name, then processes the file exactly as if you had specified the file name explicitly. File name completion reduces typing required for long file names. The commands that allow file name completion are ASSIGN, DICTIONARY IS, GET, GFONT IS, LOAD, LOAD KEY, LOAD SUB, MSI, PROTECT(LIF files only), RENAME, RE-SAVE, RE-STORE, and RE-STORE KEY.
Using the previous SRM catalog listing you can rename DATA1 using the statement:
RENAME "*1" TO "RESULTS1"
In a file name completion command, a wildcard argument must match only one file name . Therefore, the statement:
RENAME "D*" TO "RESULTS1"
would cause the following error:
ERROR 295 Wildcard matches >1 item
An escape character is specified when you enable WILDCARDS. The escape character cancels the special meaning of a wildcard character. The allowable values for the escape character are \ or '. The null string ("") can be specified to disable escape character processing. If an invalid escape character is specified the following error is generated:
ERROR 290 Invalid ESCAPE character
If you enabled WILDCARDS using the following statement:
WILDCARDS UX;ESCAPE "\"
you could use this statement to purge the program, my_program* shown in the following HFS catalog listing:
PURGE "my_program\*"
:CS80, 700
LABEL: MyVol
FORMAT: HFS
AVAILABLE SPACE: 60168
FILE NAME | FILE TYPE | FILE LEN | NUM RECS | MODIFIED DATE TIME | PERMISSION | OWNER | GROUP |
lost+found | DIR | 0 | 32 | 24-Apr-90 12:01 | RWXRWXRWX | 18 | 9 |
my_program* | PROG | 41 | 256 | 24-Apr-90 15:42 | RW-RW-RW- | 18 | 9 |
my_program1 | PROG | 412 | 256 | 24-Apr-90 14:32 | RW-RW-RW- | 18 | 9 |
freddy | ASCII | 50 | 256 | 24-Apr-90 12:02 | RW-RW-RW- | 18 | 9 |
You can only use wildcards in the rightmost segment of a directory path. The following statements are all valid:
PURGE "*"
RE-SAVE "/CHARLIE/*a*b"
COPY "/PROJECTS/Project_one/KATHY/*" TO "/PROJECTS/Project_one/JOHN
The following statements are invalid, and would cause the message ERROR 53 Improper file name to appear:
PURGE "*/*"
RE-SAVE "/*/my_program"
CAT "/PROJECTS/P*/CHARLIE/DATA*"
Here is a typical catalog listing of a LIF directory. Displays with 80 columns or more, have two extra fields for DATE and TIME when the file was last modified.
:CS80,700
VOLUME LABEL: B9836
FILE NAME PRO | TYPE | REC/FILE | BYTE/REC | ADDRESS |
MyProg | PROG | 14 | 256 | 16 |
VisiComp | ASCII | 29 | 256 | 30 |
GRAPH | BIN | 171 | 256 | 59 |
GRAPHX | BIN | 108 | 256 | 230 |
Here is what each portion of the catalog means:
:CS80,700 | Is the mass storage volume specifier (msvs) of the device. |
VOLUME LABEL | Is the name given to the volume (in this case, B9836). |
FILE NAME | Lists the file names in the directory (limit 10 characters). |
PRO | Indicates whether the file has a protect code (* is listed in this column if the file has a protect code). |
TYPE | Lists the type of each file. |
REC/FILE | Indicates the number of records (or sectors) in the file. |
BYTE/REC | Indicates the record size. |
ADDRESS | Indicates the number of the beginning sector in the file. |
DATE | Date when file was last modified (on 80-column or wider displays). |
TIME | Time when file was last modified (on 80-column or wider displays). |
Here is a typical catalog listing of an HFS directory:
:CS80, 700
LABEL: MyVol
FORMAT: HFS
AVAILABLE SPACE: 60168
FILE NAME | FILE TYPE | NUM RECS | REC LEN | MODIFIED DATE TIME | PERMISSION | OWNER | GROUP |
lost+found | DIR | 0 | 32 | 19-Nov-86 10:47 | RWXRWXRWX | 18 | 9 |
FILEIOD | PROG | 191 | 256 | 21-Nov-86 9:03 | RW-RW-RW- | 18 | 9 |
RBDAT | BDAT | 2 | 256 | 21-Nov-86 9:10 | RW-RW-RW- | 18 | 9 |
CATTOSTR | PROG | 2 | 256 | 1-Dec-86 8:02 | RW-RW-RW- | 18 | 9 |
Here is what each column means:
FILE NAME | Lists the name of the file (limit 14 characters). |
FILE TYPE | Lists the file's type (for instance, DIR specifies that the file is a directory, PROG specifies a BASIC program file, BDAT specifies a BASIC data file). |
NUM RECS | Number of logical records (the number of records allocated to the file). |
REC LEN | The logical record size (default is 256 bytes for all files except HP-UX; BDAT files have user-selectable record lengths; record length for HP-UX files is 1). |
MODIFIED
DATE TIME |
The day and time when the file was last modified. |
PERMISSION | Specifies who has access rights to the file:
There are three classes of user permissions for each file:
See the section "HFS File and Directory Permissions" later in this chapter for further information). |
OWNER | Specifies the owner identifier for the file (for BASIC files, the default owner identifier is always 18). |
GROUP | Specifies the group identifier of the file or directory (for BASIC, the default group identifier is always 9, which is used for "workstations" such as Series 200/300 BASIC and Pascal). |
Here is a typical catalog listing of an SRM directory:
PROJECTS/Project_one/CHARLIE:REMOTE 21, 0
LABEL: Disc1
FORMAT: SDF
AVAILABLE SPACE: 54096
FILE NAME | LEV | SYS TYPE | FILE TYPE | NUMBER RECORES | RECORD LENGTH | MODIFIED DATE TIME | PUB ACC | OPEN STAT |
ASCII_1 | 1 | ASCII | 1 | 256 | 2-Dec-84 13:20 | |||
BDAT_1 | 1 | 98X6 | BDAT | 1 | 256 | 2-Dec-84 13:20 | R | |
MEMOS | 1 | DIR | 1 | 24 | 2-Dec-84 13:20 | RW |
Here is what each column means:
FILE NAME | Is the name of the file (up to 16 characters). |
LEV | Is always 1 (for BASIC). |
SYS TYPE | Indicates the type of system used to create the file. This is blank for ASCII files and directories. 98x6 denotes a Series 200/300 computer. |
FILE TYPE | Indicates the file type (such as PROG, ASCII, BDAT) |
NUMBER RECORDS | Is the number of records in the file. |
RECORD LENGTH | Is the record length used in the file (file size is the product of RECORDS×LENGTH). |
MODIFIED DATE TIME | Shows date and time of day when the file was last written or modified. |
PUB ACC | Shows which access rights are currently public. For instance, MR indicates that Manager and Read capabilities are public, while other rights are protected and require a password to access them. See the section "SRM Passwords and Locks" later in this chapter for details. |
OPEN STAT | Is the current OPEN/CLOSED/LOCKED status of the file.
|
On SRM/UX, a catalog of a directory on an 80-column display has the following format:
:REMOTE 21,0
LABEL: BOOT
FORMAT: SRM-UX
AVAILABLE SPACE: 123456789
FILE NAME | FILE TYPE | NUMBER RECORDS | REC LEN | MODIFIED DATE TIME | PERMS | OWNER | GROUP | OPEN STAT |
---|---|---|---|---|---|---|---|---|
SYSTEMS | DIR | 11 | 24 | 1-Mar-90 16:56 | RWXR-XR-X | 0 | 1 | |
console | CDEV | 0 | 1 | 12-Oct-90 17:05 | RW--W--W- | 1 | ||
EDITTEST.TEXT | TEXT | 8 | 256 | 12-Dec-89 15:20 | RW-R--R-- | 175 | 54 | |
AUTOST | PROG | 2 | 256 | 5-Jan-90 15:07 | RW-R--R-- | 175 | 54 | |
srmdpipe | PIPE | 0 | 1 | 12-Oct-90 11:45 | RW------- | 0 | 1 | |
PTEST | ASCII | 1 | 256 | 2-Jan-90 10:51 | RW-RW-RW- | 17 | 9 | LOCK |
PTESTCAT | HP-UX | 984 | 1 | 2-Mar-90 15:12 | RW-RW-R-- | 175 | 54 | OPEN |
The header gives you the following information:
line 1 | Directory and volume specifier. The full path to the specified directory is displayed. If the directory path specifier contains more characters than the display width, the last 49 or 79 characters (depending on catalog format) in the path specifier are shown. An asterisk (*) as the left-most character in the path specifier indicates that leading characters were truncated for the display. |
line 2 | Label of the volume containing the directory being cataloged. |
line 3 | Directory format. |
line 4 | Number of bytes available on the volume in 256-byte increments. |
lines 5 and 6 | Labels for columns of information given for each file. |
The columns in the catalog give you the following information:
FILE NAME | lists the names of the files and directories in the directory being cataloged. | ||||||||||||||
FILE TYPE | indicates the file type. File types recognized by BASIC on SRM/UX are
the following:
The SRM/UX user can also see the following special HP-UX files in a CAT listing, but cannot manipulate them:
BASIC/WS on SRM/UX also recognizes TEXT and ASCII files. If the system does not recognize a file type, it prints a numeric code or "OTHER". |
||||||||||||||
NUMBER RECORDS | indicates the number of records in a file. | ||||||||||||||
REC LEN | indicates the number of bytes in each file record (always 24 for directories (DIR), regardless of actual size). | ||||||||||||||
MODIFIED DATE/TIME | (80-column format only) shows the date and time when the file's contents were last changed. | ||||||||||||||
PERMS | specifies who has access rights to a file.
Three classes of user permissions exist for each file:
See PERMIT for further information. |
||||||||||||||
OWNER | specifies the owner identifier for the file. BASIC/WS on SRM/UX shows the user id of the user that owns the file. | ||||||||||||||
GROUP | specifies the group identifier of the file or directory. BASIC/WS on SRM/UX shows the group id of the group to which the file belongs. | ||||||||||||||
OPEN STAT | shows whether the file is currently open (OPEN) or locked (LOCK). OPEN indicates that the file has been opened, via ASSIGN, by a user. An open file is available for access from other workstations. LOCK means the file is accessible only from the workstation at which the file was locked. If the entry is blank, the file is closed and available to any user. |
The following statement produces a multi-column listing of the file names in the current working directory of the current default volume:
CAT; NAMES
lost+found WORKSTATIONS SYSTEM_BA5
MY_PROG DATA_13 PROJECTS
You can specify which files to list using the following options to CAT:
CAT; SELECT "ABC" | Lists only the files beginning with the specified letters "ABC". |
CAT "*A*" | If you enable WILDCARDS, you could use this statement to list all file names containing the letter A. See WILDCARDS in the HP BASIC 6.2 Language Reference for details. |
CAT; COUNT Num_files | Stores the number of lines in the catalog in a numeric variable called Num_files. (This variable must be defined in the current program or subprogram context before it can be used.) |
CAT; NO HEADER, SKIP 10 | Suppresses the catalog heading and skips the first 10 files in the directory. |
See the HP BASIC 6.2 Language Reference for a complete description of these options.
Performing CAT operations on an individual PROG file returns additional information about the file. A catalog of a PROG file yields the following information:
The following catalog listing is an example of a CAT performed on an individual PROG file. This catalog format requires only 45 columns.
NEWPAGER_A
NAME SIZE TYPE
====================== ===== ================
MAIN 62002 BASIC
FNBar$ 3680 BASIC
FNRoman$ 656 BASIC
Killkeys 426 BASIC
FNTrim$ 414 BASIC
FNUpc$ 344 BASIC
FNLwc$ 416 BASIC
Table_formatter 6810 BASIC
Strip 1260 BASIC
AVAILABLE ENTRIES = 0
The AVAILABLE ENTRIES table entry is not currently used.
The following listing shows a program which was stored while a BIN program was resident in the computer.
NEWPAGER_B
NAME SIZE TYPE
====================== ===== ================
PHYREC (2.0) Rev A 1734 BASIC BINARY
*** WARNING: System level 5. Bin level 1.
MAIN 56394 BASIC
FNBar$ 3218 BASIC
FNRoman$ 656 BASIC
Killkeys 426 BASIC
FNTrim$ 414 BASIC
FNUpc$ 344 BASIC
FNLwc$ 374 BASIC
Table_formatter 7622 BASIC
AVAILABLE ENTRIES = 0
If the currently loaded BASIC system version is different from the binary program version, a warning with version codes of both BASIC system and binary program is included in the catalog information. The following example shows the format of the returned message.
Prog_phy
NAME SIZE TYPE
====================== ===== ================
PHYREC 1.0 1734 BASIC BINARY
*** WARNING: System level 5. Bin level 1.
MAIN 222 BASIC
AVAILABLE ENTRIES = 0
This section describes the mechanics of managing files in your system. These may be program files, data files that your application creates, or data files that you create from the keyboard.
Many of the following operations can only be performed on closed files and directories. Here is what the term closed means for files and directories.
ASSIGN @Io_path TO file_name
Files are closed by this statement:
ASSIGN @Io_path TO *
MASS STORAGE IS "/USERS/MARK/MY_DIR"
Makes MY_DIR the current directory
The SCRATCH A command also closes any currently open directories and files. All files except those opened with the PRINTER IS statement are also closed by pressing [Reset]. See the HP BASIC 6.2 Language Reference description of these commands for details.
You can protect files from being read, over-written, or destroyed by other system users. Note that file protection is different for each of the three directory types.
With LIF directories, protect codes are two-character strings assigned to any BDAT, BIN, or PROG file by using PROTECT. The protect code does not appear in the CAT display, but must be specified to subsequently modify the file. Protect codes are intended to prevent accidentally writing and purging files.
To protect the file NAMES with the protect code PC, use the statement:
PROTECT "NAMES","PC"
The protect code must then be specified with the file name to allow access. For example, to RENAME the protected file NAMES, use the statement:
RENAME "NAMES<PC>" TO "CLIENTS"
If a file has a protect code, it must be included in file specifiers for mass storage statements that write to that file or directory. Mass storage statements that read a file or directory do not require the protect code. Such statements include CAT, LOAD, LOAD BIN, LOADSUB, GET, and COPY.
To assign an I/O path name to the file named CLIENTS, you have to include the protect code:
ASSIGN @Path1 TO "CLIENTS<PC>"
If you assign a protect code longer than two characters, the system will ignore everything after the second (non-blank) character. The protect codes LONGPASS, LOST, and LOLLYGAG all result in the same protect code: LO. This rule holds both for PROTECTing a file and for specifying the protect code in a file specifier.
Renaming a file changes the file name in the directory, and leaves everything else intact, including the protect codes.
You can also assign a protect code to a BDAT file when you create it. For example:
CREATE BDAT "Example<xx>",10
To change a protect code, simply execute a new PROTECT statement:
PROTECT "Example<xx>","yy" new protect code is yy
PROTECT "Example<yy>"," " two blanks cancel protection
When specifying a file that does not have a protect code, you can either ignore the code entirely, or include a code of two spaces:
PURGE "Example"
or
PURGE "Example"
For HFS directories, you can use PERMIT to assign and remove access permissions of a file or directory. Since this file system is compatible with the HP-UX system, BASIC uses a subset of the HP-UX file protection mechanism. (With HP-UX, the chmod command performs this function.)
Nine permission bits for HFS files and directories, are broken into three classes, one for each class of users:
OWNER | GROUP | OTHER | ||||||
---|---|---|---|---|---|---|---|---|
Read | Write | Search | Read | Write | Search | Read | Write | Search |
The three classes of users are:
Each class of users has three types of ==permissions== for accessing an HFS file or directory:
The current state of these bits is represented in the PERMISSION column of a CAT listing of the directory in which the file or directory resides (R for READ; W for WRITE; X for SEARCH; - for no permission):
FILE NAME | FILE TYPE | NUM REC | REC LEN | MODIFIED DATE TIME | PERMISSION | OWNER | GROUP |
---|---|---|---|---|---|---|---|
Directory | DIR | 256 | 1 | 7-Nov-90 9:22 | RWXRWXRWX | 18 | 9 |
File | HPUX | 8192 | 1 | 7-Nov-90 9:23 | RW-RW-RW- | 18 | 9 |
The default permission bits for directories are: RWXRWXRWX. The default permission bits for files are: RW-RW-RW-.
PERMIT is used to permit or restrict access to files and directories by other users on a system. For more information about user categories and how to change permissions on a file or directory, see PERMIT in the HP BASIC 6.2 Language Reference.
The following example sets READ and WRITE permission for OWNER, but removes permission for SEARCH:
PERMIT "File"; OWNER:READ,WRITE
---------before
RW-------after
With these permission bits set, the owner of the file can read and write the file (with GET and RE-STORE, for example), but all other users on the system cannot access the file.
The following example sets READ and WRITE permission for OWNER, but removes permission for SEARCH (the PERMIT parameters are the same as in the preceding example, but the before permission bits are different):
PERMIT "File"; OWNER:READ,WRITE
R-XRW-RW- before
RW-RW-RW- after
With these permission bits set, all classes of users can read and write the file.
If OWNER, GROUP, or OTHER is not specified, the corresponding access-permission bits are not affected. The following statement sets permission bits for OWNER and OTHER, but leaves the bits for GROUP unchanged:
PERMIT "File"; OWNER:READ,WRITE; OTHER:READ
R--R---W-before
RW-R--R--after
The next example changes bits for GROUP and OTHER but leaves the bits for OWNER unchanged:
PERMIT "File"; GROUP:READ; OTHER:READ
RW-RW-RW-before
RW-R--R--after
If no user class is specified, the default permissions for all groups are restored:
PERMIT "File"
RW-R--R--before
RW-RW-RW-after
PERMIT "Directory"
RW-R--R--before
RWXRWXRWX after
The SRM system offers three kinds of access capability for files and directories, which are explained below. For a summary of the ways SRM/UX access capabilities differ from SRM, see "SRM/UX Access Capabilities".
READ | For a file, possessing this access capability allows you to execute
statements that read the file, such as GET, ASSIGN, ENTER.
For a directory, possessing this access capability allows you to execute statements that read the file names in the directory, and to "pass through" the directory when the directory's name is included in a directory path. In the SRM file specifier:
including the assigned password <READpass> allows passage through the directory Project_one to allow access to its subordinate directories and files. |
WRITE | For a file, possessing this access capability permits you to execute
statements that write to the file, such as SAVE, OUTPUT.
For a directory, possessing this access capability allows you to execute statements that add to or delete from the directory's contents, such as CREATE ASCII, CREATE DIR, PURGE. |
MANAGER | With the MANAGER access capability, public capabilities for a file or
directory differ slightly from password-protected capabilities.
|
Capabilities are either public access (available to all workstations on the SRM) or protected access (available only to users who know the appropriate password). The current access capabilities for a file are shown in a catalog listing:
PROJECTS/Project_one:REMOTE 21, 0
LABEL: Disc1
FORMAT: SDF
AVAILABLE SPACE: 4354096
FILE NAME | LEV | SYS TYPE | FILE TYPE | NUMBER RECORDS | RECORD LENGTH | MODIFIED DATE TIME | PUB ACC | OPEN STAT |
---|---|---|---|---|---|---|---|---|
ASCII_1 | 1 | ASCII | 0 | 256 | 2-Dec-90 13:20 | |||
BDAT_1 | 1 | 98X6 | BDAT | 0 | 256
|
2-Dec-90 13:20 | R | |
MEMOS | 1 | DIR | 0 | 24 | 2-Dec-90 13:20 | RW |
In the above example:
Capabilities are protected with the PROTECT statement, which associates a password with one or more access capabilities. Each file or directory can have several password/capability pairs assigned to it.
Once assigned, the password must be included with the file or directory specifier to execute statements requiring that access. If you don't specify the correct password when it is required, the system will report an error and deny access to the file or directory.
When you create directories and files, their access capabilities are public (available to any user on the SRM). You may subsequently protect a directory or file against certain types of access by other SRM workstations, if all of the following are true:
Using the directory structure in the following figure, and assuming no passwords have been assigned to the files, you could change the protections described in the list that follows.
MSI "/PROJECTS/Project_one"
PROTECT "CHARLIE",("passme":MANAGER,WRITE)
This moves to the directory Project_one (immediately superior to CHARLIE) and executes the PROTECT statement. The READ access capability on CHARLIE is still public, but any operations that require MANAGER or WRITE capabilities must include the password.
PROTECT "CHARLIE/ASCII_1",("no_pub":MANAGER,WRITE,READ)
or
MSI "CHARLIE"
PROTECT "ASCII_1",("no_pub":MANAGER,WRITE,READ)
These statements assume you are in the directory Project_one. The second sequence makes CHARLIE the new working directory. In the first, you merely pass through CHARLIE to reach ASCII_1. With the READ access capability on CHARLIE still public, you do not need a password.
PROTECT "BDAT_1",("write":MANAGER,WRITE)
PROTECT "MEMOS",("mgr_pass":MANAGER)
If you followed the steps above to protect the files and directory in CHARLIE, a catalog listing of CHARLIE would look something like this:
PROJECTS/Project_one/CHARLIE:REMOTE 21, 0
LABEL: Disc1
FORMAT: SDF
AVAILABLE SPACE: 54096
FILE NAME | LEV | SYS TYPE | FILE TYPE | NUMBER RECORDS | RECORD LENGTH | MODIFIED DATE TIME | PUB ACC | OPEN STAT |
---|---|---|---|---|---|---|---|---|
ASCII_1 | 1 | ASCII | 6 | 256 | 2-Dec-90 13:20 | |||
BDAT_1 | 1 | 98X6 | BDAT | 4 | 256 | 2-Dec-90 13:20 | R | |
MEMOS | 1 | DIR | 0 | 24 | 2-Dec-90 13:20 | RW |
The letters in the column labeled PUB ACC indicate access capabilities that are public (not protected with a password). Only the MANAGER (M) access capability on the directory MEMOS has been protected, leaving the READ (R) and WRITE (W) capabilities available to any SRM workstation user.
When a password is required, you must include the correct password as part of the file or directory specifier. The password must be enclosed between < and > and must immediately follow the name of the file or directory it protects. For example:
GET "/PROJECTS/Project_one/CHARLIE/ASCII_1<no_pub>"
Although allowing users to share SRM files saves disk space, it introduces the danger of several users trying to access the file at the same time. To avoid problems, you can use LOCK and UNLOCK to secure files during critical operations. LOCK establishes exclusive access to a file; the file can only be accessed from the workstation at which the LOCK was executed. Typically, you LOCK all critical files, read data from files, update the data, write the data into the files, and then UNLOCK all critical files.
To permit shared access to the file once again, UNLOCK must be executed from the same workstation, or the file must be closed. Only ASCII or BDAT files that have been opened by a user via ASSIGN may be locked explicitly by that user. For more information, refer to the descriptions of the ASSIGN, LOCK, and UNLOCK keywords in the HP BASIC 6.2 Language Reference.
You can get sole access to an SRM file with the LOCK statement. The same file can be locked several times in succession. You must cancel each LOCK with a corresponding UNLOCK.
Using ASSIGN to re-open a locked file unlocks the file. You must execute another LOCK statement to lock the file again.
Closing the file via ASSIGN @...TO * cancels all locks on the file.
In this example, a critical operation must be performed on the file named File_a, requiring a LOCK.
1000 ASSIGN @File TO "File_a:REMOTE"
1010 LOCK @File;CONDITIONAL Result_code
1020 IF Result_code THEN GOTO 1010 ! Try again
1030 ! Begin critical process
.
.
.
2000 ! End critical process
2010 UNLOCK @File
The numeric variable called Result_code is used to determine the result of the LOCK operation. If the LOCK operation is successful, the variable contains 0. If the LOCK is not successful, the variable contains the numeric error code generated by attempting to lock the file.
SRM/UX differs from the SRM system in the following ways:
The COPY statement lets you duplicate individual files or an entire disk volume. Any type of file may be copied.
COPY "ExistFile" TO "NewFile"
A new file can be created either on the same volume or on another volume. If you copy a file to the same volume and the same directory, the new file name must be different from the existing file name. If there is not enough room on the disk for the file to be copied, the system cancels the statement and reports an error.
NOTE |
---|
This type of copy destroys all data on the destination disc. If you want to copy multiple files, you should use one of the backup utilities described in the "BASIC Utilities" chapter of Installing and Maintaining HP BASIC/WS 6.2. |
Drawing of disc-to-disk COPY goes here.
To perform this type of copy, simply identify the source and destination volumes.
COPY ":,700" TO ":,702"
NOTE |
---|
You can copy a larger volume to a smaller volume, if it does not overflow the smaller one. With HFS, copying a smaller volume to a larger volume will effectively change the size of the larger volume (making it the size of the smaller volume). |
More Examples
The following statement copies File1 from the current default mass storage volume to a new file called File2 on the same volume:
COPY "File1" TO "File2"
The following statement copies File1 from the current default mass storage to a drive at interface select code 7, primary address 0, unit number 1. Both files can be named File1 if they are on different volumes.
COPY "File1" TO "File1:,700,1"
The following statement lets you copy multiple files beginning with A to another directory if WILDCARDS is enabled:
COPY "A*" TO "/TEMP"
You can overwrite the contents of an existing file using COPY with the secondary keyword PURGE:
COPY "File1" TO "ExistFile"; PURGE
COPY can be used to copy files from volumes of one format to another (LIF files to HFS or SRM volumes, SRM files to HFS or LIF volumes, and so forth).
The following statement copies a file from a disk drive to the current default mass storage device.
COPY "File1:,700,0" TO "DATA"
The following statement copies the entire disk from the right-hand drive to the left-hand drive of a dual-drive disc.
COPY ":,700,1" TO ":,700,0"
You can copy an entire LIF volume in a single COPY statement. This operation destroys all previous data on the destination.
To copy an HFS file, you must have R (read) permission on the existing file and X (search) permission on all superior directories. You also need W (write) and X permissions on the destination directory into which the duplicate file is being copied, as well as X permission on all superior directories.
You cannot copy directories, although you can copy files from one directory to another. You can copy an entire HFS volume in a single COPY statement. As with LIF, this operation destroys all previous data on the destination.
To copy an SRM file, you must have R (read) permission on the existing file. You must also have W (write) permission on the directory into which the duplicate file is being copied, as well as R permission on all superior directories.
You cannot copy directories, although you can copy files from one directory to another. You cannot copy an entire SRM volume in a single COPY statement. (You must copy an SRM volume file by file.)
The name of a file can be changed without disturbing the file's contents. This is done with RENAME. For example, to change the name of a file (on the default volume) from George to Frank, use the following statement:
RENAME "George" TO "Frank"
Within an HFS or SRM volume the RENAME statement can be used to change the name of a file, optionally changing its location in the hierarchy:
RENAME "/USERS/MARK/File22" TO "/USERS/MARK/OLD_FILES/File22"
You can purge a file from a directory by using PURGE. Purging a file deletes the directory entry for the file and releases the space reserved for the data area. For example, the following statement removes the file Old_stuff from the current default volume:
PURGE "Old_stuff"
You can purge multiple files with a single PURGE statement when WILDCARDS is enabled. The following statement purges all files in the current directory with names beginning with A through C and ending with 1:
PURGE "[A-C]*1"
Once a file is purged, there is generally no way of retrieving the information it contains. The only exception to this rule is with LIF disks, on which files can be un-purged using the Mass Storage Program (MASS_STOR). See the "Utilities" section of Installing and Maintaining HP BASIC/WS 6.2 for instructions.
The order of file names and files' data areas is the same on LIF discs. Therefore, purging a file on a LIF directory creates two gaps on the disc.
The solution to this problem is to "REPACK" the disk using the "Mass Storage" (MASS_STOR) utility, available on the BASIC Utilities disc. See the "Utilities" section of Installing and Maintaining HP BASIC/WS 6.2 for instructions.
The PURGE statement can be used for removing HFS files and directories.
Here are the restrictions on using PURGE to remove HFS files:
PURGE can be used for removing SRM files and directories. PURGE works only with closed files and directories. Directories must also be empty of all files and subordinate directories.
When specifying the SRM file to be purged, you must include a write password for the file and read/write passwords for its superior directory. To purge the file BDAT_1 from the directory CHARLIE (see previous examples), you could type:
PURGE ".<passme>/BDAT_1<write>"
In this example, CHARLIE is the current working directory, as denoted in the directory path by the . (period). (Refer to the syntax for directory path in the HP BASIC 6.2 Language Reference).
To purge a file, you must have WRITE access capability on that file and READ and WRITE access capabilities on the file's superior directory. Because passme protects the WRITE capability on CHARLIE and write protects the WRITE capability on BDAT_1, both passwords must be included in the file specifier in the PURGE statement.
Although you do not normally need to specify the working directory in a directory path, you must include the password for the PURGE operation. The READ capability on CHARLIE is not password-protected.
To purge CHARLIE, you first need to purge the remaining files and directory in CHARLIE. Because the MSI statement opens a directory, making it the current working directory, you must also close CHARLIE.
For example, if no files or directories remained in CHARLIE, you could purge CHARLIE by executing these two commands:
MSI ":REMOTE"
PURGE "PROJECTS/Project_one/CHARLIE<passme>
The first statement closes CHARLIE and establishes the root directory as the current working directory. Because passme protects the WRITE access capability on CHARLIE, you must include that password in the PURGE statement.