Browse Prior Art Database

Contents Command for VM/CMS

IP.com Disclosure Number: IPCOM000108712D
Original Publication Date: 1992-Jun-01
Included in the Prior Art Database: 2005-Mar-22
Document File: 3 page(s) / 138K

Publishing Venue

IBM

Related People

Cahill Jr, RB: AUTHOR

Abstract

Currently, there is no support for filenames, file descriptions or general file information about CMS files for users of the VM/CMS* file system outside of the eight-character filename, the eight-character filetype and the two-character filemode.

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

Contents Command for VM/CMS

       Currently, there is no support for filenames, file
descriptions or general file information about CMS files for users of
the VM/CMS* file system outside of the eight-character filename, the
eight-character filetype and the two-character filemode.

      A new function, hereafter referred to as CONTENTS, should be
added to the CMS operating system.  This command would allow the user
to enter as long a description as he/she would like about any CMS
file.  The user could then look at that description later as he/ she
needs or would like to.  This feature would also allow VM system
support personnel to add a CONTENTS file description to any file(s)
on minidisks that their VM users access.  Then, if the user ever
wants or needs to know what a file "is/was", they could use the
CONTENTS command to find this information.  This would be especially
helpful for users to see what many of the files are that are created
by CMS applications (like profiles) and then stored on the user's
"A-disk" (for example, LASTING GLOBALV A1, and application created
files; IBM Program Product ProcessMaster creates a file named DZAS
USRDFLTS A0, print profiles, the CMS netlog...).  This information
would be extremely helpful for users when they are "cleaning" up
their system files, as this would help to eliminate users from
erasing files they didn't know they needed.  The command syntax to
add a description to a file would be:
CONTENTS filename filetype <filemode> description (options)

      Where the default filemode would be A.  If a "description" is
already stored for this file, the feature would double-check to make
sure the user wants to replace the "old" description with the new
one, and if so, then the new description is saved in place of the old
one.  The information the user enters "describing" any file would
then be saved in a file named: CMSFILES CONTENTS A.  (The CMSFILES
CONTENTS A file should also have a description for itself that is
created the first time the user uses the CONTENTS command.)  A user
could enter a description of any file he/she "owns" on any of his/her
Read/Write VM minidisks as well as file(s) on mdisks that he/she does
not own.  For example, there might be a set of CMS files that are
stored on a common VM support minidisk that the user occasionally
uses.  Lets say these files are on a minidisk that the user has
access to: USERTST1 MODULE R, USERTST2 MODULE R, and USERTST3 MODULE
R.  The user knows he/she needs to execute one of the modules in each
of three particular situations. A description, or "notes" on what
each file "is", would be very helpful to have, and CONTENTS would
allow the user to enter this type of information/"notes" on each file
for retrieval at any later time.  The only option would be ... for
continuation of a description.

      The command syntax to view the description for any file would
be:
CONTENTS <filename> <filetype> <filemode> (options)

    ...