From Craig.Dedo@mixcom.com  Thu Feb  1 01:40:34 1996
Received: from mixcom.mixcom.com (mixcom.mixcom.com [198.137.186.100]) by dkuug.dk (8.6.12/8.6.12) with ESMTP id BAA01997 for <sc22wg5@dkuug.dk>; Thu, 1 Feb 1996 01:40:07 +0100
Received: from 156.46.42.211 by mixcom.mixcom.com (8.6.12/2.2)
	   id SAA12706; Wed, 31 Jan 1996 18:40:57 -0600
Message-Id: <199602010040.SAA12706@mixcom.mixcom.com>
MIME-Version: 1.0
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
Date: Tue, 30 Jan 96 20:00:48 -0600
From: Craig Dedo <Craig.Dedo@mixcom.com>
Subject: Re: (x3j3.1996-41) Re: fodder for meeting
To: "Jerrold L. Wagener" <jwagener@ionet.net>
Cc: WG5 Mailing List <sc22wg5@dkuug.dk>
In-Reply-To: <9601301315.AA17347@hwmac4>
X-Mailer: SPRY Mail Version: 04.00.06.17

Dear Jerry and Members of the WG5 Mailing List:

On Tue, 30 Jan 1996, "Jerrold L. Wagener" <jwagener@ionet.net> wrote:

>Over a year ago I pointed out via email (I'll try to dig out that message, but 
>it's locked in the Amoco email files) the "inconsistency" between the open-
>stmt and inquire-stmt RECL= specifiers (the former allows scalar-int-expr but 
>the latter only default-scalar-int-expr), and the "inconsistency" between the 
>read/write-stmt REC= and inquire-stmt NEXTREC= specifiers (again the former 
>alows scalar-int-expr but the latter only default-scalar-int-expr).  My 
>message include proposed text, which removed "default-" in six places : R924 
>(twice), 9.6.1.13 (twice), and 9.6.14 (twice).

    Too bad this did not get the attention it deserved at the time.  Unfortunately, I do not remember any such message.  

    [Several wonderful practical examples deleted]
>
>There could be a possible C interoperability reason for removing the INQUIRE 
>statement restrictions, since C files do not have record structure.  
                         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^--?????

    I may be wrong on this (Stan Whitlock or Steve Lionel can correct me) but I believe that DEC C for OpenVMS conducts its file operations thru regular RMS file calls and therefore supports all of the (elaborate and complex) RMS file structure.  The OpenVMS RMS file system is a record oriented file system.

> It might 
>be desirable in some such cases to have a large Fortran direct file (greater 
>than 2 giganumbers) that has only one record or, alternatively, records 
>consisting of only one number.  In this case standard Fortran 90/95 cannot 
>handle a great many existing practical files.

    If this is true, we should fix the problem ASAP.  The purpose of ANY programming language is to support the developoment of practical applications.  Not being able to "handle a great many practical files" means that the language is broken.

>I don't know how serious the implementation issues are, but from a language 
>point of view it is too bad we didn't fix this in F95.  I can't get too worked 
>up about it's practical necessity, however, since both OPEN and READ/WRITE can 
>handle these large files (at least for implementations that support large 
>enough integers), and in most practical cases we can work around the use of 
>INQUIRE.

>Jerry

    I very strongly disagree about the practical necessity.  Making INQUIRE useless for a significant fraction of practical files does not strike me as sound language design.  Nor does creating unnecessary irregularities and gotchas for non-experts.  

    We should contact Miles to see what means are available for fixing this problem, even though Fortran 95 is nearly ready to go to press.  If we cannot make any more technical edits, we should see what other means are available.  

    Although I do not like the idea of creating yet another parallel development effort, maybe we should seriously consider some means of fixing problems like these which are small enough through some kind of Interim Technical Fixit Process.  Just an idea.  If people don't like it, they should suggest some other alternative.  However, doing nothing is unacceptable; it does not serve our customers.

----------
Sincerely,
Craig T. Dedo             	Internet:    Craig.Dedo@mixcom.com
Elmbrook Computer Services	Voice Phone: (414) 783-5869
17130 W. Burleigh Place		
Brookfield, WI   53005		Disclaimer:  These opinions are mine alone.
USA				They do NOT represent any organization.

"Those who would give up essential Liberty, to purchase a little temporary 
    Safety, deserve neither Liberty nor Safety."    -- Benjamin Franklin

