From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from out4.theservercompany.com (out4.theservercompany.com [104.36.56.139]) by sourceware.org (Postfix) with ESMTPS id D58C038582B0 for ; Wed, 8 Mar 2023 13:30:40 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org D58C038582B0 Authentication-Results: sourceware.org; dmarc=pass (p=reject dis=none) header.from=logikalsolutions.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=logikalsolutions.com Received: from poseidon.geekstorage.com ([162.249.125.20]) by mailx2.theservercompany.com with esmtps (TLSv1.2:AES128-GCM-SHA256:128) (Exim 4.92) (envelope-from ) id 1pZts9-0006co-UW; Wed, 08 Mar 2023 07:30:38 -0600 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=logikalsolutions.com; s=default; h=Content-Transfer-Encoding:Content-Type: In-Reply-To:From:References:Cc:To:Subject:MIME-Version:Date:Message-ID:Sender :Reply-To:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help: List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=6W8k7WoG0VgiHxgXWDX+QZOdQ8m/K2uNEaRVdT+PtS8=; b=QkhiGCKmOfNZzc+iKPDlRYP7qc JWkXj5ogf2fI9Hjkc14xPoHQf6TX7jBpK+89rKrrkcDzhJoEnQKRIF7rj3fxX3qqa/Yu5VW87tDAi MG1SLKtddzsVP+KS2jYPvQeqVy2nb/aAYhiKmTIrPGVtOfVEQP8w0ZIx5UoDh39rfEDyW97yBoVu0 QoXpza5g9+kGllybHog6dToEIo4bK+uY3Lqer92ucUCowxx5u1VnAzcxTxKD/QwNb0A0fLnqLnn7Z COJuzrKa344qT00C/cCDZAwiRynScj0i+eC5V8ePPfkrFeZNDYNKvHhmzLU5+b2ijhmBZdbBHEZfA SrkU01OQ==; Received: from [207.113.211.152] (port=50329 helo=[192.168.1.6]) by poseidon.geekstorage.com with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.95) (envelope-from ) id 1pZts6-008pO9-C9; Wed, 08 Mar 2023 07:30:22 -0600 Message-ID: <836b7c0f-4a1f-a92f-d835-8207da0f58cc@logikalsolutions.com> Date: Wed, 8 Mar 2023 07:31:07 -0600 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101 Thunderbird/102.8.0 Subject: Re: F77 indexed file support To: Arjen Markus , Thomas Koenig Cc: "fortran@gcc.gnu.org" References: <8f40b52e-c264-d1e4-06dd-fb9990a64bb8@logikalsolutions.com> <320b23ee-c38c-583a-73b9-78739c8f2046@netcologne.de> Content-Language: en-US From: Roland Hughes In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Get-Message-Sender-Via: poseidon.geekstorage.com: authenticated_id: roland@logikalsolutions.com X-Authenticated-Sender: poseidon.geekstorage.com: roland@logikalsolutions.com X-Originating-IP: 162.249.125.20 X-SpamExperts-Domain: geekstorage.com X-SpamExperts-Username: 162.249.125.20 Authentication-Results: theservercompany.com; auth=pass smtp.auth=162.249.125.20@geekstorage.com X-SpamExperts-Outgoing-Class: ham X-SpamExperts-Outgoing-Evidence: Combined (0.26) X-Recommended-Action: accept X-Filter-ID: Pt3MvcO5N4iKaDQ5O6lkdGlMVN6RH8bjRMzItlySaT8kkT1X9YKhkV3+cdnceoBwPUtbdvnXkggZ 3YnVId/Y5jcf0yeVQAvfjHznO7+bT5yjaEgWr/h6FKAvspk8DTKsx5xE+Ln9hA7SMWOKG9/F5V+s uNm0eHkWJ/o8NJlaVI9Uaf4JfWqcah2162FRSyPn+izECAYYe3lcyRUgeTYrUU1/gzQfM88V/+BY 6rSZm+SlTiUJe/shiVdRFyOK4GMIAc0uXzxyDVCcVc2YNWS6fdZoiQ3OhJrhZ26eqrLcsJGckDiZ d5nI40K65woA3trs7+UKn2m1/aKQycjQgTkalK3l0x00U3K//evj2PyUHAd93AaTm/3mMnvgQO3Q 4FKrLCUT1u6vY8RICxBVjmZKKQISrgforfpawCLJdMIDKa7tuA1BGbU54TA1+z9fso2mg46a7F+L aHXXFQyrAsHe1OwEbjuUdBkI0ldE3lQRab8aSwwkzF4ks8Q5NmQD3k2Ym4aVlBObnVhI6K7gAuPO 49lsFpV5DORhRjcUG1t5HeCez1OLpXUS8pu2Pqft5x+tZ6NDi09Sehf7j1ee0+xFN+YuCn6b3uQg 2muMEmXB2pKIaSGk0QGAqgKewzVvrs/gKfiCf0j+rvPF2qG9XqwksPKYzhX51i/DfOBpfkwL5JiE KUZCoFouj/h7lFZN6N2kwXjQxqN+xRHPwvh2ZAsqZawiQjYgtOCUydvLSsE/YY4fJGvm/2JDXAeI wNOSbofb2eEUhNXUFbK6oaWt8qArQDYfTH509XQw8Xdr+MnJzzZKxqBK+ZcO17SYcohm8EEAP7g/ v82w1PskcK86cc+ng910qthNo0mZSs/doYXw+EGeyyvAeEviNcsGJspYHuVTmTmwfXjBs98VHDtT df+O6XVTpto7Dy4VAmIJZBVFLMCZlLKVv9kOQCBExA99ys9SHHASJNUmoOHSoqgqxfHmWXMM82l3 Ba8nClkKN6a/1UevqrJWO7qyOh8aANRjun1FY2z6t9jYnLo7yHJDv86Kw62pFexBpO5sQguRSyhI 60nwLOaD/NW0/dh+Mx2zcnx/hamTte9fgu+yFqf8/j2SABg0769RuEX5d22ZpKjZVCJ5c6eCov7G XMmQi8Vn+J6kh6tttFpHnTVRPX/oOV1Q/SQfHnss8YLIuSA8NNHIAeU= X-Report-Abuse-To: spam@mailx1.theservercompany.com X-Spam-Status: No, score=-0.6 required=5.0 tests=BAYES_00,BODY_8BITS,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,NICE_REPLY_A,SPF_HELO_NONE,SPF_PASS,TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: Hello Arjen, Thanks for your reply. You are confusing RMS Files-11 file versioning with Indexing. Sorry, this got away from me. Once I started I couldn't stop. Real computers, didn't matter who made them or their OS, all provided at least one type of indexed file. These were business class platforms. Even scientific users needed a business class platform. Organization types: *DIRECT * This was also called a "Hash File" on many platforms. It was a glorified sequential file you accessed via RECORD NUMBER. Sometimes data was stored and accessed as an on-disk array. Most had some kind of hash algorithm. On the PC platform a somewhat crippled version of this was the file format used by DBase and the other Xbase tools of the day used. Each "index" was stored in its own file. The platform could only have one "index" open at a time so inserts/additions to the data were only reflected in that file. You had to PACK the data file and REINDEX each time you opened a different "index" because that was the only way to be certain they were in synch. https://www.theminimumyouneedtoknow.com/xbase_book.html If you really want to know more, you can download that book from the xBaseJ project on SourceForge. I wrote it and donated it to the project. No matter what platform DIRECT access had the problem of deletions. The were only "marked" as deleted within the data. You had to PACK a file to remove them. Lazy developers used bad hash algos so you also had to deal with collisions and missing data. Today we have amazing hash algos. Even in commercial relational database systems certain indexes/keys are implemented via hash because it is the fastest for look-up only data. DIRECT access files are still popular on the lesser platforms because, if you have a logically contiguous sequential file and mandate fixed size records, the C/C++ fseek() function lets you basically implement one. *ISAM* I had to spend two weeks in COBOL I drawing on paper and chalk board until I understood how this worked. While the VAX claimed support for it (to make it easier to port IBM software to VAX) I never encountered anyone using it. Even this small description will be more than anyone wishes to know about it. Indexed Sequential Access Method was really only used on platforms that allocated disk storage in Volumes, Cylinders, and Tracks. A certain number of tracks (or cylinders) were allocated to the "index area." This was assumed to be at the top of the file. There key values would be grouped into partially filled "buckets" along with their data track number. The Primary Data Area would be allocated a certain number of tracks, cylinders, or even volumes (a volume is an entire disk spindle). The Overflow Data Area got allocated tracks, cylinders, and potentially volumes as well. We will skip the conversation of "bucket splits." Buckets were fixed size, you tried to keep them 50% or less full. Finding a record was a linear search in the index area reading the first entry of each bucket until you found one greater than what you were looking for which meant your value existed in the previous bucket if at all. Assuming your key was in said bucket, you then read the track in the data area and chewed through it record by record (they could be packed) looking for the record with your key or one greater. (lesser if you were using a descending index) After going through one or more tracks and coming up empty handed your search was not over, it had to perform a sequential search on the entire overflow area. All of this pain I just shared with you was handled by the OS. Your COBOL, FORTRAN, BASIC, DIBOL, etc. program simply did READ RECORD blah KEY EQ more-blah. If you were coding in Assembly, this pain you had to do yourself, especially if your OS didn't provide a system services library to do it mostly for you. Deletions are simply flagged deleted. You have to REORG these files to empty out the overflow area, reclaim deleted data space, and clean up the buckets. *VSAM* Virtual Sequential Access Method. Has only Index Areas (plural) and Data Areas. Each "bucket" is at least one disk block in size. At its end it contains a link to the next area bucket. These buckets can be scattered anywhere on disk. If you have bound volumes or any other OS ability to group multiple disks into one logical disk, they can be on any of those spindles. Data areas are the same. You have the option of processing this file sequentially by doing a keyed hit to the first record of some index and sequentially reading. It will read in key sequence until end. Index buckets are required to have the actual data bucket of the record. Records could span blocks/buckets and they could be packed. Deleted records were actually deleted. If block/bucket spanning was enabled you paid a bit of overhead price while things shuffled around. The file system keeps track of the lowest and highest key value for each index as well as the bucket count for the index. A binary search is done to find the correct index bucket. Again, COBOL, FORTRAN, BASIC, DIBOL, etc programmers just did their language's version of READ RECORD blah KEY EQ more-blah. The OS did everything else. Assembler programmers on platforms that didn't have system services to call had to do all of this on their own. We all had to take Assembler so we all had to learn this stuff. Sorry, once that started spilling out I couldn't stop it. Roland On 3/7/2023 11:32 PM, Arjen Markus wrote: > I have never worked much with VAXes, but I do remember that VAX used a > file system where you made a new version of a file and the older > versions were automatically kept. I guess that is the purpose of the > INDEXED organisation. It is not so much a limitation of gfortran that > it does not support this, but a consequence of the operating system's > completely different view on files and file management. > > Regards, > > Arjen > > Op di 7 mrt 2023 om 23:58 schreef Thomas Koenig via Fortran > : > > Hi Roland, > > >   210  OPEN (UNIT=K_DRAW_CHAN, > >       1        FILE=DRAWING_DATA, > >       2        STATUS='OLD', > >       3        ORGANIZATION='INDEXED', > > I'd never heard of that one up to now. > > >       4        ACCESS='KEYED', > >       5        RECORDTYPE='FIXED', > >       6        FORM='UNFORMATTED', > >       7        RECL=K_DRAWING_RECORD_SIZE/4, > >       8        CARRIAGECONTROL='FORTRAN', > >       9        KEY=(1:8:CHARACTER), > >       1        DISP='KEEP', > >       2        IOSTAT=L_DRAW_ERR, > >       3        ERR=999) > > > > The ORGANIZATION='INDEXED' is key. > > > > GnuCOBOL > > > > https://gnucobol.sourceforge.io/ > > > > uses the BerkleyDB (sp?) library so the standard COBOL indexed file > > support from the big computers can at least be mimicked. > > > > I'm searching everywhere and I cannot find Gnu Fortran (any flavor) > > having an ORGANIZATION clause in the OPEN(). > > ORGANIZATION is not an extension that gfortran supports. > ifort, which traces its lineage back to VMS Fortran, supports > ORGANIZATION, but not 'INDEXED', according to > > https://www.intel.com/content/www/us/en/develop/documentation/fortran-compiler-oneapi-dev-guide-and-reference/top/language-reference/file-operation-i-o-statements/open-statement-specifiers/open-organization-specifier.html > > This is likely a Fortran interface to a VMS speciality; the older > operating systems had stuff like that.  UNIX did away with all > the record-orientation (I also remember VSAM and ISAM data sets > on old IBM mainframes) and UNIX and derivatives, and Windows, now > just offers the "stream of bytes" model. > > So, if you need the functionality, you will have to implement it > yourself, possibly via a database. > > Best regards > >         Thomas > -- Roland Hughes, President Logikal Solutions (630)-205-1593 (cell) http://www.theminimumyouneedtoknow.com http://www.infiniteexposure.net http://www.johnsmith-book.com