Help with old VMS-Fortran 
Author Message
 Help with old VMS-Fortran

Hello,
we have to convert some old programs, running on Digital Workstation
under VMS. These programs are writen in VMS-fortran (Digitals own?)
and are perfectly undocumented.

Is there a chance to convert them into a Fortran-Version running under
Dos?

Any help is wellcome!!

Thanks
Jens



Thu, 14 Oct 1999 03:00:00 GMT  
 Help with old VMS-Fortran



Quote:
> we have to convert some old programs, running on Digital Workstation
> under VMS. These programs are writen in VMS-Fortran (Digitals own?)
> and are perfectly undocumented.

> Is there a chance to convert them into a Fortran-Version running under
> Dos?

Well, it depends on what extensions, if any, the programs use.  If
they're mostly language extensions (for example, STRUCTURE and RECORD),
then most of today's Fortran compilers support them.  If they're
OpenVMS-specific extensions, such as INDEXED files, you have a much
larger task ahead of you.

Do you still have access to the DIGITAL workstation running OpenVMS?  Is
it a VAX? If so, compile the programs using the /WARN=ULTRIX command
line switch.  This will identify OpenVMS-specific features that are
unlikely to be in DOS/Windows compilers. (The actual purpose of this
switch is to highlight extensions not supported under one of DIGITAL's
UNIX systems, but it is a good match for DOS/Windows as well.)  As an
alternative, if the workstation is an Alpha, compile with /STANDARD, but
this will warn about many more things which may or may not be
troublesome on DOS/Windows.

Do you specifically mean DOS, or are you using Windows 95?  If the
latter, there are more options available to you, including DIGITAL
Visual Fortran, which provides the best compatibility with DIGITAL's
other Fortran compilers.

--

Fortran Development               http://www.digital.com/info/slionel.html
Digital Equipment Corporation    
110 Spit Brook Road, ZKO2-3/N30
Nashua, NH 03062-2698             "Free advice is worth every cent"

For more information on DIGITAL Fortran see http://www.digital.com/fortran



Thu, 14 Oct 1999 03:00:00 GMT  
 Help with old VMS-Fortran



Quote:

> Hello,
> we have to convert some old programs, running on Digital Workstation
> under VMS. These programs are writen in VMS-Fortran (Digitals own?)
> and are perfectly undocumented.

> Is there a chance to convert them into a Fortran-Version running under
> Dos?

> Any help is wellcome!!

> Thanks
> Jens

I've just been porting some 8k lines of code from an old VMS system to a
Sun & PC.
Its taken about 2 weeks, mainly because that the VAX fortran compiler is so
sloppy!

The code ran fine on the VAX, but ported produced about 200 warnings and
120 errors!  Once these were cleared, the code still failed to run.

The problem was finally resolved, it was a programming error(not mine, I
inherited the code!) as below.

        IF ( I.EQ.NJ) THEN
                CALL EGR
                GOTO 100
        ENDIF

The VAX compiled and ran this fine, but every other complier I tryed, Sun
F77 / G77 and MS PowerStation 4. all fell over and died!

If your code is 'clean' and doesn't use any extensions it should be pretty
easy...but beware of uncovering errors in your code!

Good Luck!
Ken



Tue, 19 Oct 1999 03:00:00 GMT  
 Help with old VMS-Fortran

Quote:

>The code ran fine on the VAX, but ported produced about 200 warnings and
>120 errors!  Once these were cleared, the code still failed to run.

>The problem was finally resolved, it was a programming error(not mine, I
>inherited the code!) as below.

>    IF ( I.EQ.NJ) THEN
>            CALL EGR
>            GOTO 100
>    ENDIF

>The VAX compiled and ran this fine, but every other complier I tryed, Sun
>F77 / G77 and MS PowerStation 4. all fell over and died!

Maybe I'm just being stupid - but I don't see what's wrong with
the above segment of code.  (I'm assuming that I and NJ are integers,
that EGR is really a subroutine, and that there is an executable
or continue statement labeled 100).  Can somebody clue me in
here?

Tim.



Tue, 19 Oct 1999 03:00:00 GMT  
 Help with old VMS-Fortran



Quote:
> Its taken about 2 weeks, mainly because that the VAX fortran compiler
> is so sloppy!
> The VAX compiled and ran this fine, but every other complier I tryed,
> Sun F77 / G77 and MS PowerStation 4. all fell over and died!

That sure is a strange definition of "sloppy"!

--

