Scope and NOS/BE Permanent files

PFs were managed by the permanent file system, which was largely distinct from the portions of the OS that did I/O to and from disk files. The PF system gave each permanent file a unique name containing 1-40 characters. Each permanent file was associated as well with a 1-9 character user ID or PUBLIC (no ID specified). Unlike local filenames, PF names could contain any Display Code character, though most filenames contained only alphanumeric characters.

Cataloging files

This made local_filename permanent by creating an entry for it in the PF system under the name permanent_filename. CATALOG did not make a copy of the data; the data still resided in the same sectors on the same disk drive. CATALOG called the PFC PP-program that simply stored the file information and disk sector pointers into two special system files, the PF-Catalog (PFC) and the PF-Directory (PFD). The first one contained per permanent file the volume, segment and sectors where the data resided. The PFD contained the directory with per permanent file name PFC-pointer(s) to the (max 5) cycles. The PFC and PFD consistency was verified at each deadstart ("boot"). Bit drops in the early 6x00 systems (no parity checks in memory) caused many times crossed files.

To access an existing permanent file, a user issued an ATTACH statement of the form:
ATTACH,local_filename, permanent_filename [,optional parameters].

This created a local file which was associated with the named permanent file. For the rest of this job, I/O to local_filename was done to the file previously cataloged under permanent_filename.

Permanent file attributes

• A 9-character ID. This field was pretty worthless. Its main function was to help group files; you could list permanent files with a given ID.
• A cycle number, from 1-63. The default was 1. File cycles were like versions in DEC's VMS operating system (which post-dates SCOPE and NOS/BE, of course). You could have up to 5 different files with the same file name, with each file having a different cycle number. When you attached a permanent file, you got the highest-numbered cycle on the system unless you explicitly requested a specific cycle.

  The contents of the different cycles need not be related, but in practise different cycles typically were different versions of the same program or data file. The concept of cycles was intended to allow the easy maintenance of commonly-used files. If you had a program that many people used and you wanted to provide a new version of it, you might not be able to modify the file if it was currently in use. So, you would create a file with the same name but a higher cycle number. People currently using the older version would be unaffected, but people subsequently attaching to that filename would get the new version. The problem came when you got to cycle 63.

• Retention period. This was the number of days before the file would automatically be purged from the system. 999 meant the system should never purge the file.
• Permissions. There were 5 different permissions associated with a file. Each was controlled by a 9-character password. Thus, the use of passwords on files was much more common in SCOPE and NOS/BE than on other operating systems.

  By default, permanent files were cataloged with no special permission control, which meant that anyone on the system could do anything to the file. Nevertheless, it was rare for users to mess with each other's files, and when they did, it was usually accidental.
  The following password-protected permissions were available, listed with their two-character CATALOG and ATTACH parameter name:

  • Read permission (RD). This allowed the user to read the file.
  • Extend permission (EX). This allowed the user to permanently add data to the end of a permanent file. Oddly, you could append to a file without EX permission. However, the appended data would not be recorded in the permanent file system until an Extend operation was performed on the file. You needed EX permission to perform this Extend.
  • Modify permission (MD). This allowed the user to overwrite ("rewrite") portions of the permanent file that were already part of the permanent file system. I don't think you needed MD permission to rewrite data that had been appended to a file but not Extended. I believe that Modify permission also allowed a file to be truncated.
  • Control permission (CN). This allowed the user to purge (delete) a file cycle. When set, it was also necessary to create a new cycle of an existing file.
  • Turnkey permission (TK). This redundant feature was a separate permission that essentially combined all the features of RD, EX, MD, and CN. Actually the permanent file catalog PP program PFC subsequently called a subroutine 5 times to set these passwords.
    If there was a TK password on a file, you needed to submit the TK password to attach the file. TK could be seen as the "master lock". Even if you knew the RD, EX, MD, and CN passwords, or if there weren't these passwords on a file, you needed to submit the TK password to gain any access to the file.
  Passwords were used for more than just security reasons. If a file was attached with only Read permission and no other user currently had the file attached with anything more than Read permission, then multiple users could attach the file. This was called Multi-Read access. Placing CN, EX, and MD passwords on a file, but no RD password was therefore common. This allowed multiple users to use the file simultaneously. Also, when multiple jobs/users could be active, one could allow multiple access using "higher permissions" by specifying the multi-read (MR=1) parameter.

PRU's and disk allocation units

Indirect Permanent Files (IPF)