Fortran - Anyone for help with DEC (Vax) Fortran-IV ?

Author

Anyone for help with DEC (Vax) Fortran-IV ?

transnet@vrx.net

2006-03-17, 6:58 pm

I have old DEC Vax (11/780) code cirac 1982-1986
written in Fortran/IV with no system calls,

I'd like to get it converted, if at all possible.

the email blackholes, so dont bother.

thanks!

Jim

2006-03-17, 6:58 pm

<transnet@vrx.net> wrote in message
news:1142630345.954234.247960@z34g2000cwc.googlegroups.com...
>I have old DEC Vax (11/780) code cirac 1982-1986
> written in Fortran/IV with no system calls,
>
> I'd like to get it converted, if at all possible.
>
> the email blackholes, so dont bother.
>
> thanks!
>
VMS Fortran was always F77. It should need no conversion unless you intend
to remove the VMS extensions.
Jim

Steve Lionel

2006-03-17, 6:58 pm

transnet@vrx.net wrote:
> I have old DEC Vax (11/780) code cirac 1982-1986
> written in Fortran/IV with no system calls,
>
> I'd like to get it converted, if at all possible.

Converted to what? If it's from the timeframe you mentioned it's more
likely to be closer to Fortran 77 than Fortran IV, though it really
doesn't matter. Most current compilers can handle it. If there are
truly no VMS system calls (no calls to routines with $ in their names),
it is more likely than not that a simple recompile will do the trick.

What compiler do you want to use?

Dan Nagle

2006-03-17, 6:58 pm

Hello,

Jim wrote:
> <transnet@vrx.net> wrote in message
> news:1142630345.954234.247960@z34g2000cwc.googlegroups.com...
> VMS Fortran was always F77. It should need no conversion unless you intend
> to remove the VMS extensions.

But there were a lot of extensions.

For example, the logical <-> integer equivalence.
If it's a real VAX code, are even's true and odd's false,
or the other way around?

--
Cheers!

Dan Nagle
Purple Sage Computing Solutions, Inc.

Richard E Maine

2006-03-17, 6:59 pm

<transnet@vrx.net> wrote:

> I have old DEC Vax (11/780) code cirac 1982-1986
> written in Fortran/IV with no system calls,
>
> I'd like to get it converted, if at all possible.

Started looking at the downloaded copy (from private email) in between
other things. I'm pretty much out of time until Tuesday now. Looks like
most of the problems have been introduced by attempts to edit the code.
These aren't isssues of converting from one compiler to another. Well, a
few things are, but those seem in the minority. Lots of typos and things
that could never have compiled on anything. What I ran into so far was

1. misspelled equivalence
2. Comma omitted between items in DATA statement
3. Multiple cases of 1X mistyped/scanned? as IX in formats.
4. Multiple cases of fixed-source lines longer than 72 cols
(complete with character-context continuations).
5. Some missing and extra quotes. Must have been half-done
non-working edits. This could never have compiled on anything.
6. Formats missing their labels.
7. Input formats edit descriptors of just F, with no field widths.
I tried substituting list-directed. Looks like someone before me
had the same idea, because one of the invalid formats was
unreferenced,
but the read statement right before it used list-directed.
8. Duplicate label 6660. Looks like the 2nd one "wanted" to be 6680.
9. A spurious dot in a format. Typo?
10. A 14 in a format that I suspect should be I4.
11. A typo that says ISUV(IT)=1, there being no ISUV.
I'm guessing from context this should be ISURR(IT)=1.
12. An apparent typo of a close parens for a comma.
13. A typo of TTAKA for ITAKA
14. A type of G0TO instead of GOTO
15. Multiple typos of .EG. for .EQ.

I did something about all the above.

And about then I noticed multiple cases of GOTO referencing statement
labels that don't exist and don't have any obvious close typos or other
clues as to what might be intended. That's going to take some actual
figuring out what the code in question is trying to do.

Is there any chance that something closer to the original "unfixed"
version is around somewhere. I'm not sure I can undo the damage done to
this, but the original can't possibly have some of these problems.

--
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

transnet@vrx.net

2006-03-17, 6:59 pm

I've tried f2c, the gnu fortran f77 compiler, the old microsoft fortran
77
the vms (openvms v6) fortran compiler (which is f77)
and I've tried compaq's open fortran or whatever compiler,
then HP's version,
and Intels fortran compiler too

the latest and greatest, the oldest I can find, and everything in
between.
nothing will touch the code.

