From: Martin Gregorie on
On Thu, 15 Apr 2010 04:48:14 -0700, Roedy Green wrote:

> They all have tree structured directories. They all treat files as
> blobs of bytes, randomly accessible. They all support a basic set of
> attributes.
>
Sorry, but that's not altogether true. Off the top of my head I know
three systems (IBM mainframes and i series [i.e. AS/400], Guardian non-
stop) that don't use hierarchic file systems. All three use the older
named extent/file/subfile model where there is no hierarchic concept at
either extent or file level (both are flat lists) and where all the
subfiles in a file not only form a flat list but also hold the same type
of data, defined by a file-level descriptor.

> Windows has its drive letters. There is the complication of symbolic
> links.
>
OS-9 and VMS also have separate trees on each disk, unlike Unices, but
only the Unices support symbolic links or multiple hard links per file.

> In the olden days the OS handled various types of keyed lookup, with
> quite eccentric interfaces.
>
Thats still alive and well - i series buries that in the OS, connected to
the file via the descriptor.


--
martin@ | Martin Gregorie
gregorie. | Essex, UK
org |
From: Mike Schilling on
Martin Gregorie wrote:
> On Thu, 15 Apr 2010 04:48:14 -0700, Roedy Green wrote:
>
>> They all have tree structured directories. They all treat files as
>> blobs of bytes, randomly accessible. They all support a basic set of
>> attributes.
>>
> Sorry, but that's not altogether true. Off the top of my head I know
> three systems (IBM mainframes and i series [i.e. AS/400], Guardian
> non- stop) that don't use hierarchic file systems. All three use the
> older named extent/file/subfile model where there is no hierarchic
> concept at either extent or file level (both are flat lists) and
> where all the subfiles in a file not only form a flat list but also
> hold the same type of data, defined by a file-level descriptor.
>
>> Windows has its drive letters. There is the complication of symbolic
>> links.
>>
> OS-9 and VMS also have separate trees on each disk, unlike Unices, but
> only the Unices support symbolic links or multiple hard links per
> file.

VMS also supports files that appear in multiple directories, or at least did
back when I last used it.

>
>> In the olden days the OS handled various types of keyed lookup, with
>> quite eccentric interfaces.
>>
> Thats still alive and well - i series buries that in the OS,
> connected to the file via the descriptor.

VMS also supports files that are not simply lists of bytes, including both
the simple case of sequential files with defined record lengths and the more
complex one of indexed files. In neither of these does seeking to an
arbitrary byte offset make sense.


From: Martin Gregorie on
On Thu, 15 Apr 2010 14:35:14 -0700, Mike Schilling wrote:

> Martin Gregorie wrote:
>> On Thu, 15 Apr 2010 04:48:14 -0700, Roedy Green wrote:
>>
>>> They all have tree structured directories. They all treat files as
>>> blobs of bytes, randomly accessible. They all support a basic set of
>>> attributes.
>>>
>> Sorry, but that's not altogether true. Off the top of my head I know
>> three systems (IBM mainframes and i series [i.e. AS/400], Guardian non-
>> stop) that don't use hierarchic file systems. All three use the older
>> named extent/file/subfile model where there is no hierarchic concept at
>> either extent or file level (both are flat lists) and where all the
>> subfiles in a file not only form a flat list but also hold the same
>> type of data, defined by a file-level descriptor.
>>
>>> Windows has its drive letters. There is the complication of symbolic
>>> links.
>>>
>> OS-9 and VMS also have separate trees on each disk, unlike Unices, but
>> only the Unices support symbolic links or multiple hard links per file.
>
> VMS also supports files that appear in multiple directories, or at least
> did back when I last used it.
>
>
>>> In the olden days the OS handled various types of keyed lookup, with
>>> quite eccentric interfaces.
>>>
>> Thats still alive and well - i series buries that in the OS, connected
>> to the file via the descriptor.
>
> VMS also supports files that are not simply lists of bytes, including
> both the simple case of sequential files with defined record lengths and
> the more complex one of indexed files. In neither of these does seeking
> to an arbitrary byte offset make sense.
>
Yeah, I forgot to comment on that the ability to seek to a byte offset.
The i series source text files hold 80 byte fixed length records though
they aren't indexed. Same probably applies to Z series though not to
Guardian. However, all three systems support ISAM (indexed sequential)
files as natively supported types. They are a natural fit with a number
of languages, notably COBOL, RPG and PL/1.


--
martin@ | Martin Gregorie
gregorie. | Essex, UK
org |
From: Arne Vajhøj on
On 15-04-2010 17:35, Mike Schilling wrote:
> Martin Gregorie wrote:
>> On Thu, 15 Apr 2010 04:48:14 -0700, Roedy Green wrote:
>>> They all have tree structured directories. They all treat files as
>>> blobs of bytes, randomly accessible. They all support a basic set of
>>> attributes.
>>>
>> Sorry, but that's not altogether true. Off the top of my head I know
>> three systems (IBM mainframes and i series [i.e. AS/400], Guardian
>> non- stop) that don't use hierarchic file systems. All three use the
>> older named extent/file/subfile model where there is no hierarchic
>> concept at either extent or file level (both are flat lists) and
>> where all the subfiles in a file not only form a flat list but also
>> hold the same type of data, defined by a file-level descriptor.
>>
>>> Windows has its drive letters. There is the complication of symbolic
>>> links.
>>>
>> OS-9 and VMS also have separate trees on each disk, unlike Unices, but
>> only the Unices support symbolic links or multiple hard links per
>> file.
>
> VMS also supports files that appear in multiple directories, or at least did
> back when I last used it.

It still does.

But it is not used much.

>>> In the olden days the OS handled various types of keyed lookup, with
>>> quite eccentric interfaces.
>>>
>> Thats still alive and well - i series buries that in the OS,
>> connected to the file via the descriptor.
>
> VMS also supports files that are not simply lists of bytes, including both
> the simple case of sequential files with defined record lengths and the more
> complex one of indexed files. In neither of these does seeking to an
> arbitrary byte offset make sense.

Instead it is possible to seek by RFA, which is similar to how
fgetpos/fsetpos work unlike ftell/fseek.

Arne


From: Eric Sosman on
On 4/15/2010 5:35 PM, Mike Schilling wrote:
> [...]
> VMS also supports files that are not simply lists of bytes, including both
> the simple case of sequential files with defined record lengths and the more
> complex one of indexed files. In neither of these does seeking to an
> arbitrary byte offset make sense.

Long ago when I worked with VMS, it supported three "file
organizations:" Sequential, Random, and Indexed. Of these, only
Sequential fit into the I/O model (or straitjacket) adopted by C
and later by Java.

Next time someone asks "How can I delete some data in the
middle of a big file?" and you answer "Copy the whole file but
omit the doomed data," consider that VMS' Random and Indexed
organizations support delete-in-the-middle directly (for suitable
notions of "middle"). I mention this for the benefit of anyone
who might think it "eccentric" to want to avoid copying and re-
copying an enormous file just to erase a little data.

--
Eric Sosman
esosman(a)ieee-dot-org.invalid
First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4 5 6 7 8 9
Prev: Still don't get LayoutManagers
Next: JNDI searches