direct access with Intel fortran
in [Fortran]
|
From: glen herrmannsfeldt on 8 Feb 2010 15:53 Richard Maine <nospam(a)see.signature> wrote: > glen herrmannsfeldt <gah(a)ugcs.caltech.edu> wrote: (snip) >> While the OP uses UNFORMATTED in the examples, there is also >> FORMATTED STREAM. (snip) > I might add, even though it has nothing to do with the OP's issues, that > the restriction on POS= values in formatted stream is a typical piece of > standard-speak. It isn't as though any compiler is actually likely to > enforce the requirement that POS= values in a READ must come from > previous inquire statements. That isn't anticipated and I'd be surprised > to find any compiler bothering to try to enforce it. Seems like that > would be a lot of fuss for no useful purpose. The point is much more > that if you compute a value some other way (such as by adding up > expected byte counts) then you might not end up where you expected > (particularly if you didn't correctly account for possible > system-dependent record terminators). Accidentally positioning to the > middle of a multi-byte datum could be particularly awkward. As long as > you have managed to correctly compute a "reasonable" position, I'd be > quite surprised if any compiler rejected it. Sure it would be possible > for a compiler to keep track of what values had been returned by > inquire, but what a pointless implementation mess that would be unless > the file structure were strange enough that it took something like that > to make POS= work (in which case one might think it more likely that > such files would just be declared non-positionable.) Specifically, in some cases it would be nice to seek to the end of the file, back up a little bit, and then start reading. That is, for example, what the unix tail command does. On most systems the confustion of LF, CR, CRLF record terminators is all that you would run into. It isn't so obvious what the I/O library would do if you seek to the middle of a CRLF and start reading. On the other hand, there are some IBM systems that don't keep track of file positions as byte offsets, but as record number and record offset. On at least one such system, ftell() returns the value 32768*(record)+(offset), and fseek() expects those values. (Records have a maximum length of 32767.) In that case, you might find very strange results from adding or subtracting to the ftell() (or INQUIRE) value. -- glen
From: Richard Maine on 8 Feb 2010 16:03 glen herrmannsfeldt <gah(a)ugcs.caltech.edu> wrote: > On the other hand, there are some IBM systems that don't keep track > of file positions as byte offsets, but as record number and record > offset. On at least one such system, ftell() returns the > value 32768*(record)+(offset), and fseek() expects those values. > (Records have a maximum length of 32767.) In that case, you might > find very strange results from adding or subtracting to the ftell() > (or INQUIRE) value. I didn't know about that particular IBM scheme, but that's at least in the general direction of what I was thinking about when I mentioned file structures "strange" enough that you really only could use POS= values returned from an inquire. In your IBM example, the position still managed to get encoded into a single integer and one still could in theory compute an appropriate value as long as you knew the scheme. I was imagining cases where the position could not reasonably be encoded into a single default integer. In that case, I could imagine that inquire could create a database of positions inquired about and that POS= might just index into that database of inquire results. I don't know of any actual systems that do anything like that, but I can imagine such a thing. What a mess it would be though. -- Richard Maine | Good judgment comes from experience; email: last name at domain . net | experience comes from bad judgment. domain: summertriangle | -- Mark Twain
From: glen herrmannsfeldt on 8 Feb 2010 16:27 Richard Maine <nospam(a)see.signature> wrote: > glen herrmannsfeldt <gah(a)ugcs.caltech.edu> wrote: >> On the other hand, there are some IBM systems that don't keep track >> of file positions as byte offsets, but as record number and record >> offset. On at least one such system, ftell() returns the >> value 32768*(record)+(offset), and fseek() expects those values. >> (Records have a maximum length of 32767.) In that case, you might >> find very strange results from adding or subtracting to the ftell() >> (or INQUIRE) value. > I didn't know about that particular IBM scheme, but that's at least in > the general direction of what I was thinking about when I mentioned file > structures "strange" enough that you really only could use POS= values > returned from an inquire. > In your IBM example, the position still managed to get encoded into a > single integer and one still could in theory compute an appropriate > value as long as you knew the scheme. > I was imagining cases where the position could not reasonably be encoded > into a single default integer. Well, that is almost the case above, as the number of records is not limited to 131072. Also, in the case of variable record length binary files the above systems is still used, contrary to the C standard. > In that case, I could imagine that > inquire could create a database of positions inquired about and that > POS= might just index into that database of inquire results. I don't > know of any actual systems that do anything like that, but I can imagine > such a thing. What a mess it would be though. Or read through the whole file from the beginning and store the record offsets into a big table. Then use that table for seeks. Slow at the beginning but fast after that. OS/360 direct access files are fixed record length, and unblocked. Inefficient for small block sizes. -- glen
From: Ron Shepard on 8 Feb 2010 17:38 In article <hkptjr$rs9$6(a)naig.caltech.edu>, glen herrmannsfeldt <gah(a)ugcs.caltech.edu> wrote: > Specifically, in some cases it would be nice to seek to the end > of the file, back up a little bit, and then start reading. How portable is this: open(unit,...position='append'...) rewind unit read(unit) last_info If something like this works, and is efficient and portable, then this is what I think I would recommend. Almost all file types allow overwriting records at the end of the file. For things like magnetic tape devices, this is the only possible way to overwrite information. Is is sort of an odd concept to overwrite records at the beginning or in the middle of a file and expect all of the information afterwards to remain accessible. In fortran, direct access allows this, but only for fixed-length records, not for arbitrary mixtures of record lengths. If you think about how information is written to most external devices (magnetic or optical in nature), you can see why this is the case. Even a file stored to magnetic disk (a direct access device) is restricted to write an entire sector at a time. If you want to overwrite only part of the sector, and expect the original information to be retained, then either you or the I/O library must first read the original information, replace the part you are overwriting, and then the full sector must be replaced. Although most external devices now are disk-like rather than tape-like, some effort is required to make things appear "as if" they are byte- or word-addressable. So, unless you would prefer to write two separate files (one with the data, the other with the last_info record describing how the data are written), I would recommend putting the header information at the end of the file rather than the beginning. Especially if the above works, it is difficult to imagine anything that is simpler. $.02 -Ron Shepard
From: robin on 8 Feb 2010 21:06
"John Paine" <johnpaine1(a)optusnet.com.au> wrote in message news:4b6f8387$0$6094$afc38c87(a)news.optusnet.com.au... | | I did include a remark about the possibility of using access='direct', but | would prefer not to do that for a number of reasons. Primarily, I'd like the | flexibility of rewriting various portions of the binary files I use and | frequently the actual position will depend on the data that precedes the | location where the data is to be written. access = "direct" is a good way of updating individual records of a file. | I know that I can keep track of | this position (and can even use fseek to directly tell me where I am in the | file), but wanted to check first that there wasn't some obvious option for | the open statement that I was missing that would allow me to rewrite a | portion of the file without truncating it. Also, having to have a fixed | record length would make it much harder to keep track of where I actually | want to write the data and I'd rather revamp my interface to the relevant | system calls than rewrite my code to manage extraneous task of counting | records. |