many keywords are not understood.
the EQUIVELENCE keyword for one.
the RANDOM function is completely incompatible
and even the COMMON variables aren't handled properly.

it's a mess. even some functions dont get handled right either.

an old vaxstation (v5.6 openvms) also wont handle it - its f77 too.

so it definitely seems like F/IV more than anything.

some of the code needs cleaning up yes, but 20 years of work I think
it's pretty close.
NO system ($) calls. the ONLY specific vax thing in it is the file
access in one routine.
(and terminal access of course) - but that's handled through files not
system calls.

the code is at - http://trek7.sourceforge.net

thanks

Richard E Maine

2006-03-17, 6:59 pm

<transnet@vrx.net> wrote:

> many keywords are not understood.
> the EQUIVELENCE keyword for one.

See my post of a few minutes ago. That's not the correct spelling of
equivalence. Yes, it matters. And the misspelling was in the code - not
just the posting here.

> so it definitely seems like F/IV more than anything.
> some of the code needs cleaning up yes, but 20 years of work I think
> it's pretty close.

Then did you point me at the wrong code? Things like GOTO 331, when
there isn't a 331 isn't close, and it isn't an issue of compatibility
between versions. That's just code that has gotten mangled somewhere
along the line.

> the code is at - http://trek7.sourceforge.net

I started out with treka.for in the directory "newest" there. The other
directory was empty.

--
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

transnet@vrx.net

2006-03-17, 6:59 pm

There exists no other copy of this code on any medium (except an old
magtape perhaps).
but the best I can do is a paper print out.

I have several different versions of the code (some with the system
calls added on).
this was an add-on feature I added later in the life-cycle.
yes I coded those.

so for the most part, I have to rely on paper copies.
and the old DEC line printers don't make things easy!!

even by EYE, its hard to tell a zero from an "oh", or an "L" or a one
or an "i" (capital)
like "l" or "1" or "I" are almost identical by eye. its scary.

if I had approximate locations ("all positioning is relative and not
absolute) I could probably get which ones you're referring to and
correct it or supply it.

I don't know if an high-resolution scan (jpg) of the pages might help
or not.
that might be my next attempt.

one problem with compilers as you mention, continuation lines, nothing
seemed to handle those, even if they were correct in every detail
(matching quotes, etc). lines longer than 72 characters.

the old vax 11/780 definitely ran this code (vms 5.1 I believe or maybe
up to 5.5) its been a LOONG time...

and another compiler issue, the original code was broken into modules
as you see it. so from module A to B to C to D, etc, there are
duplicate GOTO statements, etc. I mean theres a 100 in A, and another
100 in B. so most modern compilers I tried didn't like that. they
wouldnt compile it as seperate modules, and putting them together
caused all sorts of hassles.

anyhow I'll work on scanning in the pages as JPG or something, that
might help. maybe.

Dan.

William Asher

2006-03-17, 6:59 pm

Richard E Maine wrote:

> <transnet@vrx.net> wrote:
>
>
> Started looking at the downloaded copy (from private email) in between
> other things. I'm pretty much out of time until Tuesday now. Looks like
> most of the problems have been introduced by attempts to edit the code.
> These aren't isssues of converting from one compiler to another. Well, a
> few things are, but those seem in the minority. Lots of typos and things
> that could never have compiled on anything. What I ran into so far was
>
> 1. misspelled equivalence
> 2. Comma omitted between items in DATA statement
> 3. Multiple cases of 1X mistyped/scanned? as IX in formats.
> 4. Multiple cases of fixed-source lines longer than 72 cols
> (complete with character-context continuations).
> 5. Some missing and extra quotes. Must have been half-done
> non-working edits. This could never have compiled on anything.
> 6. Formats missing their labels.
> 7. Input formats edit descriptors of just F, with no field widths.
> I tried substituting list-directed. Looks like someone before me
> had the same idea, because one of the invalid formats was
> unreferenced,
> but the read statement right before it used list-directed.
> 8. Duplicate label 6660. Looks like the 2nd one "wanted" to be 6680.
> 9. A spurious dot in a format. Typo?
> 10. A 14 in a format that I suspect should be I4.
> 11. A typo that says ISUV(IT)=1, there being no ISUV.
> I'm guessing from context this should be ISURR(IT)=1.
> 12. An apparent typo of a close parens for a comma.
> 13. A typo of TTAKA for ITAKA
> 14. A type of G0TO instead of GOTO
> 15. Multiple typos of .EG. for .EQ.
>
> I did something about all the above.
>
> And about then I noticed multiple cases of GOTO referencing statement
> labels that don't exist and don't have any obvious close typos or other
> clues as to what might be intended. That's going to take some actual
> figuring out what the code in question is trying to do.
>
> Is there any chance that something closer to the original "unfixed"
> version is around somewhere. I'm not sure I can undo the damage done to
> this, but the original can't possibly have some of these problems.
>

