Subject: re: I/O - what else [new construct?]

From: [email-masked]
Date: Thu, 25 Jun 92 00:10:58 CDT

There aren't many things more frustrating than to
 have 18 GBytes of data on a disk subsystem in a format
 known only to God his/her vendor.  This is *only*
 acceptable if all access to that data makes its layout
 appear, transparently, to be that of an ordinary Fortran 
 file.

 Users, strange beasts that they are, like the functionality
 of NFS (if not its performance).  They can access any file
 from any system and (punting binary/ascii and byte ordering
 issues) use what they find, immediately.

 Now, vendors (e.g., Intel with CFS, TMC with its DV, or any
 of the RAID vendors) can, and do, supply fileservers that 
 hide (or can hide) weird physical distributions of bits.  
 And that's part of the vendor's job, not that of a language
 design group.

 F90 has plenty of I/O mechanisms [Marc Snir insinuated "too
 many" in the June mtg].  As far as possible we should stick
 with those mechanisms.  Please note that this view says 
 *nothing* about additional data structures that the file
 system might associate with a given file. I would almost
 expect the HPF runtime system to peek at the mapping of 
 its array [section] argument, and the file system's hidden
 info on a file, to see if it can be smart about a particular
 data transfer.  Perhaps vendors can comment here ?

 Individual vendors are going to provide all manner of slick
 ways to "dump/undump" data to their disk (and other) subsystems.
 These (as I mentioned in an earlier msg) will necessarily be
 vendor-dependent.  I will make use of these mechanisms for
 scratch files.  What we don't want to do in HPF is to give
 vendors a way to get "off the hook" with special-purpose I/O 
 mechanisms.  They have to do the Right Thing; they'll do the
 Other Stuff anyway.

 Peter