FCC VAX VMS Fortran program AMDIST
in [Fortran]
|
Prev: Intel Fortran compiler
Next: Intel Fortran etc.
From: e p chandler on 10 Jun 2010 10:38 "mecej4" wrote > The program assumes that it is writing to an ANSI/VT-100 terminal. > Specifically, BELL (ASCII 7) and escape sequences are output in WRITE > statements. These will need to be fixed if you do not want to slow down > the program considerably. Bear in mind that ANSI.SYS support no longer exists on Windows. It did work on XP but only for 16 bit (DOS) programs under COMMAND.COM instead of CMD.EXE and only if CONFIG.NT (not CONFIG.SYS) was modified. 64 bit Vista drops 16 bit support (DOS and Win16) entirely.
From: Ron Shepard on 10 Jun 2010 10:54 In article <4C10A4DA.4030103(a)net-b.de>, Tobias Burnus <burnus(a)net-b.de> wrote: > I think Tim found the line, which causes the error you are seening. You > could try replacing > character*2 escape /'1B'x/ > by > character(2) :: escape = achar(z'1B') Why use the confusing hex form for the integer? Why not simply achar(27) where 27=16+11. Also, why is the variable escape declared as two characters rather than one. It is always used in an A1 field, so it seems it should be one character long rather than two. The fact that is is two character rather than one prevents the programmer from using expressions like escape // '[0m' to generate the terminal escape sequences. It is much easier to convert codes like this to standard form when the programmer still has access to a compiler that accepts the nonstandard extensions. In this case, sections of code can be rewritten and tests of all of the internal state, before and after, can be done. For this code, that should have happened about 30 years ago for the nonstandard declarations, and 20 years ago for the achar() related stuff. After you no longer have support for all the nonstandard stuff, then the programmer must try to port the code without the ability to compare the internal state, which is a much much harder task. Of course, the OP is stuck with code that was written that way by someone else, so this comment applies more to current and future code. The real purpose of compatibility libraries and compiler flags that allow nonstandard extensions is to facilitate porting the code to standard form, not necessarily to allow the nonstandard code to be compiled indefinitely. $.02 -Ron Shepard
From: Ken Fairfield on 10 Jun 2010 14:41 Note up front: I have great hesitation in replying to this thread any more since my previous replies seem to have gone unheeded like those of many other regulars here. Nevertheless. On Jun 9, 10:27 pm, rfengineer55 <rfenginee...(a)aol.com> wrote: > By popular demand, here is one of my FCC programs that Is > generating Gfortran errors, two to be exact. > > Incompatible type in DATA statement at <1>: Attempted conversion of > type integer to type character. > <during initialiation> Edit the lines that have combined declaration and data initialization into two lines. For example, integer ibc /42/ would become: integer ibc data ibc /42/ Standard F77 form. [...] > I have about six FCC programs that fail to compile for strange > problems similar to this one. BTW one of the respondents here asked if > I was working from a photocopied DEC VMS Fortrann manual. I wish. I > have no DEC documentatio at all. The best I have been able to do is to > find two or three generic college VAX texdtbooks from ABEbooks.com > which WERE helpful in helping me unravel a syntax error I was running > into with the OPEN statement; VMS OPEN is very different from Fortran > 77 OPEN :-) See: http://h71000.www7.hp.com/doc/fortran.html for the VMS Fortran online documentation. While that compiler is F95 compliant, it is also (as I mentioned before) F77 compliant *and* it documents various VMS Fortran extensions. [...] In *quickly* looking at the source you posted, I see three VMS library routines (which you've commented-out): LIB$GET_FOREIGN. This is used to retrieve command-line arguments. Most compilers have an O/S-specific and/or compiler-specific alternative. You can often replace it with a simple "READ(*,*) COMMAND" if you are willing to supply the arguments on a line that follows the program invocation. LIB$STOP(status) This is simply a convenient way to get the error message associated with "status" written to the output device while halting the program. If you're not interested in status, a simple Fortran STOP is good enough. Or you can WRITE(*,*) STATUS and the STOP. LIB$GETDVI The subroutine in which this appears is mostly trying to determine if there's an actual terminal attached, as opposed to a batch run with output to a log file (I presume). You've handled that sort opposite of the way I would, by hard-coding that you do have a terminal attached. Your choice. DATE (Not VMS-specific) All the compilers you will be using support the DATE_AND_TIME Fortran intrinsic function. Use it. Otherwise, having commented-out the call, you reference the character variable TODAY without ever having given it a value, which is a program error. Three other points: The missing AMKEYS.INC *will* need to be supplied. You need to determine what reasonable contents it should have, but you at least need to supply a file, even if it's empty, to satisfy the compiler. At least one character variable holds the "path" to a file, whether input or output I didn't check. You need to determine how it is used and substitute a path+file specification appropriate to the platform you're using. OPEN statements. See the VMS Fortran documentation at the link I supplied above. VMS extensions are clearly indicated along with their standard-conforming replacements. Again, I didn't check them carefully, but I doubt there is anything very VMS-specific (other than the "spelling") in any of them. Regards, Ken
From: Ken Fairfield on 10 Jun 2010 14:49
On Jun 10, 11:41 am, Ken Fairfield <ken.fairfi...(a)gmail.com> wrote: [...] > At least one character variable holds the "path" > to a file, whether input or output I didn't check. > You need to determine how it is used and substitute > a path+file specification appropriate to the platform > you're using. amdbname is the variable in question and is using VMS file specification syntax. It needs to be changed to Windows and/or Linux syntax. > > OPEN statements. > See the VMS Fortran documentation at the link I > supplied above. VMS extensions are clearly > indicated along with their standard-conforming > replacements. Again, I didn't check them carefully, > but I doubt there is anything very VMS-specific > (other than the "spelling") in any of them. In particular, AMDBNAME points to an RMS indexed files, something *very* VMS-specific. You probably don't want to go to all the trouble of installing an "ISAM" package on your computers, so you need to understand the context of that file, and provide a different method of reading it. I.e., you probably will need to read the file form the beginning and compare the appropriate field in each line you read to the "key" string until you get a match. Reading an indexed file by key is fast, easy and efficient in VMS, but it is certainly not necessary: a brute force method will work just as well. -Ken |