I would suspect that the "code" is the result of someone scanning a
hardcopy of a dot-matrix printout and putting that through an OCR. The
"typos" look suspiciously familiar to ones I had to deal with when I did
the same thing a while back.

--
Bill Asher

transnet@vrx.net

2006-03-17, 6:59 pm

Yep, that's about the only way of getting the code in.
however! some modules were hand typed in entirety.
like module E for example.

a lot of touch up work was done. going over the code many times.
you think you got everything and then... well, you don't.

ugh.

Would jpegs help or is it really gonna take retyping everything by
hand?

Dan.

William Asher

2006-03-17, 6:59 pm

wrote:

> Yep, that's about the only way of getting the code in.
> however! some modules were hand typed in entirety.
> like module E for example.
>
> a lot of touch up work was done. going over the code many times.
> you think you got everything and then... well, you don't.
>
> ugh.
>
> Would jpegs help or is it really gonna take retyping everything by
> hand?
>
> Dan.
>

Hmmmm, you're trying to compile Trek7 right? I am embarrassed to admit
this but I have a copy of this. I never played with it before but I just
discovered mine compiles on DVF 6.6d with only a few warnings. It also
links without errors but doesn't run.

If you want my version of the source code, send me an e-mail and I will
send you the zip I have of the source, data files, etc.

--
Bill Asher

William Asher

2006-03-17, 6:59 pm

William Asher wrote:

> wrote:
>
>
> Hmmmm, you're trying to compile Trek7 right? I am embarrassed to
> admit this but I have a copy of this. I never played with it before
> but I just discovered mine compiles on DVF 6.6d with only a few
> warnings. It also links without errors but doesn't run.
>
> If you want my version of the source code, send me an e-mail and I
> will send you the zip I have of the source, data files, etc.
>

Ok, I take that back, my version even runs once I put the data files where
they need to be. It doesn't seem to run right, but it does run.

--
Bill Asher

Brooks Moses

2006-03-17, 6:59 pm

transnet@vrx.net wrote:
> Yep, that's about the only way of getting the code in.
> however! some modules were hand typed in entirety.
> like module E for example.
>
> a lot of touch up work was done. going over the code many times.
> you think you got everything and then... well, you don't.
>
> ugh.
>
> Would jpegs help or is it really gonna take retyping everything by
> hand?

Honestly, how I'd do this is by retyping things by hand as if I were
rewriting it, probably with cutting and pasting small pieces from the
existing code as I understood them and confirmed that they were correct,
and with comments along the way to document the thought process.

I think the scanned images (300 or 600dpi is good) would help, if only
for archival purposes. (They'll probably be useful for the retyping,
too.) The finished edited code is almost certainly going to have too
much editing and "cleanup" done to it to be a true copy of the original.

Out of curiousity, how much shared lineage does this have with the BASIC
Star Trek game in Ahl's _Basic Computer Games_?

- Brooks

--
The "bmoses-nospam" address is valid; no unmunging needed.

Brooks Moses

2006-03-17, 9:56 pm

transnet@vrx.net wrote:
> some of the code needs cleaning up yes, but 20 years of work I think
> it's pretty close.
> NO system ($) calls. the ONLY specific vax thing in it is the file
> access in one routine.
> (and terminal access of course) - but that's handled through files not
> system calls.
>
> the code is at - http://trek7.sourceforge.net

I would like to report one non-Fortran bug in the code. The TREKA.FOR
header has the following comments:

> C RELEASED UNDER GPL BY DAN GAHLINGER AUG. 20/2003 *
> C ALL MODIFICATIONS TO CODE MUST BE APPROVED BY EITHER OF THE ABOVE *
> C ALL PATCHES/ETC MUST BE APPROVED AND RELEASED VIA OFFICIAL CHANNELS *

These are inconsistent with each other. If the code has been released
under the GPL, then the authors have thereby waived the rights to
require that only their "official channels" be used to release the code
or to approve patches. The GPL says that I can take the code, modify it
as I wish, and distribute it as I wish, so long as I comply with the
terms of the GPL, without needing to ask for any explicit permission or
approval. That's sort of the whole point of the license.

- Brooks

--
The "bmoses-nospam" address is valid; no unmunging needed.

