From: e p chandler on 10 Jun 2010 10:38
> 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/
> 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
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/
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):
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
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.
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
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.
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