Browse Prior Art Database

File Name Mapping in a Heterogeneous Distributed Environment

IP.com Disclosure Number: IPCOM000100114D
Original Publication Date: 1990-Mar-01
Included in the Prior Art Database: 2005-Mar-15
Document File: 7 page(s) / 300K

Publishing Venue

IBM

Related People

Jolin, AT: AUTHOR

Abstract

A method is described to map the names of files on one system to the naming conventions of another system. The mapping can be specific or generic; that is, one mapping statement can control a specific file or any member of a non-enumerated group of files.

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

File Name Mapping in a Heterogeneous Distributed Environment

       A method is described to map the names of files on one
system to the naming conventions of another system.  The mapping can
be specific or generic; that is, one mapping statement can control a
specific file or any member of a non-enumerated group of files.

      In connecting unlike operating systems, there is often a need
to work under one operating system while referring to files on a
second OS.  If the intent is to make access to the files on the
second OS transparent to a user or application on the first OS, then
there is a need to map a first-OS-format fileid* into a corresponding
second-OS- format fileid.  (The term "fileid" refers to the
completely-qualified name of the file, including any subdirectories,
high-level-qualifiers, minidisk letters, etc., which may be required
or assumed by the operating system)

      The mapping must be one-to-one and on-to. ("one-to-one" means
that for every "from" fileid there is one and only one "to" fileid.
"on-to" means that for every "to" fileid there is one and only one
"from" fileid.) Anything less will allow ambiguity of reference,
which is unacceptable due to data loss and user confusion.

      On the other hand, a mapping system which has an entry for each
specific fileid would have to be adjusted every time a file is
created or erased.  Since files come and go frequently under many
operating systems, such a mapping system would have poor usability
there.

      In the interest of consistency, the mapping method should be
able to handle mapping of fileids from any OS to any other OS.

      The mapping method described here is based on a "profile" which
is set up ahead of time (that is, prior to the actual reference to a
particular file by an application or user).  The profile contains a
set of rules which determine how a particular fileid is mapped from
the first operating system's format (F1) to the second operating
system's format (F2).

      The profile looks like this, using Backus-Naur Form (BNF)
notation:

      The particular choice of symbols described here (e.g., "*" for
the wildcard symbol) is for convenience and usability; any other
symbols could be used.

      Other fileid formats besides <DOSfid>, etc., may be defined for
other operating systems.  There are no inherent limits on what
<F1fid> and <F2fid> look like; the formats specified above are
examples.  Details about special characters allowed in <name> and
<ext> are omitted in the description above.  These details differ
depending on the particular operating system.  Also, <MVSfid> has a
maximum length of 44 characters, but this additional condition could
not be expressed in BNF.  These details are not pertinent for this
description.

      To simplify the process, a particular profile should contain
rules for only one particular <F1fid> <F2fid> pair; that is, the
rules are all of the form <DOSfid> <MVSf...