• Please review our updated Terms and Rules here

DEC Fortran IV

Mike_Z

Mike_Z

Veteran Member
Joined
Dec 1, 2013
Messages
1,713
Location
Near Milwaukee Wisconsin
For the last few days I have been writing a DEC Fortran program on my PDP8e. The program asks for 3 lengths, checks if these lengths make a valid triangle, if so, then calc's it's area. I was using EDIT to enter source code. I found EDIT to work fine, but was a little tiring. I looked into TECO, but got confused. Then I tried to write the Fortran source code in CP/M2.2 WordStar and transfer it to the PDP8e via Kermit 80. For some reason I could not get Kermit 80 to work in both directions. So I tried writing the source code in SMART word processor on my IBM XT then transfer the code via KERMIT DOS. This worked in both directions. I was progressing until yesterday. Then for some reason I started to get compiler errors such as misspelled keyword and missing operands. I could not see any of these errors in my simple code. So I tried just removing the offending lines. This just moved the errors to other lines. The next thing I tried was to write a very simple source code and transfer it. The same problems occurred. I wrote the same program using DEC EDIT and there were no errors. This led me to believe that maybe KERMIT was changing something. This also was not the problem. Then it occurred to me that the Fortran IV source code is based on punch cards. The layout of the source code has to match code that would be punched onto cards. The problem was my SMART word processor. I had it set to produce a text file, but it's default setting was to use a 5 space left margin and 10 space tabs. Most times these setting were not a problem, until I started to use label numbers. The layout for these lines were 5 spaces then the label number. A punch card uses the first 5 columns for the label and the 6th column is the continuation character. My label line numbers were occurring in the continuation field. I found that any non space character in the continuation field is read a continuation. So my SMART text file was confusing Fortran. After resetting the margin and tab settings of SMART, I can now write source code in the IBM XT and transfer it to the PDP8e with no problems (at least for now). Now I can get back to error codes like undefined statements etal. Just thought you might be interested. Mike
 
Thanks for passing it on... I'm getting ready for some projects in Fortran for RT-11. I'm taking note of your suggestion.
 
Slight correction: FORTRAN IV says both zero and space in the continuation column signal no continuation. It's surprising how many references get this wrong, but it's in the standard.
 
Not to question you, Chuck, my OS/8 Language Reference manual says only a space character. Yet, my copy of Fortran IV Primer by Organick says a space or a zero. The OS/8 handbook also say only a space character. McCracken's guide says both a space or a zero will work. I also looked at ANSI 3.9-1966 and it states a continuation character is a space or zero in column 6. I wonder why DEC does not mention the zero. I'll have to test it out. Thanks for the minor correction. Mike
 
I think DEC would have had serious problems with any of the major FORTRAN packages were 0 not to count as a space. 0/space in column 6 has been that way nearly since the beginning (Original 704 1956 FORTRAN said that continuation was signaled by a "mark" in column 6). 1958 704 FORTRAN II (see PDF page 15) says that anything but a space or 0 in column 6 signals a continuation. The 704 implementation is why only columns 1-72 are read by the compiler--the 711 card reader could transfer only 72 columns out of an 80 column card; the actual columns transferred was determined by a plugboard).

A widely-used stylistic convention on continuation was to punch the first card with a "0", the next with a "1" and so on. This had the advantage of indicating that continuation cards were to follow.
 
A Blast from the Past!

One of my first engineering courses at University of Florida involved working with the WATFOR compiler on an IBM 360 in batch mode. The upper classmen used interactive Selectrics to enter their programs but we freshmen had to make do with the classic IBM 029 keypunch and submit actual card decks held together with a rubber band. The "text" was a publication of the data center that specified that we enter a 'c' in column 6 for a continuation.

As for the contents of columns 73 - 80, If you didn't use them to hold a sequence number, you'd wish you had if/when that rubber band popped and dumped your project all over the floor an hour before it was due.
 
Rubber band? Try a couple of filing-cabinet trays of cards on an I/O cart that upsets when it hits a loose separator in a raised floor. The other thing that helped was using a felt-tip marker to run a diagonal line across the top of each deck. But on serious stuff, sequence in 73-80 so that you could take the mess to the 082 and sort it out.

But SOP was getting the deck intact to a card reader and then committing the whole thing to tape. There were library programs to manage deck libraries and permit editing by card directives.
 