Fortran Development               http://www.digital.com/info/slionel.html
Digital Equipment Corporation    
110 Spit Brook Road, ZKO2-3/N30
Nashua, NH 03062-2698             "Free advice is worth every cent"

For more information on DIGITAL Fortran see http://www.digital.com/fortran



Fri, 22 Oct 1999 03:00:00 GMT  
 Help with old VMS-Fortran

Quote:

>Hello,
>we have to convert some old programs, running on Digital Workstation
>under VMS. These programs are writen in VMS-Fortran (Digitals own?)
>and are perfectly undocumented.
>Is there a chance to convert them into a Fortran-Version running under
>Dos?
>Any help is wellcome!!
>Thanks
>Jens

If you are interested in documenting your Fortran programs before
converting them, we offer a product - FOR_STUDY - which is essentially
a Fortran static analyzer.  It has the option of generating any
missing program documentation - which may be helpful to you.

You can check our website at http://www.cobalt-blue.com/fymain for
more info, and downloadable demo.

Best wishes.

----------------------------------
Cobalt Blue, Inc.
Alpharetta, GA, USA
http://www.cobalt-blue.com
(770) 751-1149, Fax (770) 475-2892
----------------------------------



Mon, 25 Oct 1999 03:00:00 GMT  
 Help with old VMS-Fortran

Quote:



>> Hello,
>> we have to convert some old programs, running on Digital Workstation
>> under VMS. These programs are writen in VMS-Fortran (Digitals own?)
>> and are perfectly undocumented.

>> Is there a chance to convert them into a Fortran-Version running under
>> Dos?

>> Any help is wellcome!!

>> Thanks
>> Jens

>I've just been porting some 8k lines of code from an old VMS system to a
>Sun & PC.
>Its taken about 2 weeks, mainly because that the VAX fortran compiler is so
>sloppy!

I am not involved with the PC world, but some of my colleagues are
involved with porting many more k of our applications to PCs.  Their
biggest problem was work-arounds for the Powerstation Fortran bugs.
Our code was ported in a day for each application -- perhaps two for
one of our applications that fell major prey to the memory leak
problem.

Quote:
>The code ran fine on the VAX, but ported produced about 200 warnings and
>120 errors!  Once these were cleared, the code still failed to run.

If this is ANSI F77 code, I can believe many warnings if it has not
been compiled with the newer VAX compilers (e.g. unused variables are
now highlighted).  But 120 errors?  If these are Digital specific
extensions you are referring to O.K.   But if you intend to port, you
should be aware of any vendor specific extensions and remove them from
the code and get the new executable to work on the old platform.  This
problem is programmer specific and not the fault of any vendor who has
offered extensions that you take advantage of.

Will the code compile cleanly on an up-to-date VAX compiler?  Does the
code use sloppy programmer practises that were accepted on VAX, e.g.
any uninitialised variable was assumed initialised as 0.  To almost
repeat myself, the sloppiness is not that of any reputable (and note
that I did say "reputable") vendor -- or even PD compiler writer -- it
is the sloppiness of the programmer who is porting without doing his
homework.

The Digital compilers are now better able to address bad programming
practices, but they should only be warnings at worst and not errors.
I, for one, and probably Steve Lionel (and probably the compiler
writer of that system), would be very interested in Fortran code that
compiles on a VAX but gives *errors* on another compiler, unless it is
an extension exclusive to Digital.

Quote:
>The problem was finally resolved, it was a programming error(not mine, I
>inherited the code!) as below.
>    IF ( I.EQ.NJ) THEN
>            CALL EGR
>            GOTO 100
>    ENDIF
>The VAX compiled and ran this fine, but every other complier I tryed, Sun
>F77 / G77 and MS PowerStation 4. all fell over and died!

Along with Tim Shoppa, I am feeling very stupid .. what is the
compiler error that did not cause an error on a VAX compiler?

Quote:
>If your code is 'clean' and doesn't use any extensions it should be pretty
>easy...but beware of uncovering errors in your code!

You've said it.  

My current belief is that one of the best ways to test that your code
is (reasonably) portable and correct Fortran  is to run regression
testing on more than one platform.  We found many "features" when we
moved our VAX environment to the Alpha platform, and some others
(usually coding practices) when we had to provide for a PC platform.

Regards, Paddy



Tue, 26 Oct 1999 03:00:00 GMT  
 Help with old VMS-Fortran



Quote:




JUNK REMOVED....

