Prev: Fun with casts
Next: JNDI searches
From: Martin Gregorie on 17 Apr 2010 07:20 On Fri, 16 Apr 2010 20:06:37 -0400, Arne Vajhøj wrote: > It is: sequential, relative and indexed. > > Random access (as opposed to sequential access) is possible to all file > organizations. > > Indexed is really a little database in itself. > > I believe that some IBM OS'es have similar functionality. > I think all mainframes from that period had more or less the same capabilities for accessing records in a disk file. I used ICL kit (first 1900 series and then 2900 series). These offered the following access methods: sequential - variable length records, prefixed with a length word stored in arrival sequence. self-indexed - fixed length records, retrieved by record number indexed - fixed length records, retrieved by a key field, stored in key sequence and accessed via a distributed index random - fixed length records, retrieved by a key field, stored via a hash of the key All four organisations could be read sequentially. In that era files tended to occupy fixed places on a disk: the 1900's basic file allocation amounted to partitioning the disk and treating each partition, which was named for access, as a file. Source and executables were kept in 'subfiles' - variable sized chunks of a file. Only the George 3 OS had the sort of hierarchic filing system that we now expect. -- martin@ | Martin Gregorie gregorie. | Essex, UK org |
From: Eric Sosman on 17 Apr 2010 07:57 On 4/16/2010 8:06 PM, Arne Vajh�j wrote: > On 16-04-2010 09:07, Eric Sosman wrote: >> >> Long ago when I worked with VMS, it supported three "file >> organizations:" Sequential, Random, and Indexed. > > No - it is: sequential, relative and indexed. Thanks for the correction. (As I said, my VMS work was long ago, and my gray cells suffer a few parity errors.) -- Eric Sosman esosman(a)ieee-dot-org.invalid
From: Mike Schilling on 17 Apr 2010 10:41 Eric Sosman wrote: > On 4/16/2010 8:06 PM, Arne Vajh�j wrote: >> On 16-04-2010 09:07, Eric Sosman wrote: >>> >>> Long ago when I worked with VMS, it supported three "file >>> organizations:" Sequential, Random, and Indexed. >> >> No - it is: sequential, relative and indexed. > > Thanks for the correction. (As I said, my VMS work was > long ago, and my gray cells suffer a few parity errors.) A VAX would have corrected those, or at least detected them.
From: Stanimir Stamenkov on 17 Apr 2010 11:16 Thu, 15 Apr 2010 21:28:43 +0000 (UTC), /Martin Gregorie/: > only the Unices support symbolic links or multiple hard links per file. Windows with NTFS supports file hard links and directory symbolic links since Windows 2000: http://msdn.microsoft.com/en-us/library/aa363860(VS.85).aspx http://www.microsoft.com/resources/documentation/windows/xp/all/proddocs/en-us/fsutil_hardlink.mspx http://technet.microsoft.com/en-us/sysinternals/bb896768.aspx AFAIK Windows 7 supports file symbolic links, also. -- Stanimir
From: Arne Vajhøj on 18 Apr 2010 21:52
On 17-04-2010 07:20, Martin Gregorie wrote: > On Fri, 16 Apr 2010 20:06:37 -0400, Arne Vajhøj wrote: >> It is: sequential, relative and indexed. >> >> Random access (as opposed to sequential access) is possible to all file >> organizations. >> >> Indexed is really a little database in itself. >> >> I believe that some IBM OS'es have similar functionality. >> > I think all mainframes from that period had more or less the same > capabilities for accessing records in a disk file. I used ICL kit (first > 1900 series and then 2900 series). These offered the following access > methods: > > sequential - variable length records, prefixed with a length word > stored in arrival sequence. > self-indexed - fixed length records, retrieved by record number > indexed - fixed length records, retrieved by a key field, stored > in key sequence and accessed via a distributed index > random - fixed length records, retrieved by a key field, > stored via a hash of the key > > All four organisations could be read sequentially. And there were often pretty good language support for those accesc methods in Cobol, Fortran, Pascal etc.. Arne |