transnet@vrx.net

2006-03-17, 9:56 pm

Not true actually.

The linux kernel. I'm sure you've heard of it.
It is licensed under GPL.

however, all patches, changes, etc must be approved by the kernel
maintainers, and ultimately by Linus Torvalds.

Sure, you can roll your own kernel, via the GPL and do what you want,
but no one is going to accept "YOUR" kernel as the linux kernel.

Same thing here. I am the code maintainer, I approve patches and
things.

Same for ANY sourceforge project, actually.
Go ahead, pick a sourceforge package, modify it, submit your
modifications to the project.
they don't HAVE to accept your modifications. they can go blissfully
along without you if they wish.

that's not the point though.

I understand the code, and the "spirit" of what it tries to do, and
capture. I'd like to say that maintained, not turned into a horrible
car-wreck like "netrek" or something (shudder).

Though I feel, once this code is working as intentioned, I have no
problems setting it free completely really. That is once the original
code set runs on something modern (with mods, converted, translated,
whatever) then I really have no issues, even if someone takes it and
makes a million dollars off it, I really don't care. that's not the
point.

the point is that things like this deserve to be preserved. Well,
that's my feeling anyhow.
I always liked text-adventures more than other stuff. Maybe I'm just a
few generations too old.

Dan.

Richard Maine

2006-03-17, 9:56 pm

(From home at the moment)

<transnet@vrx.net> wrote:

> so for the most part, I have to rely on paper copies.
> and the old DEC line printers don't make things easy!!
>
> even by EYE, its hard to tell a zero from an "oh", or an "L" or a one
> or an "i" (capital)
> like "l" or "1" or "I" are almost identical by eye. its scary.

Yes. There are signs of things like that. Fortunately, those are mostly
relatively simple to fix, as long as the error isn't accidentally
something valid, but unintended.

> I don't know if an high-resolution scan (jpg) of the pages might help
> or not.

Yes. Most of the stufff is pretty mundane. Just needs some time to
plough though it because there are a lot of cases. Takes a little time,
but not hard. It is the GOTO missing statement numbers that leave me
having no idea what to do to fix it. A high-res jpg of the paper copy
could plausibly help rectify that. I wouldn't want to type the whole
thing in from such a scan, but it could help identifying missing things
like that.

> one problem with compilers as you mention, continuation lines, nothing
> seemed to handle those, even if they were correct in every detail
> (matching quotes, etc). lines longer than 72 characters.

That's because that is nonstandard. And even some common extensions
would be a little tricky because of the character context thing. Looks
to me like this assumed exactly 75 cols per line (if I counted right),
no more and no less. The number is supposed to be 72. But that's a
relatively simple thing to fix. Those I can do.

> and another compiler issue, the original code was broken into modules
> as you see it. so from module A to B to C to D, etc, there are
> duplicate GOTO statements, etc. I mean theres a 100 in A, and another
> 100 in B. so most modern compilers I tried didn't like that. they
> wouldnt compile it as seperate modules, and putting them together
> caused all sorts of hassles.

I suspect you misidentified something here. There is absolutely *NO*
problem with having the same statement number in separate subroutines.
That is perfectly standard, has been forever, is done all the time, and
I do not believe that you could find *ANY* compiler that would refuse to
compile it, much less "most modern compilers". Either

1. You are incorrectly describing it. Some possibilities come to mind.

or

2. Some other error messed things up enough so that the separate
subroutines weren't recognized as separate subroutines. DUplicates of
the same statement number on the same subroutine is a problem, but not
in separate subroutines.

And yes, trying to merge subroutines together would make things worse -
not better. That would just add problems without solving any. Don't do
that.

--
Richard Maine | Good judgement comes from experience;
email: last name at domain . net | experience comes from bad judgement.
domain: summertriangle | -- Mark Twain

Richard Maine

2006-03-17, 9:56 pm

William Asher <gcnp58@yahoo.com> wrote:

>
> my version even runs once I put the data files where
> they need to be. It doesn't seem to run right, but it does run.

I didn't read this before posting a few minutes ago about how a jpeg
might help me with parts. Sounds to me like starting from William's copy
might be a better way to go, saving a bit of work. The jpeg might still
be useful for some cross-checking.

--
Richard Maine | Good judgement comes from experience;
email: last name at domain . net | experience comes from bad judgement.
domain: summertriangle | -- Mark Twain

transnet@vrx.net

2006-03-17, 9:56 pm

Could you please email me the copy you have?
I'd really appreciate it.

my e-m is bitslayer ATT gmail - yknow ;)