Well here goes....
Sorry guys...I seem to have stood on a few peoples toes by accusing the VAX
compiler as being 'SLOPPY'
A couple of things.
1. The reply to the original message was meant to say that yes if you have
clean code...you shouldn't have any problems, as long as your code is VERY
clean (full ANSI)

2. I inherited the code to port.  I am a C++ / Java junky with a few years
Fortran
for good measure.  The code was give to me in a state (understatement of
the year?)
that compiled and ran...supposedly.  On compiling it all the warnings and
errors appeared....yes it was very badly coded, but the mistakes present
were due to a
lack of control, quality, and a sloppy compiler which let the 'errors'
through.

3. The main errors were DOs and IFs and GOTOs all sharing common CONTINUE
statements.

4. The code problem...
        IF ( I.EQ.NJ) THEN
                CALL EGR
                GOTO 100
        ENDIF

Is GOTOing out of a IF clause a good idea?  I think not...the problem I
'seem' to have had is that jumping out of the IF statment was leaving stuff
on the stack, and eventually bombing out.  Don't quote me on this, as I
havn't done much assembly stuff in the last 8 years.....

Anyway, to me jumping out of a IF statement is BAD.  I reworked the code
to:

        IF(blah) THEN
                CALL EGR
        ENDIF

If you have to GOTO from an IF clause, then your logic sucks!

So... I have spent the last 2 weeks cleaning up the code, removed all
GOTO's and re-writing about 20% of the code, resulting in a 27% performance
improvement.;-)

The code was dodgy to start with and it is this which made it crash and
burn.  

Ken



Fri, 29 Oct 1999 03:00:00 GMT  
 Help with old VMS-Fortran

Quote:

> Sorry guys...I seem to have stood on a few peoples toes by accusing the VAX
> compiler as being 'SLOPPY'
> A couple of things.
[...]
> 2. I inherited the code to port.  I am a C++ / Java junky with a few years
> Fortran
> for good measure.  The code was give to me in a state (understatement of
> the year?)
> that compiled and ran...supposedly.  On compiling it all the warnings and
> errors appeared....yes it was very badly coded, but the mistakes present
> were due to a
> lack of control, quality, and a sloppy compiler which let the 'errors'
> through.

        The problem is, you're blaming the compiler for the programmer's
    bad practices.   Unlike  C,  there  is  nothing  in  the  Fortran 77
    Standard  that  requires  a  "processor" (compiler)  to  generate  a
    diagnostic for non-standard conforming input code.

        Furthermore,  _most_  compilers  of   the  80's,  including  VAX
    Fortran, were _required_ to accept old and ugly Fortran source, both
    Fortran  66/Fortran  IV  style  stuff, and  a  variety  of  vendors'
    extensions (IBM, Cray, Burroughs, you  name  it).   The  requirement
    came from _customers_ who had old code that needed to compile on the
    new processor _as is_, otherwise they wouldn't buy the thing.

        Now, most quality  compilers,  including  VAX  Fortran  (and its
    successors,  DEC  Fortran  and Digital Fortran  :-),  have  compiler
    switches that turn on all sorts  of  checking.   To  say  that  code
    compiled  under  VAX Fortran says next to nothing about it being F77
    compliant _unless_ these  standards  checking qualifier(s) was(were)
    used.   My point is that the compiler is far from sloppy.  It is the
    programmer who wrote the code  and  used  the  compiler  who  is/was
    sloppy.

Quote:
> 3. The main errors were DOs and IFs and GOTOs all sharing common CONTINUE
> statements.

        GOTOs don't share a CONTINUE, the "go  to" a label, which may be
    a   CONTINUE.   The  practice  of  several  DOs  sharing  a   common
    terminating statement, while ugly, does  not,  to  the  best  of  my
    knowledge,  violate  the  F77 standard.  IFs don't get involved with
    CONTINUEs or labels, so I don't know what you're talking about.

        However, the style of having several DOs, for example, terminate
    on the same labeled statement is  a hold-over from Fortran 66, IMHO,
    and should be eliminated.

Quote:
> 4. The code problem...
>    IF ( I.EQ.NJ) THEN
>            CALL EGR
>            GOTO 100
>    ENDIF

> Is GOTOing out of a IF clause a good idea?

        Yes, if the algorithm warrants it.

