Compiler Error
in [Fortran]
|
From: glen herrmannsfeldt on 11 Jun 2010 19:46 mecej4 <mecej4.nyetspam(a)operamail.com> wrote: (snip, I wrote) >> The IBM form of unformatted direct access I/O looks like: >> WRITE ( UNFDAT'IREC ) FREQ, SIG(II), >> +D1( JJ ), UMVM(II,JJ), D2( JJ ), BMVM(II,JJ) >> Someone might have missed that apostrophe and replaced >> it with a comma. >> The name IREC looks like a record number, not an ASSIGNed >> format label. The more modern form is: >> WRITE ( UNFDAT,REC=IREC ) FREQ, SIG(II), >> +D1( JJ ), UMVM(II,JJ), D2( JJ ), BMVM(II,JJ) > I cannot find the non-standard version <unitno>'<recno> in my copy of the > IBM VS Fortran manual of 1982. The closest mention of something like this > is under LANGLVL(66) FEATURES NOT IN VS FORTRAN, > . IBM direct-access READ and WRITE It goes back at least to the OS/360 G and H compilers. > Is it the case that DEC replicated this non-standard feature into VAX > Fortran after IBM itself had abandoned it? Well, VAX came out in about 1977 or 1978, the first compilers, I believe, being Fortran 66 compilers. Also on bitsavers is AA-Y868C-TK Fortran-10-20 and VAX compatibility from 1987. Fortran-10 is from TOPS-10 on the PDP-10, some years before VAX. I used direct access I/O on Fortran-10 in 1977, I believe using Fortran I/O, though possibly using assembly routines. I do remember that the record locking was done in assembly. (That was a Fortran port of the BASIC program PCAVES. It had to do record locking before modifying the file.) VS Fortran came out pretty late (for a Fortran 77 compiler). I am not so sure when DEC first implmented this, but it is likely before IBM removed it. -- glen
From: glen herrmannsfeldt on 11 Jun 2010 19:54 dpb <none(a)non.net> wrote: (snip) > Speaking of "blanket substitution" reminds of a _very_ painful episode > from many years ago -- so long ago that the DEC 10 was near the king of > the hill and TECO was the editor of choice (the type your name backwards > w/o punctuation in and see what it does editor :) ). I remember TECO, though I used SOS on the 10. It wasn't until later on RT-11 that I used TECO. > Anyway, had contract to port a large scientific modeling code w/ it's > 60-bit word to 32-bit IBM machine which necessitated changing all SP > constants to DP. You use a 36 bit machine to convert from 60 bit words to 32 bit? > On the apostrophe for the direct access, I recall using it on VAX some > but it's been so long I don't recall what other ramifications it may > have had. I don't remember any bad experiences on that one... :) It seesm that Fortran-10 had it, but I don't know when. -- glen
From: Ron Shepard on 11 Jun 2010 21:20 In article <huu85b$njl$1(a)speranza.aioe.org>, glen herrmannsfeldt <gah(a)ugcs.caltech.edu> wrote: > > ASSIGN 234 TO I > > WRITE(6,I) > 234 FORMAT(' HI THERE!') > > An interesting, though not so needed, feature, it was then > removed in Fortran 90. I do wonder if it ever got used in > any production (as opposed to tests like above) programs. Yes, I used this feature in some of my codes. I have some library routines that print real arrays in a nice column format, and I used the assign statement to select which of two or three formats to use (f or e or g). When f90 compilers started printing out warning messages, I went back and changed the assign statement to a character variable assignment to achieve the same result (or maybe I used a pointer assignment, I forget which now). The assign statement has some minor advantages over the alternatives, one of which is that compilers sometimes verify format statements at compile time for the correct syntax, whereas they seldom do that for character variables used as formats. So during code development, you get a little extra help that way. $.02 -Ron Shepard
From: Richard Maine on 11 Jun 2010 21:35 rfengineer55 <rfengineer55(a)aol.com> wrote: > t's not reasonable to intermix meaningless comments along with helpful > suggestions, or worse, post a message that, in the case of this board, has > nothing to do with fortran troubleshooting. but is meaningless > information... And quite a lot along the same vein, all of which I might describe as having nothing to do with Fortran troubleshooting, but being "meaningless information" minus the information part. All this extensive complaint in response to a single post by dpb where he showed exactly how to duplicate the message in question, which is certainly useful, and he accurately described the ISAM feature being used and the general process of how to sucessfully deal with the kind of code in question. I do not find myself encouraged to post further help in the matter, imagining that I might get a simillar treatment. After all, I have usually found myself quite in agreement with dpb's advice, finding it useful and welcome (just so that is also "on the record")... including this time. My pattern recognition sensor has detected one. I think that's enough from me. -- Richard Maine | Good judgment comes from experience; email: last name at domain . net | experience comes from bad judgment. domain: summertriangle | -- Mark Twain
From: dpb on 12 Jun 2010 00:06
glen herrmannsfeldt wrote: > dpb <none(a)non.net> wrote: .... >> Anyway, had contract to port a large scientific modeling code w/ it's >> 60-bit word to 32-bit IBM machine which necessitated changing all SP >> constants to DP. > > You use a 36 bit machine to convert from 60 bit words to 32 bit? Sure, makes _perfect_ sense, doesn't it... :) The powers that be decreed the only machine we had access to for the editing work was the 10. Once that was to the point it would compile we then did get time of the IBM to debug. I'll not go into it, but some of the hacks used by the original coders (one of the "cleanest" was the use of the upper 18 bits of array indexing variables used as other control bits since the CDC FTN compilers only used the lower 42 as addresses; others were far worse) were so arcane to put into the 32 bit machine the conversion, while it did run and produced comparable results, was so slow as to be essentially worthless in the end. -- |