Update to the MTS architecture article in Wikipedia (Draft)

posted May 25, 2014, 6:50 AM by Jeff Ogden   [ updated Jun 7, 2014, 6:49 PM ]
On 7 June 2014 new sub-sections on "Shared files" and "File locking" were added to the "MTS Systems Architecture" article in Wikipedia. The new sub-sections are an update of the draft that follows with changes suggested by Gary Pirkola and Mike Alexander.

  -Jeff

On May 25, 2014, at 12:03 AM, Jeff Ogden wrote:

The "MTS System Architecture" article in Wikipedia doesn't currently (May 2014) talk about shared files or file locking and so I'm gathering information for an addition to that article. Here is a draft of a possible addition. Comments, suggestions, and corrections welcome.

  -Jeff

Shared files

Over time the sharing of files between MTS users evolved in four stages.

Stage one allowed for limited file sharing, where public or library files (files whose names start with an asterisk) were readable by all users and all other files (user files) could only be accessed by their owners. Public files were owned and maintained by Computing Center staff members, so at this stage only Computing Center files were shared.

Stage two allowed for limited file sharing, where the program *PERMIT could be used to (i) make a file read-only (RO) to the file’s owner and all other MTS users, (ii) make a file available for copying by members of the same project as the file’s owner using the program *COPY, or (iii) make a file available for copying by all other users using the program *COPY. As for stage one, by default owners had unlimited access to their own files and the files were not accessible to other users.

Stage three allowed for “really shared files”, where the $PERMIT command or the PERMIT subroutine can be used to share a file in a variety of ways with lists of other users, projects, all other users, or a combination of these. The types of access that can be allowed are read, write-extend, write-change or empty, renumber or truncate, destroy, and permit. As for stages one and two, by default a user file is permitted with unlimited access for its owner and no access for others. A file’s owner’s access can also be changed, although an owner always retains permit access. The $FILESTATUS command or FILEINFO and GFINFO subroutines can be used to obtain a file’s permit status.

Stage four added program keys (PKeys) to the list of things to which a file can be permitted. Thus files can be permitted to users, projects, all other users, program keys, or a combination of these. Program keys were associated with MTS commands and files, which allowed files to be permitted to specific programs or to specific MTS commands. Among other things this allowed the creation of execute-only or run-only programs in MTS. The PKEY subroutine can be used to shorten the program key of the currently running program or switch the program key of the currently running program to *EXEC and later restore the program key, allowing a program to voluntarily limit the access it has to files by virtue of its program key.

File locking

As part of “really shared files” (stage three), file locking was introduced to control simultaneous access to shared files between active MTS sessions (that is, between separate running tasks or processes). File locking does not limit or block access to files within a single MTS session (between command language subsystems or user programs running as part of the same MTS session).

File locking in MTS is mandatory rather than advisory. Files are locked implicitly on first use of a particular type of access or explicitly using the $LOCK command or the LOCK subroutine. Files are unlocked implicitly when the last use of a file within a task is closed or explicitly using the $UNLOCK command or the UNLK subroutine. The $LOCKSTATUS command or LSFILE and LSTASK subroutines can be used to obtain a file’s or a task’s current lock status.

A file’s lock status may be “not open and not locked”, “open”, “locked for read”, “locked for modify”, “locked for destroy”, “waiting for open”, “waiting for read”, “waiting for modify”, or “waiting for destroy”. Locking a file for modification also locks the file for reading and locking a file for destroying also locks the file for modification and reading. Any number of jobs can have a file locked for reading at any given time, but only one job can have a file locked for modification at any given time and then only if no job has the file locked for reading, or locked for destroying. Only one job can have a file locked for destroying at any given time, and then only if no job has the file open, locked for reading, or locked for modification.

When an attempt to lock a file cannot be satisfied, the calling task will wait either indefinitely or for a specific period of time for another task to unlock the file, or until an attention interrupt is received. If the file cannot be locked, an error indicating this is returned. The file locking software detects deadlocks between tasks and returns an error indication.


Comments