Quote:
>                                             I think not...the problem I
> 'seem' to have had is that jumping out of the IF statment was leaving stuff
> on the stack, and eventually bombing out.  Don't quote me on this, as I
> havn't done much assembly stuff in the last 8 years.....

        The Fortran standard  knows  nothing  about  stacks  or assembly
    language.   If your compiler generates bad code when you jump out of
    an IF-block, you've got a lousy compiler, get a new one.

        Jumping _into_ a DO-loop  of  IF-block  is an entirely different
    matter  and  is disallowed by the F77 standard (although allowed  by
    Fortran  66?).   But  jumping  out  of  a  DO-loop  or  IF-block  is
    completely supported, and a common programming practice.

Quote:
> Anyway, to me jumping out of a IF statement is BAD.  I reworked the code
> to:

>    IF(blah) THEN
>            CALL EGR
>    ENDIF

        Now you've changed the logic.   What  do you do, repeat the test
    on `blah' and GOTO 100 if true?  Geez...

Quote:
> If you have to GOTO from an IF clause, then your logic sucks!

        Such a blanket statement  without  supporting evidence speaks of
    either  (a) a religious adherence to a particular programming  style
    without moderation that accounts for special  cases  encountered  in
    the "real world", or (b) inexperience.

Quote:
> So... I have spent the last 2 weeks cleaning up the code, removed all
> GOTO's and re-writing about 20% of the code, resulting in a 27% performance
> improvement.;-)

        That's very good.  Many times, programs written to old standards
    that  didn't  support  modern  control  structures  can  be  greatly
    improved  using the new (and standard) structures.  These structures
    not  only  make  the   program   more   readable   and,   therefore,
    maintainable,  but  they  give  the  compiler more information which
    allows them to do better optimizations.  It's also quite common that
    in recasting an  old  algorithm  such  that  it  has  a good, modern
    structure leads to a more efficient algorithm.

Quote:
> The code was dodgy to start with and it is this which made it crash and
> burn.  

        Exactly, although  I'd  tend  to  phrase  it  as,  "non-standard
    conforming  code or code that makes assumptions about the underlying
    hardware tends not to be portable".

        -Ken
--

 SLAC, P.O.Box 4349, MS 46  |  DECnet:   45537::FAIRFIELD (45537=SLACVX)
 Stanford, CA   94309       |  Voice:    415-926-2924    FAX: 415-926-3515
 -------------------------------------------------------------------------
 These opinions are mine, not SLAC's, Stanford's, nor the DOE's...



Fri, 29 Oct 1999 03:00:00 GMT  
 Help with old VMS-Fortran

Quote:

>4. The code problem...
>    IF ( I.EQ.NJ) THEN
>            CALL EGR
>            GOTO 100
>    ENDIF

>Is GOTOing out of a IF clause a good idea?  I think not...

What's wrong with it?  Fortran programmers have been doing it for
decades, and every compiler I know of deals with it quite nicely.

Quote:
>the problem I
>'seem' to have had is that jumping out of the IF statment was leaving stuff
>on the stack, and eventually bombing out.  Don't quote me on this, as I
>havn't done much assembly stuff in the last 8 years.....

I don't think that was your problem.  I know of no Fortran compiler
that would do anything like you are suggesting.

Quote:
>Anyway, to me jumping out of a IF statement is BAD.  I reworked the code
>to:

>    IF(blah) THEN
>            CALL EGR
>    ENDIF

>If you have to GOTO from an IF clause, then your logic sucks!

No, we just think differently than you.  If you're wearing
the straight-jacket of avoiding GOTO's at all cost, you're going
to not see the elegance and advantages they have to offer in
implementing common algorithms.  There are lots of
program control structures out there in the real world, and
sometimes a GOTO in an IF clause is the best way to do the coding.




Fri, 29 Oct 1999 03:00:00 GMT  
 Help with old VMS-Fortran

[[[   ...   snip   ...   ]]]

Quote:

>         Jumping _into_ a DO-loop  of  IF-block  is an entirely different
>     matter  and  is disallowed by the F77 standard (although allowed  by
>     Fortran  66?).

[[[   ...   snip   ...   ]]]

Jumping into a Fortran '66 Do Loop was not allowed.  However, jumping
back (is this hair splitting?)  into a Do Loop from an "Extended Range",
was allowed.  E.g:
        Do 20 I = 1, n
          ...
          go to 399
  10      Continue
          ...
  20    Continue
          ...
 399      ...
          go to 10

The Block If statement did not exist in Fortran '66.
--

  [ To reply, change "$$ibud..." to "ibud...".  This is an Anti-Spam
measure]  
.Scientific Conversions (SciCon
..Consultant for PC applications & CPI Spanish School in Costa Rica
...As Dizzy Dean said, "It ain't braggin' if ya kin do it."



Fri, 29 Oct 1999 03:00:00 GMT  
 Help with old VMS-Fortran



Quote:

> >4. The code problem...
> >       IF ( I.EQ.NJ) THEN
> >               CALL EGR
> >               GOTO 100
> >       ENDIF

> >Is GOTOing out of a IF clause a good idea?  I think not...

> What's wrong with it?  Fortran programmers have been doing it for
> decades, and every compiler I know of deals with it quite nicely.

> >the problem I
> >'seem' to have had is that jumping out of the IF statment was leaving
stuff
> >on the stack, and eventually bombing out.  Don't quote me on this, as I
> >havn't done much assembly stuff in the last 8 years.....

> I don't think that was your problem.  I know of no Fortran compiler
> that would do anything like you are suggesting.

> >Anyway, to me jumping out of a IF statement is BAD.  I reworked the code
> >to:

> >       IF(blah) THEN
> >               CALL EGR
> >       ENDIF

> >If you have to GOTO from an IF clause, then your logic sucks!

> No, we just think differently than you.  If you're wearing
> the straight-jacket of avoiding GOTO's at all cost, you're going
> to not see the elegance and advantages they have to offer in
> implementing common algorithms.  There are lots of
> program control structures out there in the real world, and
> sometimes a GOTO in an IF clause is the best way to do the coding.



ELEGANCE and GOTO's HA!
The language may allow it, due to its support of old code, but GOTO's are
bad.
There is no need for gotos.  All that is required is a bit of effort to
produce a
good clean bit of code.
I have been coding for 15 yrs, and NEVER used a goto.  Java now doesn't
support
them!

Ken



Sat, 30 Oct 1999 03:00:00 GMT  
 Help with old VMS-Fortran



Quote:

writes:

> > Anyway, to me jumping out of a IF statement is BAD.  I reworked the
code
> > to:

> >       IF(blah) THEN
> >               CALL EGR
> >       ENDIF

>         Now you've changed the logic.   What  do you do, repeat the test
>     on `blah' and GOTO 100 if true?  Geez...

