Home > Archive > Fortran > June 2004 > Problems with VMS and g77 commonality attempt
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
Problems with VMS and g77 commonality attempt
|
|
| Rob Chambers 2004-06-25, 7:43 pm |
| I'm currently trying to take a legacy VMS FORTRAN application and get it
running with g77 under Windows. I would also like to achieve code
commonality between the two systems. I've solved most of the problems I've
come across so far, and am now left with two things that seem to be
system-specific.
The first issue is that of file record length - VMS reads the file in
question as records of 128 long words (i.e. RECL=128), the PC requires the
record length to be 512 bytes. The VMS FORTRAN help describes the /ASSUME
"BYTEREC" option to force VMS to use byte units, but no matter how I format
the compilation command, VMS can't understand its usage. /ASSUME=all or
/ASSUME without arguments are accepted by the compiler, however (this is on
OpenVMS VAX V7.1). What is the correct form/usage of this command?
The second issue is the use of VMS logical names to define a directory in
which files may be found. I first tried to set environmental variables in
the DOS box to emulate the way the VMS program worked, but without success.
It looks like I have to use a getenv() or getarg() intrinsic function to do
the equivalent in g77. As I said, I'd like to have common code between the
VMS and PC versions if possible...but is that a realistic objective?
Thanks in advance for any assistance.
Rob
--
"Freedom of the press in Britain is freedom to print such of the
proprietor's prejudices as the advertisers do not object to." - Hannen
Swaffer
| |
| Jan Vorbrüggen 2004-06-25, 7:43 pm |
| > The first issue is that of file record length - VMS reads the file in
> question as records of 128 long words (i.e. RECL=128), the PC requires the
> record length to be 512 bytes. The VMS FORTRAN help describes the /ASSUME
> "BYTEREC" option to force VMS to use byte units, but no matter how I format
> the compilation command, VMS can't understand its usage. /ASSUME=all or
> /ASSUME without arguments are accepted by the compiler, however (this is on
> OpenVMS VAX V7.1). What is the correct form/usage of this command?
It's not clear whether you have tried /assume=byterec...that is the form
that should work. You could also request a listing file, which will contain
a report on all options that have been selected.
> The second issue is the use of VMS logical names to define a directory in
> which files may be found. I first tried to set environmental variables in
> the DOS box to emulate the way the VMS program worked, but without success.
> It looks like I have to use a getenv() or getarg() intrinsic function to do
> the equivalent in g77. As I said, I'd like to have common code between the
> VMS and PC versions if possible...but is that a realistic objective?
For such things, I tend to think it's better to have a system-depedent file
that localizes such details. I know that the C RTL emulates the getenv
behaviour for logical names, but I tend to think the Fortran RTL won't. And
the mechanisms are distinct enough that you will get users  . Having
seperate implementations for the same routine that does the work of
determining the proper directory is the way to go, IMO.
Jan
| |
| Steve Lionel 2004-06-25, 7:43 pm |
| On Mon, 21 Jun 2004 14:43:03 +0100, "Rob Chambers"
<robert.chambers@yourpants.baesystems.com> wrote:
>The first issue is that of file record length - VMS reads the file in
>question as records of 128 long words (i.e. RECL=128), the PC requires the
>record length to be 512 bytes. The VMS FORTRAN help describes the /ASSUME
>"BYTEREC" option to force VMS to use byte units, but no matter how I format
>the compilation command, VMS can't understand its usage. /ASSUME=all or
>/ASSUME without arguments are accepted by the compiler, however (this is on
>OpenVMS VAX V7.1). What is the correct form/usage of this command?
/ASSUME=BYTERECL
(though BYTEREC should work.) What version of VAX Fortran are you using? You
need at least version 6.4.
>The second issue is the use of VMS logical names to define a directory in
>which files may be found. I first tried to set environmental variables in
>the DOS box to emulate the way the VMS program worked, but without success.
>It looks like I have to use a getenv() or getarg() intrinsic function to do
>the equivalent in g77. As I said, I'd like to have common code between the
>VMS and PC versions if possible...but is that a realistic objective?
I assume this is for an OPEN statement? UNIX and Windows systems don't have
the integration of environment variables into file specifications the way VMS
does with logical names. You're going to have to fake it with getenv.
Steve Lionel
Software Products Division
Intel Corporation
Nashua, NH
User communities for Intel Software Development Products
http://softwareforums.intel.com/
Intel Fortran Support
http://developer.intel.com/software/products/support/
| |
| Rob Chambers 2004-06-25, 7:43 pm |
| Jan Vorbrüggen temporarily inconvenienced several billion electrons
with:
> It's not clear whether you have tried /assume=byterec...that is the
> form that should work.
I've tried:
$ for/assume=byterec opensquare.for
%DCL-W-IVKEYW, unrecognized keyword - check validity and spelling
\BYTEREC\
$ for/assume=(byterec) opensquare.for
%DCL-W-IVKEYW, unrecognized keyword - check validity and spelling
\BYTEREC\
$ for/assume=all opensquare.for
(compiles without error)
> Having seperate implementations for
> the same routine that does the work of determining the proper
> directory is the way to go, IMO.
OK, I thought as much. It's not a big problem.
Rob
--
"I don't kill flies, but I like to mess with their minds. I hold them
above globes. They freak out and yell 'Whooa, I'm *way* too high.'" -
Bruce Baum
| |
| Rob Chambers 2004-06-25, 7:43 pm |
| Steve Lionel temporarily inconvenienced several billion electrons with:
> What version of VAX Fortran are you
> using? You need at least version 6.4.
How do I find out directly? I'm using OpenVMS 7.1, and I was under the
impression that the compiler was upgraded to whatever the version is that
shipped with 7.1, though it may not have been. I've tried /assume=all and
/assume without parameters, and both seem acceptable to the compiler, but
$ FOR/ASSUME=(ACCU,BYTERECL,NODUMM) opensquare.for
%DCL-W-IVKEYW, unrecognized keyword - check validity and spelling
\BYTERECL\
It's not a big problem, though. These problems only occur in one file of the
set which makes up the application, so I can easily maintain two copies if
necessary.
Rob
--
"If you were one of Bono's brain cells you'd be lonely." - Tom (Mekons)
| |
| John Mansell 2004-06-25, 7:43 pm |
| I believe that we invented this particular wheel many years ago,
probably along with others unknown...
We ported apps from TOPS10 to VMS to MS-DOS to Windows etc.
Here are some comments based on our experiences. Without exception, they
state the obvious.
1. Try to get 98%-plus source in standard fortran (f77 in this case).
This means avoiding 'nice' language extensions, such as VAX fortran
structures and records, but this advice may come too late ...
2.All OS-specific stuff should be shunted into a set of subroutines /
functions /parameters that vary from OS to OS. The calls to these should
be the same over all OSes. Variations in OPEN statements seem to cause a
lot of work here (not just the words/bytes stuff, but such things as how
to implement appending to a file (if at all), and even the idea of what
a file name is.
3.I don't know /ASSUME: I used RECL=IFACT*nnn, where nnn is the record
length in words (common for all implementations) and IFACT is a
parameter =1 for VMS, =4 for almost anything else. Define the IFACT
parameter on a per-OS basis in a file and INCLUDE it (not standard, I
know, but INCLUDE has common syntax over many fortrans).
4. If you need a getenv (the polyhedron site says that g77 has getenv),
you could write a VMS getenv which returns the value of a logical (VMS
is clever - you can have a list-valued logical (in one or more tables)
with your files spread over directories enumerated in the list - but
assume that you have a list of one in just one table and just one
directory).
5. If you are looking at getting arguments off the command line, take a
look at http://www.winteracter.com/f2kcli/ . There are versions for VMS
and g77. This way, you can make your calls common to most OSes - you
then put the actual implementation into a non-standard library.
In message <40d6e43f$1_1@baen1673807.greenlnk.net>, Rob Chambers
<robert.chambers@yourpants.baesystems.com> writes
>I'm currently trying to take a legacy VMS FORTRAN application and get it
>running with g77 under Windows. I would also like to achieve code
>commonality between the two systems. I've solved most of the problems I've
>come across so far, and am now left with two things that seem to be
>system-specific.
>
>The first issue is that of file record length - VMS reads the file in
>question as records of 128 long words (i.e. RECL=128), the PC requires the
>record length to be 512 bytes. The VMS FORTRAN help describes the /ASSUME
>"BYTEREC" option to force VMS to use byte units, but no matter how I format
>the compilation command, VMS can't understand its usage. /ASSUME=all or
>/ASSUME without arguments are accepted by the compiler, however (this is on
>OpenVMS VAX V7.1). What is the correct form/usage of this command?
>
>The second issue is the use of VMS logical names to define a directory in
>which files may be found. I first tried to set environmental variables in
>the DOS box to emulate the way the VMS program worked, but without success.
>It looks like I have to use a getenv() or getarg() intrinsic function to do
>the equivalent in g77. As I said, I'd like to have common code between the
>VMS and PC versions if possible...but is that a realistic objective?
>
>Thanks in advance for any assistance.
>
>Rob
>--
>"Freedom of the press in Britain is freedom to print such of the
>proprietor's prejudices as the advertisers do not object to." - Hannen
>Swaffer
>
>
--
to reply, interpret the following:
John Mansell: john at wcompsys dot co dot uk
| |
| Jan Vorbrüggen 2004-06-25, 7:44 pm |
| >>What version of VAX Fortran are you using? You need at least version 6.4.
> How do I find out directly?
$ FORTRAN/LIST NL:
and look at the header of the listing file. Or, for the more adventurous,
ANAL/IMAGE SYS$SYSTEM:FORTRAN should also tell you the version number.
Jan
| |
| Richard Maine 2004-06-25, 7:44 pm |
| Jan Vorbrüggen <jvorbrueggen-not@mediasec.de> writes:
> ANAL/IMAGE...
Are you sure you have the right newsgroup for that topic? :-) :-)
--
Richard Maine | Good judgment comes from experience;
email: my first.last at org.domain | experience comes from bad judgment.
org: nasa, domain: gov | -- Mark Twain
| |
| Steve Lionel 2004-06-25, 7:44 pm |
| On Mon, 21 Jun 2004 16:46:18 +0100, "Rob Chambers"
<robert.chambers@yourpants.baesystems.com> wrote:
>Steve Lionel temporarily inconvenienced several billion electrons with:
>
>How do I find out directly? I'm using OpenVMS 7.1, and I was under the
>impression that the compiler was upgraded to whatever the version is that
>shipped with 7.1, though it may not have been. I've tried /assume=all and
>/assume without parameters, and both seem acceptable to the compiler, but
VMS does not ship with any compilers. (Just the MACRO assembler.) Fortran is
a separate product.
FORTRAN/VERSION should give you the identifier, though other methods suggested
would also work.
Does HELP FORTRAN /ASSUME show BYTERECL as an option? /ASSUME=ALL just
gives you all the ASSUME options the compiler knows about, some of which you
may NOT want..
I implemented this feature in VAX Fortran back in 1997.
Steve Lionel
Software Products Division
Intel Corporation
Nashua, NH
User communities for Intel Software Development Products
http://softwareforums.intel.com/
Intel Fortran Support
http://developer.intel.com/software/products/support/
| |
| Rob Chambers 2004-06-25, 7:44 pm |
| Jan Vorbrüggen temporarily inconvenienced several billion electrons
with:
> $ FORTRAN/LIST NL:
That gives me
Digital Fortran 77 V6.5-188 for OpenVMS VAX Systems
and the list of compiler options in the .LIS file looks includes
/ ASSUME=(ACCURACY_SENSITIVE,NOBYTERECL,NO
DUMMY_ALIASES,NOSOURCE_INCLUDE)
The Release Notes say:
"Use of the non-default BYTERECL value requires that the application be
running on a system which has the associated Fortran Run-Time Library
support. This support is provided by installing one of the following:
Digital Fortran 77 version V6.4 or later
OpenVMS VAX V7.0 or later
....."
so my system ought to be OK with it.
Rob
--
"The author clearly has a beef with popular society's role in censorship and
morality. Here, the krill represent an alternative to Hawaiian shirts."
| |
| Rob Chambers 2004-06-25, 7:44 pm |
| Steve Lionel temporarily inconvenienced several billion electrons with:
> Does HELP FORTRAN /ASSUME show BYTERECL as an option?
Yes, it does.
> I implemented this feature in VAX Fortran back in 1997.
You might be able to tell me if there's something wrong with the format of
my command line:
$ fortran/extend/assume=byterecl opensquare
because it gives me
%DCL-W-IVKEYW, unrecognized keyword - check validity and spelling
\BYTERECL\
Rob
--
"Democracy is two wolves and a sheep voting to decide what to have for
dinner." - Benjamin Franklin
| |
| Rob Chambers 2004-06-25, 7:44 pm |
| Thanks for those - luckily the VMS code wasn't *too* nonstandard (apart from
the use of TAB indentation throughout <grr> ) and the -fvxt VAX compatibility
switch in g77 took care of most of the rest.
F2KCLI looks *very* useful.
Rob
--
"One would like to believe that people who think of themselves as
devout Christians would also behave in a manner that is in according
with Christian ethics. But pastorally and existentially, I know that
this is not the case, and never has been." -John Neuhaus, in San Jose
Mercury News
| |
| Jan Vorbrüggen 2004-06-25, 7:44 pm |
| > You might be able to tell me if there's something wrong with the format of
> my command line:
>
> $ fortran/extend/assume=byterecl opensquare
>
> because it gives me
>
> %DCL-W-IVKEYW, unrecognized keyword - check validity and spelling
> \BYTERECL\
The command line is OK. It seems that your DCLTABLES have not been updated
properly to contain the updated list of keywords for that switch. Find the
system manager for that system, and get him to properly install the modified
command. If he doesn't know how to do that, ask again.
Jan
| |
| Mike Lay 2004-06-25, 7:44 pm |
| Rob Chambers wrote:
> Steve Lionel temporarily inconvenienced several billion electrons with:
>
>
>
> How do I find out directly? I'm using OpenVMS 7.1, and I was under the
> impression that the compiler was upgraded to whatever the version is that
> shipped with 7.1, though it may not have been. I've tried /assume=all and
> /assume without parameters, and both seem acceptable to the compiler, but
$ fortran/version
Compaq Fortran V7.4-1341-46ACJ
I've always liked the VMS habit of having qualifiers that sometimes look
like real words...
--
Mike Lay - Clinical Trial Service Unit
"I can barely speak for myself, let alone the CTSU"
w: http://www.ctsu.ox.ac.uk/
e: michael dot lay at ctsu (with an ox, an ac, and an uk on the end).
| |
| Rob Chambers 2004-06-25, 7:44 pm |
| Jan Vorbrüggen temporarily inconvenienced several billion electrons
with:
> The command line is OK. It seems that your DCLTABLES have not been
> updated properly to contain the updated list of keywords for that
> switch. Find the system manager for that system, and get him to
> properly install the modified command. If he doesn't know how to do
> that, ask again.
Thanks - I thought I was doing something obviously stupid. Now only subtly
stupid stuff remains...
Rob
--
"No one may kill a man. Not for any purpose. It cannot be condoned." -
Kirk, "Spock's Brain", stardate 5431.6
| |
| Steve Lionel 2004-06-25, 7:44 pm |
| On Tue, 22 Jun 2004 12:27:48 +0100, Mike Lay <ctsu0009@herald.ox.ac.uk> wrote:
>$ fortran/version
>Compaq Fortran V7.4-1341-46ACJ
>
>I've always liked the VMS habit of having qualifiers that sometimes look
>like real words...
You did this on an Alpha system. And that's an old compiler
Steve Lionel
Software Products Division
Intel Corporation
Nashua, NH
User communities for Intel Software Development Products
http://softwareforums.intel.com/
Intel Fortran Support
http://developer.intel.com/software/products/support/
| |
| Steve Lionel 2004-06-25, 7:44 pm |
| On Tue, 22 Jun 2004 12:56:20 +0100, "Rob Chambers"
<robert.chambers@yourpants.baesystems.com> wrote:
>Jan Vorbrüggen temporarily inconvenienced several billion electrons
>with:
>
>Thanks - I thought I was doing something obviously stupid. Now only subtly
>stupid stuff remains...
Reinstalling FORTRAN should do the trick. FORT066 is the most recent.
Steve Lionel
Software Products Division
Intel Corporation
Nashua, NH
User communities for Intel Software Development Products
http://softwareforums.intel.com/
Intel Fortran Support
http://developer.intel.com/software/products/support/
| |
| Richard Maine 2004-06-25, 7:44 pm |
| Steve Lionel <Steve.Lionel@intel.com> writes:
> FORT066 is the most recent.
Unfortunate co-incidence of version numbers. :-)
I'd think you would have supported at least f77 by now. :-)
--
Richard Maine | Good judgment comes from experience;
email: my first.last at org.domain | experience comes from bad judgment.
org: nasa, domain: gov | -- Mark Twain
| |
| Steve Lionel 2004-06-25, 7:44 pm |
| On 22 Jun 2004 08:05:28 -0700, Richard Maine <nospam@see.signature> wrote:
>Steve Lionel <Steve.Lionel@intel.com> writes:
>
>
>Unfortunate co-incidence of version numbers. :-)
>
>I'd think you would have supported at least f77 by now. :-)
Indeed! That version (Compaq Fortran 77 for OpenVMS VAX 6.6) does support
F77, but not F90 (it does have some F90 features, though.). Not to be
with Compaq Visual Fortran 6.6 which is Fortran 95. (I know you were
joking, but I thought some might be by another similarity of version
numbers.)
I was the sole maintainer for VAX Fortran from 1994 through 2001, though the
last release was in 1999, a release whose primary purpose was to change the
name from Digital to Compaq. A good compiler, ahead of its time in many ways.
Steve Lionel
Software Products Division
Intel Corporation
Nashua, NH
User communities for Intel Software Development Products
http://softwareforums.intel.com/
Intel Fortran Support
http://developer.intel.com/software/products/support/
|
|
|
|
|