NOS/VE File System
NOS/VE used a hierarchical file system, of course. References to files had the syntax:
[:family[.username.]] [catalog1.] [catalog2.] … filename [.cycle] [.position]
A family name was for instance used to determine different locations (systems) in the network. On most systems, it was always “NVE”.
A “catalog” was VE’s term for a directory. Each user had a master catalog–that is to say, a home directory–that could be referred to by the symbol $USER. For instance, for the SYS account, $USER expanded to “:NVE.SYS” much like the “~” UNIX shell expansion.
Cycles, as in the SCOPE/ NOS/BE operating system, allowed different versions of a file with the same name. The default cycle was $HIGH, the highest-numbered cycle. Aside from explicit cycle numbers, you could use $LOW, $NEXT, and $NEXT_LOW.
The position specified the position of the file when opened. This specification defaulted to $BOI (beginning of information) and was rarely used. Other values were $EOI and $ASIS. To concatenate the file A to the end of B, for instance, one could type:
COPY_FILE A B.$EOI
$LOCAL was a special catalog for temporary (local) files and for permanent files temporarily associated with a local file. Unlike other catalogs (directories), $LOCAL could not have subcatalogs. This arrangement was very similar to local files in SCOPE (and NOS/BE). Because VE allowed permanent files to be referenced directly by name, this confusing holdover was rarely used. $LOCAL was the default location for certain files, such as object files output from a compiler.
NOS/VE had the concept of a “working catalog” (current directory). This was a path name that was prefixed to a file reference if you didn’t start the reference with a “.” or “:”. At the beginning of a job, the working catalog was $LOCAL (like in NOS/BE!); not very useful. But prologs allowed the user to set the working_catalog to the users home directory or that of e.g. a project.
As with other modern operating systems, NOS/VE file security was primarily through “permits” (permissions) issued by the owner of a file. File passwords were available but rarely used. Types of access were:
- CONTROL (allows deletion or changing of attributes)
- CYCLE (allows adding new cycles, or creating a file in the first
Permits could apply to individual files or to entire catalogs. They could be issued for users, families, accounts, or projects. The “access mode” of a file was what you were allowed to do to a file.
The “share mode” of a file was the modes in which you were required to share the file with others while you were using the file. (Not applicable to CONTROL and CYCLE.)
CREATE_CATALOG_PERMIT $user group=family am=(read,execute).. share_mode=(read,execute)
changed the permissions on the catalog $user (the user’s home directory) to allow users in the same family to read and execute. Applying permissions to a catalog controlled access and visibility of the catalog contents (DISplay_Catalog_Contents of _Entry).
CREATE_FILE_PERMIT $user.secfile group=user user=lukey .. access_mode=all
allowed user lukey unlimited access to the file secfile in the catalog $user.
Job Files and System Files
Job files were fixed names for file-like resources associated with each job. Job files themselves could not be reassigned; system files were used for that purpose.
|COMMAND||Source of commands; terminal for interactive jobs, or job deck for batch|
|INPUT||Terminal input (null for batch)|
|OUTPUT||Place where output goes: terminal for interactive jobs, printer for batch jobs|
|$NULL||Like /dev/null on UNIX|
|$JOB_LOG||Place where echoed commands and system messages went, like SCOPE/Hustler dayfile.|
System files were essentially UNIX-style links. They were reassignable standard “files” which were real names treated as pseudonyms for real files. System files were used by the system for standard places to get or put data. Each system file was usually associated with a job file.
|$ECHO||none||none||Useful for debugging PROCs|
|$RESPONSE||$JOB_LOG & OUTPUT||OUTPUT||Place for system messages, similar to dayfile. Similar to $ERRORS.|
File connections (reassignment of a system file) were not frequently used. They might be used for logging a session or for debugging, but generally there was an easier way of redirecting output for ordinary work. For instance, compiler listings could be sent to a file with the L= parameter on the FORTRAN control statement. So
FORTRAN I=myprog L=mylisting
was used in preference to
CREATE_FILE_CONNECTION $LIST mylisting FORTRAN I=myprog