Dan.

transnet@vrx.net

2006-03-17, 9:56 pm

There is a version on punch-cards in a box someplace ;)
hehe :)

I've emailed Bill, and posted here for him, so hopefully his is fairly
recent code.
I did things like add more players and things like that in the end. Not
too hard to do though.

Dan.

Brooks Moses

2006-03-17, 9:56 pm

transnet@vrx.net wrote:
> Not true actually.

I think you may have slightly misunderstood my comment, then.

> The linux kernel. I'm sure you've heard of it.
> It is licensed under GPL.
>
> however, all patches, changes, etc must be approved by the kernel
> maintainers, and ultimately by Linus Torvalds.

All patches, changes, etc. _that get rolled back into the official
version that Linus distributes_ must be approved by him. Which is
rather self-obvious, as he's the one distributing the version that he
distributes.

That doesn't place any restriction on my making patches and changes of
my own, however.

> Sure, you can roll your own kernel, via the GPL and do what you want,
> but no one is going to accept "YOUR" kernel as the linux kernel.
>
> Same thing here. I am the code maintainer, I approve patches and
> things.

Can I roll my own version of Trek7, then, and do what I want with it, in
the same way? The two sentences that I was objecting to appeared, to
me, to be a wording that would prohibit me from doing so. That's what I
was complaining about, is all.

I have no objection whatsoever to you only putting things in your
version that you approve of. It seems quite obvious to me that you'd do
that.

(I also have no objection to the idea that you should be able to call
your version the "official" version, and that other people's versions
should not. That's also in the GPL already, though it seems to get
ignored; if I release a modified version, the GPL requires that I make
it clear what modifications were made.)

> I understand the code, and the "spirit" of what it tries to do, and
> capture. I'd like to say that maintained, not turned into a horrible
> car-wreck like "netrek" or something (shudder).

I appreciate that, definitely.

I'm just picky about license wording, is all. :)

- Brooks

--
The "bmoses-nospam" address is valid; no unmunging needed.

transnet@vrx.net

2006-03-17, 9:56 pm

I did a lot of modifications and updates to the code back on the vax up
until the final days.
It's weird that Bill got a copy of it from somewhere. But hey, it
happens.

copies of my other game "Castle" are out on the net someplace too, I've
passed it out time and again, but always in binary. never source.

I put over 4 man years solid into getting Castle working right, and it
finally does. even found another bug two years ago and finally squashed
it.

as I mentioned I really dont mind people doing what they want with
Trek7, but I would like to see the code that is there working first. I
don't think its a huge thing to ask.

And to me, seeing pieces of a broken program floating around doesnt
make much sense as part of other projects.

Call it personal attachment or whatever you want. But that'd be my
preference.
However, if you do have a specific use for it, please email me off-list
and I'll consider it.

I'm not an ogre, or even a grue - heh ;)

Once the code we have is working (reasonably stable) I dont have a
problem with that code being used elsewhere. At least then I have the
peace of mind know that it is somewhat reliable.

I guess after 24 years its hard to let go of our kids... :)

Dan.

William Asher

2006-03-18, 3:56 am

transnet@vrx.net wrote in news:1142646613.657695.83740
@e56g2000cwe.googlegroups.com:

> Could you please email me the copy you have?
> I'd really appreciate it.
>
> my e-m is bitslayer ATT gmail - yknow ;)
>
> Dan.
>

Done.

Let me know if you don't receive it or it got corrupted in transmission
somehow.

--
Bill Asher

transnet@vrx.net

2006-03-18, 3:56 am

Too bad no source code with that.
Hopefully you can send the data files too.

it looks like a pc-hybrid version I made a number of years ago.
I had some of this on sourceforge, and theres an old thread out on the
net someplace, likely that has this all still.

I had a pc version, a hybrid, a linux version, and the vms versions.
ugh. I should have used CVS :)

So anyone who wants the version bill has, its binary only (it seems). I
can send it.
or I may post it to sourceforge (though doesnt quite fit the name).

I will be doing scans of the paper printouts in the meantime.

Joy. (not)

Dan.
William Asher wrote:
> transnet@vrx.net wrote in news:1142646613.657695.83740
> @e56g2000cwe.googlegroups.com:
>
>
> Done.
>
> Let me know if you don't receive it or it got corrupted in transmission
> somehow.
>
> --
> Bill Asher

William Asher

2006-03-18, 3:56 am

transnet@vrx.net wrote in
news:1142662158.134018.169000@v46g2000cwv.googlegroups.com:

