oldie but goody

[mhull]

I used to run a fortran iv compiler on IBM 360 and 370 hardware in the late 1970s.
You will need:
// exec fortfclg
for execute fortran (f) compile, link, go
I don't remember if the F is for fortran (f)our or if it was the (F) version of the compiler.

Very close. FORTGCLG as it turns out. I actually found Fortran IV G for MVS which contrary to rumors is actually in the public domain. I now have it installed on MVS 3.8 using TK4- via Hercules emulator, and a version of the partially cleaned-up Blitz code loaded in a PDS. Apart from the necessity of upper case for FORTRAN, it seems to be friendly to Blitz6 code generally. Easy mode at last, perhaps.

For mainframe nostalgia, TK4- is a turnkey setup. You can run it under Linux or Cygwin. The opensource SPF environment and period everything-else takes some getting used to, especially if your job is using modern z/OS.

For PC platforms, the last version of gcc that featured g77 was 3.4. That would get one to the -ff66 switch and "easy mode".

[Dann Corbit]

Talk about a blast from the past! It's "Back To The Future!"

[mhull]

Talk about a blast from the past! It's "Back To The Future!"

I don't suppose you remember what the system call was for time-of-day when you were doing Fortran on the 360?

[Dann Corbit]

Talk about a blast from the past! It's "Back To The Future!"

I don't suppose you remember what the system call was for time-of-day when you were doing Fortran on the 360?

Sorry, that was 1976-77 and my JCL and FORTRAN IV are getting a bit rusty.
But here is the manual:
http://bitsavers.trailing-edge.com/pdf/ ... LogMan.pdf

[Dann Corbit]

One thing that may be helpful is to give:
//class=P, time=1440
because on an IBM mainframe, a job with more than 200K RAM requires special permission (class =p means high priority) and time=1440 means let the job run as long as it takes, because the job gets a forced timeout when the time limit is exceeded.
Class=D is good for up to 200K. Class=A is only for tiny jobs.

[Dann Corbit]

A horrifying thing about FORTRAN IV is that only the first two letters in a variable name are recognized.
so:
JIVE =1
JIM = 2
both represent the same variable. The easiest way to keep track is simply to not use variable names longer than two letters.

[mhull]

A horrifying thing about FORTRAN IV is that only the first two letters in a variable name are recognized.
so:
JIVE =1
JIM = 2
both represent the same variable. The easiest way to keep track is simply to not use variable names longer than two letters.

I'm not sure about that. Look at page 21 (on the right) in this link:
https://archive.org/details/bitsavers_i ... 3/mode/2up

[mhull]

One thing that may be helpful is to give:
//class=P, time=1440
because on an IBM mainframe, a job with more than 200K RAM requires special permission (class =p means high priority) and time=1440 means let the job run as long as it takes, because the job gets a forced timeout when the time limit is exceeded.
Class=D is good for up to 200K. Class=A is only for tiny jobs.

Good to know. This seems to be the CLASS convention for MVS3.8j. These days, class designation is determined by site engineers. At my shop, user short jobs are CLASS=L, longish ones CLASS=M and infinite jobs and TAPE are CLASS=H, and "production jobs" (run by the production job scheduler) are CLASS=P.

But when BLITZ6 is finally built, I imagine it should run under TSO for interactivity.

[Dann Corbit]

TSO was in beta when I worked on the IBM mainframe.
At the time, we saw one line of input at the terminal.
It was like DOS edlin from way back in the day.
At the time, I thought it was utterly incredible.
"Look at that! I am changing the virtual image of these cards right from this terminal!"

[mhull]

Talk about a blast from the past! It's "Back To The Future!"

I don't suppose you remember what the system call was for time-of-day when you were doing Fortran on the 360?

Sorry, that was 1976-77 and my JCL and FORTRAN IV are getting a bit rusty.
But here is the manual:
http://bitsavers.trailing-edge.com/pdf/ ... LogMan.pdf

Thanks very much for that link. Turns out that Fortran of this vintage has no built-in capability for acquiring DATE/TOD information. No problem. The solution is to link into your project a callable assembler subroutine that uses a TIME macro that returns these values to your program. It works on my small test program.

The other required system hook for TSO interactivity is an "attention interrupt" handler, i.e. pressing the ATTN or PA1 key to signal BLITZ that the user wants to enter the opponents move while the program is pondering. BLITZ has a "break" subroutine designed to be invoked by this kind of interrupt. Once again the solution an assembler subroutine that invokes the STAX macro which adds a hook to your project for directing ATTN interrupts to a specified subroutine address (the "break" subroutine in BLITZ). Haven't coded this yet but once done, then compile AND link can commence.

Meanwhile all the Fortran modules now compile without errors with the FORTRAN IV G compiler. Two other compilers on this system, FORTRAN-H from the Goddard Space Flight Center and FORTRAN-H-EXTENDED, have optimization flags (unlike the G compiler). If the program gets to a smooth-running state under G, then optimization using one of the H compilers might be productive.