get CPU info, RAM info
in [Java Programming]
|
Prev: Still don't get LayoutManagers
Next: JNDI searches
From: Martin Gregorie on 15 Apr 2010 17:28 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 15 Apr 2010 17:35 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 15 Apr 2010 19:07 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 15 Apr 2010 22:04 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 16 Apr 2010 09:07
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 |