> Too bad no source code with that.
> Hopefully you can send the data files too.
>

Hi Dan:

No, there is source code, I just got mixed up and sent the wrong
archive. Hopefully I have corrected that and you now have the source,
data files, as well as the .exe

Here's the header from the .main.

C TREK7 MODULE A *
C -- CONVERTED TO PC BY: DAN GAHLINGER -- *
C ENTIRE MODULE TYPE-EXACT CHECK 04/26/2000 BY: D.G. *

--
Bill Asher

transnet@vrx.net

2006-03-18, 3:56 am

ooh, that looks like one of my "lost" code archives.
wonders never cease.

thanks Bill!

So I will be posting this to sourceforge (hopefully) and anyone who
wants it, ask me or Bill (if he's willing) but I'll make it available.

This is DEFINITELY newer and better code than whats on sourceforge now.
It's a lot cleaner!

What I can remember the ONLY real major issues with this code is:
RANDO (random number generator)
and
HORTA routine

they get locked in an infinite loop for some reason, and never break
out.
course I'm recalling this from memory ;)

Dan.

transnet@vrx.net

2006-03-18, 3:56 am

Oh sure, soon as I post that I realize there are typographical problems
in this one too,
but its not so bad.

This is supposed to be code I went over by hand at least 3 times to
verify the printout.
it's still not right.

ugh.

Dan.

Steve Lionel

2006-03-18, 7:56 am

Jim wrote:

> VMS Fortran was always F77. It should need no conversion unless you intend
> to remove the VMS extensions.

Not ALWAYS. Version 1 of VAX-11 FORTRAN-IV-PLUS was "almost but not
quite" F77. I implemented the necessary run-time support (primarily
INQUIRE, but also a few other things) for 1980's version 2, which was
renamed VAX-11 FORTRAN, which then qualified as full F77. (That's also
when the compiler was changed to be a native VAX implementation instead
of being PDP-11 code running under RSX emulation.)

Steve

transnet@vrx.net

2006-03-18, 6:58 pm

And It might get messier than that (not sure).
There was a vax 11/750 I was using that had a PDP-8 as its FEP
(front-end processor).
So it was sorta a vax, and partly a PDP, but kinda neither and both at
the same time.

VMS was and still is one of my favorite OSes (my other fav is amiga),
guess I'm a sucker for hard luck cases or something ;)

I was using Valtrep in 1986 on a Sentry-70. Valtrep has been called the
predecessor to Fortran.

All these systems had their little quirks. But I remember very clearly
later on that the vax 11/750s I used (actually a vax 11/752) had
compiler options for BOTH Fortran/IV and Fortran/77, I think I ran vms
from about 3.1 or 3.2 on to 5.6 or so, but recently only openvms stuff,
and even my openvms 5.6 has compaq's fortran compiler on it.

And a lot of this code came from the PDP originally, either the PDP-10
or PDP-11. the last one they had that I worked on I think was a
PDP-11/45

As luck would have it, a friend of mine has a PDP (which is the size of
a full-tower PC), it's fully functional too! so that may help. At least
my life will be more fun.

I wish I had a picture, but that vax 11/750 I used, if you opened up
the front panel, there was a cross-bar inside it, the connector from
the FEP to the vax. It was stamped (by DEC) with the word "FUBAR".

But this isn't a vax discussion forum, it's fortran. But what's Fortran
without the rich history that DEC lent to it? :)

Dan.

Steve Lionel wrote:
> Jim wrote:
>
>
> Not ALWAYS. Version 1 of VAX-11 FORTRAN-IV-PLUS was "almost but not
> quite" F77. I implemented the necessary run-time support (primarily
> INQUIRE, but also a few other things) for 1980's version 2, which was
> renamed VAX-11 FORTRAN, which then qualified as full F77. (That's also
> when the compiler was changed to be a native VAX implementation instead
> of being PDP-11 code running under RSX emulation.)
>
> Steve

Jim

2006-03-18, 6:58 pm

"Steve Lionel" <Steve.Lionel@RemoveMeIntel.com> wrote in message
news:W4USf.14143$S25.10823@newsread1.news.atl.earthlink.net...
> Jim wrote:
>
>
> Not ALWAYS. Version 1 of VAX-11 FORTRAN-IV-PLUS was "almost but not
> quite" F77. I implemented the necessary run-time support (primarily
> INQUIRE, but also a few other things) for 1980's version 2, which was
> renamed VAX-11 FORTRAN, which then qualified as full F77. (That's also
> when the compiler was changed to be a native VAX implementation instead
> of being PDP-11 code running under RSX emulation.)
>
> Steve
Sorry, I missed V1. At that time I was working with Fortran IV on RT-11.