Oh sorry....I am comparing a previous bit of code to the changes....the
fact that I didn't explicitly define the logic comparison that takes place
is irrelivant...stop moaning.
For those who cannot grasp this ...here is the REWORKED code with the
logic.

        IF ( I.EQ.NJ) THEN
                CALL EGR
        ENDIF

Quote:
> > If you have to GOTO from an IF clause, then your logic sucks!

>         Such a blanket statement  without  supporting evidence speaks of
>     either  (a) a religious adherence to a particular programming  style
>     without moderation that accounts for special  cases  encountered  in
>     the "real world", or (b) inexperience.

Supporting evidence:
In 15 yrs of programming I have never used a goto. They are just plain bad!
The only reason why FORTRAN retains them is for compatibility with existing
code.
Take a look at languages such as JAVA, can you see any GOTO's?
NO! YOU DON'T...  
If you read up about the development of Java, they checked millions (this
is an exageration before someone replys to say that it was only 200,000) of
code looking for GOTO's to see
if they were really required, they found 6 occurences.
4 were errors, the programmer just forgot about them.
2 were in use, but were quickly removed with a little effort.

You can live without gotos...and its a far nicer place!

(a) I live in the 'real world', and I have yet to fine a good reason to use
a GOTO.
(b) Hmmm...Over my last 5 projects in the last 3 years I have on average
reduced code size by 15% ( number of lines ) and improved performance by
about 50%. Whats your performance like?

Ken.



Sat, 30 Oct 1999 03:00:00 GMT  
 Help with old VMS-Fortran

Quote:




>writes:

>[...]

>> > If you have to GOTO from an IF clause, then your logic sucks!

>>         Such a blanket statement  without  supporting evidence speaks of
>>     either  (a) a religious adherence to a particular programming  style
>>     without moderation that accounts for special  cases  encountered  in
>>     the "real world", or (b) inexperience.

>Supporting evidence:
>In 15 yrs of programming I have never used a goto. They are just plain bad!
>The only reason why FORTRAN retains them is for compatibility with existing
>code.
>Take a look at languages such as JAVA, can you see any GOTO's?
>NO! YOU DON'T...  
>If you read up about the development of Java, they checked millions (this
>is an exageration before someone replys to say that it was only 200,000) of
>code looking for GOTO's to see
>if they were really required, they found 6 occurences.
>4 were errors, the programmer just forgot about them.
>2 were in use, but were quickly removed with a little effort.

