Browse Prior Art Database

Use Of Directory Paths to Solve File Handling Problems in a CMS Multitasking Environment

IP.com Disclosure Number: IPCOM000115225D
Original Publication Date: 1995-Apr-01
Included in the Prior Art Database: 2005-Mar-30
Document File: 4 page(s) / 109K

Publishing Venue

IBM

Related People

Stone, RL: AUTHOR

Abstract

Disclosed is the use of the CMS Shared File System and directory pathing to solve two problems associated with executing a current CMS program in a CMS multitasking environment.

This text was extracted from an ASCII text file.
This is the abbreviated version, containing approximately 52% of the total text.

Use Of Directory Paths to Solve File Handling Problems in a CMS Multitasking
Environment

      Disclosed is the use of the CMS Shared File System and
directory pathing to solve two problems associated with executing a
current CMS program in a CMS multitasking environment.

      A directory, as, for example, in the CMS Shared File System
(SFS), is a user-defined entity containing a set of files.  A
directory path is a sequence of directories such that programs can
read and write to a directory path and not know about the individual
directories or minidisks which make up the directory path.

      CMS paths have the following rules:
  1.  If an application writes to a file which does not currently
       exist, the file will be created in the first
      Read/Write directory or minidisk in the directory path.
      For example, using Fig. 1, files created in the directory
       path would be placed in directory 1.
  2.  If an application reads or writes a file which does exist in a
       directory in the directory path, the file is read or written
in
       the directory in which it exists.  For example, using Fig. 1,
if
       a program using that path wrote to file X, file X in directory
2
       would be modified.

      Applications which are designed for a single tasking system,
such as CMS, make certain assumptions about their environment.  One
assumption made by CMS applications is that no other program is
sharing its Read/Write DASD space.  This assumption is based in the
CMS minidisk file system which has the rule that only one user (and
therefore only one application) has "write authorization" to a
minidisk at a time.

      A second assumption is that it can read and write to a minidisk
named "A".  Traditionally each user has a private read/write "A"
minidisk to which applications read input files and write work files
and output files.  This "A-disk" may be either a minidisk or an SFS
directory.

      One result of these assumptions is the use of standard, or
fixed, file names by applications.  Each time the program is
executed, it creates a file of the same name.  Because no other user
can execute a program writing to the same minidisk at the same time,
there was no danger of colliding on the file name.  A collision is
defined as writing successively to the same file name.  T...