As for the printed copies, you need to understand that VAX Fortran allowed a
Tab character at the start of a line to move the carriage to position 7
which is where the source code should start. When printed, you cannot tell
that the Tab replaced several blanks. Hence what looks like a line of more
than 72 characters may not have been that long.

Furthermore, if the latest VMS Fortran compiler rejects your code, then your
code is not what you think it is. Goodness knows, I have ported lots and
lots and lots of F77 code from the VAX to the Alpha with no problems.

Jim

Richard E Maine

2006-03-19, 3:56 am

Jim <j.n@nospam.com> wrote:

> As for the printed copies, you need to understand that VAX Fortran allowed a
> Tab character at the start of a line to move the carriage to position 7
> which is where the source code should start. When printed, you cannot tell
> that the Tab replaced several blanks. Hence what looks like a line of more
> than 72 characters may not have been that long.

That's one of the multiple reasons that tabs cause portability issues
even among compilers that accept them. Since they are not standard, the
fine points of their interpretation can vary. This includes such matters
as whether the tab counts as 1 character or as the multiple expanded
blanks.

--
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

transnet@vrx.net

2006-03-19, 3:56 am

Well I will be scanning stuff soon.
Tabs and stuff may not be such a problem, as comments started on the
left most column (position 1) in many cases. so that can give a
guideline for things.

it should help.

and ... I just picked up a vax today, that PDP I wanted to pick up,
turns out it was a vax, with a TK70 on the front and everything. the
size of a bar fridge. ready to go.

I think it still works. I'm hoping anyhow, havent seen it in a few
years - its been sitting in a garage.
should be fun though.

There was another version of trek7 I had that was given out, it was
fully ported to f2c - at least it would compile without errors anyhow.
it had the same problems as the pctrek.exe that bill has, the infinite
loop or lock up issues.

Dan.

Phillip Helbig---remove CLOTHES to reply

2006-03-19, 9:56 pm

In article <oxGSf.44359$2O6.39733@newssvr12.news.prodigy.com>, "Jim"
<j.n@nospam.com> writes:

> VMS Fortran was always F77. It should need no conversion unless you intend
> to remove the VMS extensions.
> Jim

VAX Fortran was always F77, perhaps with some extensions, some of which
are standard in later versions of Fortran, some of which are identical
to later standard extensions both in form and function, some of which
are identical to later standard extensions in function but not form.

VMS Fortran can be Fortran95. I don't know to what extent later
standard features are supported, and if there are any whether they will
be available on ALPHA, Itanium or both.

Jim

2006-03-19, 9:56 pm

"Richard E Maine" <nospam@see.signature> wrote in message
news:1hcf0tx.127qhsbxb38aoN%nospam@see.signature...
> Jim <j.n@nospam.com> wrote:
>
>
> That's one of the multiple reasons that tabs cause portability issues
> even among compilers that accept them. Since they are not standard, the
> fine points of their interpretation can vary. This includes such matters
> as whether the tab counts as 1 character or as the multiple expanded
> blanks.
>
> --
> 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
As I remember, for line length purposes, VMS Fortran considered the tab
character as one. Most of my code was non portable, and the very least part
of the non portability was the status of the tab character,
Jim

Gary L. Scott

2006-03-19, 9:56 pm

Jim wrote:

> "Richard E Maine" <nospam@see.signature> wrote in message
> news:1hcf0tx.127qhsbxb38aoN%nospam@see.signature...
>
>
> As I remember, for line length purposes, VMS Fortran considered the tab
> character as one. Most of my code was non portable, and the very least part
> of the non portability was the status of the tab character,
> Jim
>

This news group tends to exaggerate the ability to achieve portability
in real code somewhat. The vast majority of code written today uses
operating system APIs for such things as GUI/graphics, threads,
processes, supporting/translating to/from non-standard data types, and
performing "binary" IO. But of course we want to strive for increased
portability and the more the language standardization process supports
that, the better.

>

--

Gary Scott
mailto:garyscott@ev1.net

Fortran Library: http://www.fortranlib.com

Support the Original G95 Project: http://www.g95.org
-OR-
Support the GNU GFortran Project: http://gcc.gnu.org/fortran/index.html

Why are there two? God only knows.

If you want to do the impossible, don't hire an expert because he knows
it can't be done.

-- Henry Ford

transnet@vrx.net

2006-03-20, 6:59 pm