>You can live without gotos...and its a far nicer place!

>(a) I live in the 'real world', and I have yet to fine a good reason to use
>a GOTO.
>(b) Hmmm...Over my last 5 projects in the last 3 years I have on average
>reduced code size by 15% ( number of lines ) and improved performance by
>about 50%. Whats your performance like?

Sorry, but I can't resist:
In 45 yrs of leaving I have never used a million $. They are just plain bad!
The only reason why rich people retain them is for compatibility with existing
life.
Take a look at places such as Java Island, can you see any millions $ ?
NO! YOU DON'T...  
If you read up about the development of Java, they checked millions (this
is an exageration before someone replys to say that it was only 200,000) of
people looking for those with millions $ to see if they were really required,
they found 6 occurences.
4 were errors, the owner just forgot about them.
2 were in use, but were quickly removed with a little effort.

You can live without millions $ ...and it's a far nicer place!

(a) I live in the 'real world', and I have yet to find a good reason to use
a million $.
(b) Hmmm...Over my last 5 projects in the last 3 years I have on average
reduced my wallet size by 15% ( number of banknotes ) and improved productivity by
about 50%. What's your performance like?

For the record, I use about 10 GOTOs per program, all in IF blocks of
the form:
  IF (Error_condition) THEN
     CALL ERR_MSG (Error_condition)
     GO TO 9000
  ENDIF

Label 9000 corresponds to the ``clean-up and die gently'' section of the
program.

For the record also, I never, up to now, gained less than 50% on the programs
that I examined for performance. Some of them were large CFD Fortran codes.
Most of time, reduction was by a ratio of 3 to 5.

I use to indent IFs and DOs by 3 blanks, and I wonder: How wide
is your screen ?
I also wonder what your opinion is about:

  if (End_condition) break;

GOTOs are not so harmful as brainless programmers.
If you feel like chasing something, aim your gun at them first.

Michel

--

| IFREMER: Institut Francais de Recherches pour l'Exploitation de la Mer|
| Centre de Brest - B.P. 70                      phone : +33-2-9822 4144|
| F-29280 PLOUZANE - FRANCE                      fax   : +33-2-9822 4135|
| http://www.ifremer.fr/ditigo/molagnon/molagnon.html                   |



Sat, 30 Oct 1999 03:00:00 GMT  
 Help with old VMS-Fortran

Quote:

> ELEGANCE and GOTO's HA!
> The language may allow it, due to its support of old code, but GOTO's are
> bad.
> There is no need for gotos.  All that is required is a bit of effort to
> produce a
> good clean bit of code.
> I have been coding for 15 yrs, and NEVER used a goto.  Java now doesn't
> support
> them!

If, in order to avoid a goto, you have to insert an additional level of
control structure and an additional variable, then the improvement in
code elegance is questionable.  If you have to do that, or similar,
multiple times in a short piece of code then the code with the gotos
may well be more elegant in many people's eyes.

I will agree that elegantly-written code tends to minimize the use of
gotos, but I can hardly agree that goto is incompatible with elegance.
If a code with the gotos is easier to follow than an equivalent code
without, then I can't personally attribute greater elegance to the
goto-free version.

Remember, too, that the standards committee has decided that two
particular uses of goto (at least) are sufficiently useful to deserve
their own statements: cycle and exit.  No matter how you slice it,
those two are unconditional branches, exactly equivalent to appropriate
goto statements.  Disguising a goto as a cycle or exit statement often
improves code readability, but sometimes a cycle statement 100 lines
above the corresponding end do might be better written as a goto.

John Bollinger



Sat, 30 Oct 1999 03:00:00 GMT  
 
 [ 18 post ]  Go to page: [1] [2]

 Relevant Pages 

1. Help needed on old VMS Fortran 77 Program

2. Need help linking Ada code to Fortran on VAX/VMS

3. VMS fortran Newbie requires HELP!

4. Help converting VMS Fortran to C

5. NEED HELP IN VAX/VMS FORTRAN SCREEN INTERFACE

6. help: VMS fortran77 to DOS-fortran

7. VMS Fortran conversion - HELP

8. Help on locating a Lahey/VMS fortran specific book

9. Help Wanted: How to run Fortran on VMS?

10. Semi-OT: help ID old Fortran 77 text book

11. Need help udating OLD fortran programs

12. Old Fortran. Please Help

 

 
Powered by phpBB® Forum Software