Time to fire up the old PDP-10.
FORTRAN 15
June 2016 - Working draft available
July 2016 - WG5 straw ballot
February 2017- Committee draft available
March 2017 - WG5 ballot on committee draft
October 2017 - Draft International Standard available
November 2017 - Ballot on Draft International Standard
February 2018 - Final Draft International Standard available
April 2018 - Ballot on Final Draft International Standard
July 2018 - Standard published
https://software.intel.com/en-us/blogs/2015/09/04/doctor-fortran-in-one-door-closes
Wow. I haven’t messed with FORTRAN since ‘79. I hope the accursed punch cards are history...
Intel is still committed to FORTRAN.
I programmed in Fortran for close to thirty years. What got me out of the ‘Biz’ wasn’t the programming, it was the ensuing documentation. When I first started a job that involved a one line code change plus testing and documentation took eight hours or so. When I left it was at least six month’s from start to finish plus almost a half a million dollars in overhead.
It was just too much...
Now I’m much happier doing what I’m doing.
Boy do I remember those days.
COBOL/CICS and JCL with VSAM structures.
DELETE/DEFINE files before loading them.
Fun stuff and pretty easy.
I even did Assembler for my old banks connections from the branches to the mainframe. Quickest code to read the deposit/withdraw information back and forth to the branches.
Time to fire up the old PDP-10.
+1
I remember what was it, about 20 years ago, I threw away a deck of Cobol cards that were a language interpreter for something - think it was a tape management system.
Since then, I’ve consulted, been an employee, but now simply contract as a systems programmer.engineer exclusively for mainframes.
But don’t get me wrong - I agree with you premise, that no one knows Cobol or Fortran or any of those anymore.
And sadly, as far as the Internet goes, Cobol would have kicked the shit out of Java!
FORTRAN, PL/1 and COBOL were not hard to learn. PL/1 was my favorite.
At 60, I can handle the COBOL/FORTRAN. What I can’t handle is the SOX BS and dealing with the people in India. Retired I shall stay...
Worked on one project to move key applications off a mainframe. The replacement system would have been more flexible but required over a hundred servers to replace 1/3 of one mainframe LPAR. When management saw the cost, the whole project was cancelled. Ironically, the best replacement configuration turned out to be...a mainframe supporting virtual servers.
When were mainframe systems ever “cool”?
A good software engineer can write FORTRAN in any language.
I learned FORTRAN II (that’s 2 not 11) in college in ‘64. Ran it on an IBM 1620. You had to load the compiler deck of several hundred cards through the card reader. A guy in the class dropped the compiler more than once. He got very proficient at operating the card sorter.
Mainframe operators, themselves, are dying off like dinosaurs because everyone went on this cloud kick and yet the cloud is, IMO, just as vulnerable. Stripping away all the jargon and bullsh— techies love to babble, a mainframe requires sunk costs in a physical system that must be constantly updated and is vulnerable because it exists in one physical location. A cloud requires paying to outsource this to another company and is vulnerable because the business must access their important data through an internet connection that isn’t (and probably never will be) 100% secure from hackers and terrorists.
I guess enough businesses have been stung by the cloud that they are rebuilding their mainframes again which, at least, the business has more physical control and access over their data.
The wisest approach, which I have seen in action, is a redundancy approach where data centers exist in more than one location and the cloud is used as a backup storage location as part of a disaster recovery plan, meaning you have a mainframe that does the primary work, a second physical mainframe in another city that can take over for the primary during maintenance and physical emergencies (hurricanes, for example) and a third backup of data in a cloud system should both mainframes be affected at one time.
This triple redundancy is expensive but it is the wisest approach for any business where their data is their lifeblood.
This COBOL programmer ready to come out of retirement. Any takers?
Are you saying I could go back to work as a COBOL programmer?
A company I was working for fired all its COBOL and Fortran programmers and hired Satyam. That was exciting.
I programmed in IBM S370 Assembler language for 12 years... couldn’t find work after Y2K.
Started my own business.
Would like to get back into programming if this is true.