How the hell can it be fortran 95?
We're talking about code from 1976 (originally!)
so even fortran/77 couldn't be possible at that time (a year too early)

or am I just too fixated on dates here? I mean really.

So does that mean the fortran done on a PDP-10 (TOPPS-10) back in early
76 would also be F/77 or F95 ?

this doesn't seem right to me. though again I am still fixated on dates
I think.
There was even another one compiler option at the time, can't remember
what it was.

I also worked on the Sentry-70 using Valtrep. Not quite fortran, but
almost.

and I made a mistake before, it wasn't a vax 11/752 it was a vax
11/782.
is a vax 11/750 still a vax if it has a PDP-8 FEP? :) hehe

Dan.

Steve Lionel

2006-03-20, 6:59 pm

On 20 Mar 2006 08:41:42 -0800, transnet@vrx.net wrote:

>How the hell can it be fortran 95?
>We're talking about code from 1976 (originally!)
>so even fortran/77 couldn't be possible at that time (a year too early)
>
>or am I just too fixated on dates here? I mean really.

I too did a double-take on Gary's post, but then I reread it.

VAX Fortran will never be F90 much less F95. The last version, 6.6, is an
extended F77 implementation.

"VMS Fortran", however, encompasses DEC/DIGITAL/Compaq/HP Fortran for OpenVMS
Alpha (and now Itanium), which is F95 in current versions.

Steve Lionel
Developer 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/

transnet@vrx.net

2006-03-20, 6:59 pm

Ok, but I'm not talking about openvms!
I'm talking about the *real* vms from the 70s, not the compaq/HP
crapola. (sorry).

so fortran from those days. if its from 1976 from DEC (digital)
directly on a vms system (not openvms) was like 3.1 at the time (maybe)
couldn't possibly be F/77, could it?

someone want to explain this?

I'm posting this seperately as another post (dupe perhaps) because its
too damn confusing!

Richard Maine

2006-03-20, 6:59 pm

Steve Lionel <Steve.Lionel@REMOVEintelME.com> wrote:

> On 20 Mar 2006 08:41:42 -0800, transnet@vrx.net wrote:
>
[color=darkred]
> I too did a double-take on Gary's post, but then I reread it.
>
> VAX Fortran will never be F90 much less F95.

Are you two responding to some other post than the one it appears? Gary
doesn't mention a word about F95 in that post. I looked twice in case I
overlooked it the first time. Then I enlisted the aid of the search
function in thsi newsreader. No 95 even appears in his post unless....

Did you two perhaps get

by thinking that the stuff about g95
and gfortran in Gary's signature was part of the body of his message? It
isn't. That's just his signature and it has nothing in particular to do
with this thread.

--
Richard Maine | Good judgement comes from experience;
email: last name at domain . net | experience comes from bad judgement.
domain: summertriangle | -- Mark Twain

Gary L. Scott

2006-03-20, 9:56 pm

transnet@vrx.net wrote:

> How the hell can it be fortran 95?
> We're talking about code from 1976 (originally!)
> so even fortran/77 couldn't be possible at that time (a year too early)
>
> or am I just too fixated on dates here? I mean really.
>
> So does that mean the fortran done on a PDP-10 (TOPPS-10) back in early
> 76 would also be F/77 or F95 ?
>
> this doesn't seem right to me. though again I am still fixated on dates
> I think.
> There was even another one compiler option at the time, can't remember
> what it was.
>
> I also worked on the Sentry-70 using Valtrep. Not quite fortran, but
> almost.
>
> and I made a mistake before, it wasn't a vax 11/752 it was a vax
> 11/782.
> is a vax 11/750 still a vax if it has a PDP-8 FEP? :) hehe
>
> Dan.
>
I was only making a general statement about portability. VAX code often
had calls to OS APIs, making it non-portable (as did inclusion of tab
characters), just like modern code does and always will if you want to
accomplish anything of significance. In reference to the "most of my
code was non-portable" comment of the person I responded to.

--

Gary Scott
mailto:garyscott@ev1.net

Fortran Library: http://www.fortranlib.com

Support the Original G95 Project: http://www.g95.org
-OR-
Support the GNU GFortran Project: http://gcc.gnu.org/fortran/index.html

Why are there two? God only knows.

If you want to do the impossible, don't hire an expert because he knows
it can't be done.

-- Henry Ford

transnet@vrx.net

2006-03-21, 10:05 pm

Ok I found it!

anyone who wants the linux verison(s) with the F2C mods, email me and
I'll send it off.

Sponsored Links