Mike_Z said:
I looked into TECO, but got confused.
Click to expand...
Yea. As a rule, I've never been really comfortable with the command line character editors. I feel like half the time I'm typing in the dark.

That included things like TECO and CP/Ms ED. Unix ed(1) is a line editor, so it's not as problematic.

You can get used to anything, but last time I had a quick, 5 minute crash course in TECO it was definitely a struggle.
 
I loved TECO back in college. Never have liked ED. Now I use VI for most Linux things.
 
I'm waiting for someone to write a good vi clone for the 8. Doesn't have to support all of the features, but having it modular enough where you could assemble in certain features and leave out others would be very nice.
 
antiquekid3 said:
I'm waiting for someone to write a good vi clone for the 8.
Click to expand...
Sounds like a challenge!

But wouldn't this be just a medium complexity TECO macro :)?

I once saw (and used) a WYSIWYG editor for the VT52 that was a TECO macro.

I do think the EMACS-like thing that was done recently is currently a contender for best/easiest editor for the PDP-8. (Still wish it was nano compatible.)

Vince
 
I'm not an Emacs or TECO guy myself, so I have no idea what would be involved writing macros and such. I do feel like, while it might be reinventing the wheel a bit, a native vi would be smaller and more performant than a macro solution, and certainly more fun! :)
 
What's all this vi and TECO stuff? When I wrote a lot of FORTRAN, it was write it up on a coding form, keypunch it, run an 80-80 listing on a 407, correct any errors and run the deck. If something went wrong and the program crashed, get a dump printout and spend a day or so desk-checking it. When interactive terminals came around, it was wonderful--you could make twice as many errors in the same amount of time. I imagine that in the early days of the PDP/8, the terminal of choice was either a Teletype or DECwriter.

I'm guilty of writing a line editor (you can't really do visual stuff at 300 bps) that used vector instructions. I called it OGNATE for "Oh g*d, not another text editor".

Now, get off my lawn! :)
 
I don't know what vi is, but I do know what dropping a deck of cards means. In '65 I was using a Bourrghs 5500 and an IBM 029 card punch. You would work and work to get the program right, submit it prior 5PM and they would run all the batch files that night. Then in the morning you would get a print out and your deck, most likely with syntax errors. Never actually saw the computer, but a lot of the key punch and coding forms not to mention those damned syntax error messages. Punch cards are neat to think about, but not that much fun to program with. But that was there was. Later, we had an Interdata 14 that could service a bunch of teletypes. Like Chuck said, you could make more mistakes and correct them much faster. Mike
 
VI is a text editor common to Linux, maybe Unix. There are even versions for Windows. It's easy to use and quite powerful. But has loads and loads of specialized commands that I never use. Maybe a handful or a bit more are what I use and that's all I need. Never have liked line oriented editors. Emacs took me awhile to get used to also, but is very powerful.

I saw someone drop a card box that had no sequence number or black stripe. They just started crying. I was always careful transporting card boxes with rubber bands on the box too.
 
antiquekid3 said:
a native vi would be smaller and more performant than a macro solution, and certainly more fun!
Click to expand...
Agreed. Challenging, too with the limited memory size. You can't just read in the file and work on it. OS/8 also has the challenge that files are contiguous, and you may not even be able to get enough blocks together in one place to output a result!

One possibility would be to output some warning at the beginning about the amount the file can grow (or must shrink?) before the output area is full.

I recall the PDP-11 version of vi had strange tables that hashed into the temp file to find the lines.

Vince
 
VI is the real unix text editor. ED predated it but IMHO was way too limited, so I never used it. You can count on VI being on any real unix system.
And once I punched a program card deck I always took a black magic marker and made a prominent diagonal stripe on one edge of the card deck. Just in case. Only had to use it once.
 
I've dropped, and seen dropped, a couple of decks in my day. They weren't even my decks. I was a college "consultant" that helped folks with their work on the computers, and we had an RJE station folks could use to load decks, and on occasion, I dropped theirs.

Largest deck I ever saw was, I'm going to say, about 6 feet long. The guy carried it in a couple of trays on a cart.

Ideally you have your cards numbered, but, minimally, again ideally, you have a most recent printout of the code/data to help you reorder things should the worse happen.
 
You must log in or register to reply here.
Back
Top