I would somewhat rephrase that. FORTRAN, from FORTRAN IV to its later incarnations, was a very versatile language and could be used for almost anything. I’m not closely familiar with COBOL for the VAX, but historically DEC was largely in the scientific space despite a growing corporate presence in their later years, and I’m sure that VAX FORTRAN was technologically far ahead of their COBOL implementation, which was really just a “must-have” kind of feature rather than a strong selling point. From a business standpoint COBOL had a lot of features like character field management that made it much more suitable for business forms than the basic mathematical orientation of FORTRAN. Growing up as I did in a computer science environment, COBOL was always the target of ridicule, but it was a good tool for the things that businesses typically needed.
Don’t forget SWylbur, TSO, and ISAM.
MrsRico started way before me, with memory drums (access timing was critical) and punchcards, even. Before that she programmed wire-wrap cards. Ah, but punchcards! Two couplets from those days:
Q: How can you tell if they’re a programmer?
A: By the rubber bands around their wrists.
Q: How can you tell if they’re a professional programmer?
A: They wrap TWO rubber bands around the card deck.
Random trivia: access timing was indeed critical, but it was automated and from the earliest days that was the job of the assembler. The first IBM commercial computer, the IBM 650, which used vacuum tubes and a rotating drum for main memory, came with an assembler called SOAP, which stood for Symbolic Optimizing Assembly Program. Like modern assemblers, its main job was to convert symbolic instructions into machine code, but the “optimizing” part was that it knew the execution time of each instruction, and located the next instruction at a drum address that would rotate under the read/write head precisely when the instruction had completed. It also had an option for an extremely limited amount of core memory, which was available at the time but very expensive.
I’m not sure what you mean by “programmed wire-wrap cards”. In my experience the general structure of computers in those days is that cards were basically plug-in circuit boards that contained a number of logic gates to perform a particular function, and plugged into a backplane that had slots for them on one side and about a bazillion pins (usually gold-plated) on the other. Wire-wrapping was done on the backplane, and the interconnections were astoundingly numerous and complex. This is part of the backplane of a very simple 12-bit minicomputer that had about a millionth the computing power of your smart phone. How that wire-wrapping was done without error is still an astounding human accomplishment. Nevertheless, even in my day of solid-state logic and core memory, it was quite standard for such computers – small or large – to be installed and initially not work. When they finally did work, it was SOP to leave them running tests for several days. As an enthusiastic young lad, the wait time for my new toy to be officially turned over for production use was almost unbearable. This was generally after waiting 6 to 8 months or so from order to delivery.
I used Vax Cobol for a couple decades and it was better than you’d expect. I don’t know about Cobol on other platforms like IBM but Vax Cobol was regularly upgraded with new features. In the late 90’s when everybody was flocking to C programming, they even added pointer capability to Cobol. I never used that but read how to use it in the reference manual. It was interesting. Implementing things like that were quite tedious, especially compared to implementing pointers in C (which I was used to).
Speaking of legacy systems, my last software engineering job included upgrading the systems of a couple of very large clients. Their systems were originally installed on vax clusters back around the late 80’s with an early version of our software that was entirely written in Vax Macro (assembler). The upgrade projects I was assigned to were replacing the now-very-old Vaxes with new HP Integrity systems running the newest version of OpenVMS. Same application, though. To port the old Vax Macro to the newest version of Macro (I think they only dropped the word “Vax” from the language name by then) we had to tweak a few of the deepest modules but otherwise it was nothing more than recompiling the whole system. Those were fun projects.
On the other hand, I also had a few smaller projects just doing feature enhancements to those client’s applications. Those were miserable because the code was so brittle. It felt like if you so much as sneezed in it’s direction, it would start throwing errors in production.
Someplace in NJ tried to recruit me for COBOL work back in the 90s. Could have been this code but I don’t recall the details. Then, as now, coding COBOL in New Jersey is a special place in programming hell. I feel bad for anyone so desperate they would take this job.
To the secondary argument going on here: FORTRAN is a very basic procedural language, just about anyone familiar with any other could quickly learn to read, write, and modify FORTRAN code. COBOL is an enormous language in comparison, it has extremely verbose syntax with multiple means of performing the same simple computation using very different syntices* and subtle semantic differences. It is not easy to become proficient in COBOL, especially when stepping into the midst of a huge that has mis-evolved over decades, and I’m sure is largely a mess from trying to maintain it with less than proficient programmers.
Early 2000s a Bank recruited me for what turned out to be 85% COBOL. I turned it down and stuck to the job I had at the time. This was in New Jersey of course.
saw a cartoon at a funeral. Guy says to the widow “I know this is a tough time but did he ever mention source code?”
One of my old-time favorites, now it’s source code, it used to be about some cans of paint.
*forgot to mention in previous post: I know ‘syntices’ is not the plural of syntax, but it oughta be.
My all time favorite programmer joke…
What’s a S0C4?
To keep your feet warm.
Never underestimate how kludged up legacy systems can get. When I was an astronomy student in the late 90s, the main telescope in our observatory was run by an Apple ][e. The Apple ][e was attached to an OS2/warp computer for use as a front end. That computer, in turn, communicated only over an isolated intranet, to a bank of computers running DOS and Windows 3.1. To get data off of those computers, you saved it to an Exabyte (brand name, not actual size) large-format floppy, and moved the floppy to the only other computer that had an Exabyte drive. That computer connected via another private intranet, to a modern (at the time) computer (Win 95) that also connected to the Internet and such.
It would have been ever so much easier to just run the scope directly from a modern computer, but setting that up would have required more work than adding one more layer of kludge, and so what happened was just an endless stream of layers of kludges. Of course, eventually something in that huge process is going to break, and then all work will be shut down until someone (hopefully) takes the time to do it right.
I’ve also had the task of maintaining ancient, undocumented, uncommented code (in my case, Fortran77). I started by converting it all to rich text, with a little script to convert it back for compiling, so I could color-code things (in context-specific ways which an IDE wouldn’t know how to do) and use subscripts and superscrips to indicate which arguments to a function were input and output, and so on. I never did get it right-- Some of the code was the result of OCRed scans of printouts, never saved in softcopy, and it was impossible to be sure about all of the Os vs. 0s, or Is and 1s. The manager of that project got really upset at me fixing the code, because it “worked perfectly”, and I was just supposed to feeding in a different set of garbage inputs. She knew it worked perfectly, because it always gave the right answers, and she knew they were the right answers, because they matched what the code produced.
Legacy code…
I don’t think I’ve ever seen any that wasn’t a mess.
Dead code. Redundant code. Variables passed but never used. Globals that shouldn’t have been. Code that gave wrong answers which someone else corrected elsewhere. Code that simply gave wrong answers and had been doing so for years.
For wolfpup, Rico is referring to plug boards, shown at 1950’s tax preparation: plugboard programming. I have one of those Time-Life books from 1966 written for high-schoolers, titled Mathematics. They had half of a page about computer programming, and at that time that’s what they were using to describe computer programming.
I never programmed one, but I bought one on eBay. I bring it in to my Data Structures class, along with some punch cards, to show what “structured data” was originally - and in some ways, still is.
Almost forgot: CICS!
Who remembers?: ABEND(S0C7)
Yes, specifically what I thought of when I saw the thread. 99% they want CICS programmers for their COBOL application, not COBOL programmers as such.
A programmer co-worker brought her great Newfie to the wedding of MrsRico and I. The dog’s name? Oh-Cee-Seven.
I know people who can deal with that; it can’t be that rare. Like I said, $1000/hour might attract more of them, who might otherwise “volunteer” to stay at home and drink Scotch whisky.
Does anybody know the going rate they are paying for these positions? I hear other states, like Michigan, have a similar need. I didn’t take it very seriously at first but if it’s for serious money I’ll happily dust off my MVS skills. It was the most fun I ever had as a developer.
They are looking for volunteers.
ETA: That sounds like a joke, but here’s the link from the OP:
…volunteer…? 'eff that.
Volunteer to learn a obsolete system well enough to modify and test the changes?
Oh hell no.
That’s a lot of work just to familiarize yourself. First you have to learn the main files and records. What programs update them? It’s probably forms that you need to look at.
No way would anyone put in that Amount of work and stress for free.
My background is Honeywell GCOS 3 and GCOS 8. Honeywell CP-6. Vax VMS
I started with COBOL-74 and later COBOL-85. I did a little maintenance on COBOL-68 but or shop migrated to COBOL-74 after I was hired.
Never got near IBM CICS.