Using Directories and Files

This chapter describes general management of directories and files.

Creating and Using Hierarchical Directories

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.

Changing the Default Volume

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.

Adding Another Directory

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.

Creating Files and Other Directories Under a Directory

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:

Management of Hierarchical Directories

As a type of file, a directory can be managed in the following ways:

Using Wildcards

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.

Enabling and Disabling Wildcards

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

File Name Expansion

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.

File Name Completion

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

Using the Escape Character

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

Restrictions on the Use of Wildcards

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*"

Understanding Catalog Listings

LIF Catalogs

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).

HFS Catalogs

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:
  • R indicates that the file can be read.
  • W indicates that the file can be written.
  • X indicates that the file can be searched (meaningful for hierarchical directories only).

There are three classes of user permissions for each file:

  • OWNER (left-most three characters).
  • GROUP (center three characters).
  • OTHER (right-most three characters).

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).

SRM Catalogs

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.
  • OPEN means someone currently has the file open.
  • LOCKED means the file is opened in EXCLUSIVE mode, and no one else may access the file.
  • If blank, no one is currently using the file.

SRM/UX Catalogs

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:
DIR directory
PROG BASIC program file
PIPE named pipe

The SRM/UX user can also see the following special HP-UX files in a CAT listing, but cannot manipulate them:
NET network special file
SOCK HP-UX socket
BDEV block special file
CDEV character special file

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.
     indicates that a file can be read.
    W indicates that a file can be written.
    X indicates that a directory can be searched (meaningful for directories only).

Three classes of user permissions exist for each file:
   OWNER (left-most three characters)
      GROUP (center three characters)
      OTHER (right-most three characters).

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.

Listing Only File Names (Requires MS Binary)

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

Cataloging Selected Files (Requires MS Binary)

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.

Cataloging Individual PROG Files (Requires MS Binary)

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

General File Management Operations

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.

Closed versus Open Files and Hierarchical Directories

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.

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.

Protecting Files

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.

LIF Protect Codes

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"

HFS File and Directory Permissions

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

SRM Passwords and Locks

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:

"/PROJECTS/Project_one<READpass>/JOHN/f1"

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.

  • *Public MANAGER capability allows any SRM user to PROTECT, PURGE, or RENAME the file. *The password-protected MANAGER capability provides MANAGER, READ, and WRITE access capabilities to users who include a valid password in the file or directory specifier.

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:

  1. The file ASCII_1 has no public access capabilities. All access must include the appropriate password.
  2. The file BDAT_1 has the READ capability open to the public. Anyone on the SRM system can read the file.
  3. The directory MEMOS has READ and WRITE capabilities open to the public. Anyone can create and purge files in the directory, and search through the directory with a statement like MASS STORAGE IS "MEMOS/SUB_DIR".

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.

  1. Assign the password passme to protect the MANAGER and WRITE access capabilities on the directory CHARLIE:
    
    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.

  2. Remove all public access capabilities from the file ASCII_1 by assigning the password no_pub, using:
       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.

  3. Protect the file BDAT_1 so data can be read from it but not written into it without using the password write. If the current working directory were CHARLIE, you would type:
       PROTECT "BDAT_1",("write":MANAGER,WRITE)
    

  4. Protect the MANAGER access capability of the directory MEMOS with the password, mgr_pass. Everyone can read from and write to the directory, but a password is required to purge the directory or its contents. Type:
       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.

Specifying Passwords

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>"

Exclusive Access: Locking SRM Files

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.

Locking and Unlocking SRM Files

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 Access Capabilities

SRM/UX differs from the SRM system in the following ways:

Copying Files and Volumes

The COPY statement lets you duplicate individual files or an entire disk volume. Any type of file may be copied.

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).

Copying LIF Files

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.

Copying HFS Files

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.

Copying SRM Files

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.)

Renaming Files

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"

Purging Files

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.

Effects of PURGE on LIF Directories

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.

Purging HFS Files and Directories

The PURGE statement can be used for removing HFS files and directories.

Here are the restrictions on using PURGE to remove HFS files:

Purging SRM Files and Directories

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.