Very Computer

Hi,

I am wondering if I'm the first one in this world asking this, or
maybe it's too obvious: does Tru64 have ODS-2 and RMS support so
that one could put a Tru64 machine in a VMS cluster? Since Compaq
seems to nudge people to migrate from VMS to Tru64, supporting
heterogenous clusters would be a sure and seamless path to do that.
Alas, it seems there is no such thing. I find that strange. Is it
a silly idea? Why?

I heard about FreeBSD and Linux being able to mount ODS-2 file
systems, if only read only and very limited. But since Compaq has
the experts and the full specs, why are they not doing it?

any thoughts appreciated,
-Gunther

--

Medical Information Scientist      Regenstrief Institute for Health Care
Adjunct Assistant Professor        Indiana University School of Medicine
tel:1(317)630-7960                         http://aurora.regenstrief.org

Quote:> Hi,

> I am wondering if I'm the first one in this world asking this, or
> maybe it's too obvious: does Tru64 have ODS-2 and RMS support so
> that one could put a Tru64 machine in a VMS cluster?

No.  The distributed lock manager in VMS cluster is used by the VMS file
system in both the kernel and in RMS to control file and record level
access, as well as for other purposes.  The distributed lock manager in
Tru64 is used in the kernel to control access at the disk block level
as well as other purposes.

You could try porting the ODS-2 support from Linux, but don't expect it
to talk SCS to a VMScluster.

----------------------------------------------------------------------
Bob Koehler                     | Computer Sciences Corporation
NASA GSFC Flight Software       | Federal Sector, Civil Group
                                | please remove ".aspm" when replying

The problem is that the Unix file system simply is not rich enough to
map to all the different record types supported by ODS-2.
For Unix a file is just a sequence of bytes. It is the application which
might create some structure in these bytes. This structure does not exist
outside the application.
In ODS-2 the file itself has some structure even without application,
sometimes a very complex one as, e.g., in ISAM files. It does not fit
in the Unix scheme to have such a structure outside the application.

The same proble you will see, although not so extreme, with ANSI labeled
tapes. The ANSI standard also defines several record structures, but Unix
does not know anything of records outside the application.
That's why ANSI-labeled tapes are handled so easily in VMS and are difficult
to use under Unix.

This is not only a problem for Unix, but for all operating systems that do
not define record structures in files, like e.g., DOS and Windows. The use
of the ODS-2 system under such operating systems is only very limited.

TOPS-20 also used a stream of bytes, but when the Fortran library, COBOL
library, and others eventually all realized they were trying to achieve
the same results they consolidated it into an RMS.

The UNIX f77 environment already has to deal with needing record concepts
imposed on the byte stream.  No reason why there couldn't be a librms.so
providing all the other capabilities, in fact vendors sell libraries like
that to support VMS -> UNIX migration.

What you don't get for free is language specific libraries rewritten on
top of a librms.  libc et.al. will continue to sit directly on top of
the UNIX kernel API unless some UNIX vendor sees the benefit of
centralizing all that code.  

Meanwhile VMS engineers are adding I/O capabilities to the kernel just
to support C libary calls for DII-COE, solving the opposite problem by
what appears to be removing RMS for some cases.

----------------------------------------------------------------------
Bob Koehler                     | Computer Sciences Corporation
NASA GSFC Flight Software       | Federal Sector, Civil Group
                                | please remove ".aspm" when replying