User Controls
Learn COBOL!
-
2020-04-15 at 7:30 PM UTC
-
2020-04-15 at 7:41 PM UTCHow to Geek has an article on COBOL today
Kind of spooked me but looks like there’s money to be made -
2020-04-15 at 8:47 PM UTC
Closing the COBOL Programming Skills Gap
https://ibmsystemsmag.com/IBM-Z/10/2019/closing-cobol-programming-skills-gap
By Phil Teplitzky
10/25/2019
The backbone of today's electronic commerce is COBOL on an IBM Z computing platform. There are 240 billion lines of COBOL in operation, and another 5 billion new lines are added each year. $3 trillion of commercial transactions are processed by COBOL applications each day. COBOL is what business runs on.
Some reports indicate that the 240 billion lines of COBOL code are the second most valuable asset in America, right behind oil. How did COBOL weather 60 years of technological evolution? Because there are classes of information processing that are ideally suited for COBOL on a mainframe. Back-end, high-volume transaction processing must work correctly, securely and fast. If you must process several million transactions in the six-hour overnight batch window, IBM Z COBOL is what you use.
But the community of COBOL programmers is shrinking faster than the open positions they create can be filled. The average age of a COBOL programmer is 58, and roughly 10% are retiring each year.
Emulator for IBM Z Series Mainframes on home computers:
http://www.hercules-390.eu/ -
2020-04-15 at 9:27 PM UTCThe following users say it would be alright if the author of this post didn't die in a fire!
-
2020-04-15 at 9:38 PM UTC
Originally posted by rabbitweed ???
The gulf war ended in 1991. Java was released in 1995.
Nice spot.
It was apparently assembly.
https://www.iro.umontreal.ca/~mignotte/IFT2425/Disasters.htmlhttps://www.iro.umontreal.ca/~mignotte/IFT2425/Disasters.html
https://embeddedgurus.com/barr-code/2014/03/lethal-software-defects-patriot-missile-failure/ -
2020-04-15 at 10:04 PM UTCOr maybe it was C or Ada. Can't find shit on specifics.
https://hackaday.com/2015/10/22/an-improvement-to-floating-point-numbers/
OTOH the Ariane 5 failure was Ada.
http://www-users.math.umn.edu/~arnold//disasters/ariane5rep.html -
2020-04-15 at 10:23 PM UTCNope, assembly. Had to go to Archive.org for the actual story, not just the simplified version:
Roundoff Error and the Patriot Missile
https://web.archive.org/web/20090416015820/http://www.mc.edu/campus/users/travis/syllabi/381/patriot.htm
Robert Skeel
The March 13 issue of Science carried an article claiming, on the basis of a report from the General Accounting Office (GAO), that a "minute mathematical error … allowed an Iraqi Scud missile to slip through Patriot missile defenses a year ago and hit U.S. Army barracks in Dhahran, Saudi Arabia, killing 28 servicemen." The article continues with a readable account of what happened.
The article says that the computer doing the tracking calculations had an internal clock whose values were slightly truncated when converted to floating-point arithmetic. The errors were proportional to the time on the clock: 0.0275 seconds after eight hours and 0.3433 seconds after 100 hours. A calculation shows each of these relative errors to be both very nearly 2-20, which is approximately 0.0001%.
The GAO report contains some additional information. The internal clock kept time as an integer value in units of tenths of a second, and the computer's registers were only 24 bits long. This and the consistency in the time lags suggested that the error was caused by a fixed-point 24-bit representation of 0.1 in base 2. The base 2 representation of 0.1 is nonterminating; for the first 23 binary digits after the binary point, the value is 0.1 × (1 - 2-20). The use of 0.1 × (1 - 2-20) in obtaining a floating-point value of time in seconds would cause all times to be reduced by 0.0001%.
This does not really explain the tracking errors, however, because the tracking of a missile should depend not on the absolute clock-time but rather on the time that elapsed between two different radar pulses. And because of the consistency of the errors, this time difference should be in error by only 0.0001%, a truly insignificant amount.
Further inquiries cleared up the mystery. It turns out that the hypothesis concerning the truncated binary representation of 0.1 was essentially correct. A 24-bit representation of 0.1 was used to multiply the clock-time, yielding a result in a pair of 24-bit registers. This was transformed into a 48-bit floating-point number. The software used had been written in assembly language 20 years ago. When Patriot systems were brought into the Gulf conflict, the software was modified (several times) to cope with the high speed of ballistic missiles, for which the system was not originally designed.
At least one of these software modifications was the introduction of a subroutine for converting clock-time more accurately into floating-point. This calculation was needed in about half a dozen places in the program, but the call to the subroutine was not inserted at every point where it was needed. Hence, with a less accurate truncated time of one radar pulse being subtracted from a more accurate time of another radar pulse, the error no longer cancelled.
In the case of the Dhahran Scud, the clock had run up a time of 100 hours, so the calculated elapsed time was too long by 2-20 × 100 hours = 0.3433 seconds, during which time a Scud would be expected to travel more than half a kilometer.
The roundoff error, of course, is not the only problem that has been identified: serious doubts have been expressed about the ability of Patriot missiles to hit Scuds.
Robert Skeel is a professor of computer science at the University of Illinois at Urbana-Champaign.
From SIAM News, July 1992, Volume 25, Number 4, page 11 -
2020-04-16 at 12:18 AM UTC
Originally posted by Cathay Coof It's simplicity is why it's so great. Most of the bugs we catch are due to Java programmers trying to do weird and clever things.
Ehh, I mean it is simple. Go is simple. It has a lot in common with Go actually, good and bad.
Simple without ergonomics isn't really enough to be something you want to use. I mean I don't think COBOL is that bad, but there's like pretty much zero reason to use it for a greenfield project.
Totally agree that Java is a blight on humanity at this point. -
2020-04-16 at 9:36 AM UTCJava is OK when you get into it, but super slow. Yeah, they bullshit about how Java is so fast because of how fast it executes loops or whatever, and blame it being slow on the programmers being Indian basically (if you read between the lines) but when you're sitting around a minute waiting for a Java program to load it's becomes obvious what the reality is.
About the only problem with Cobol is ANSI encoding fucking up foreign people's ńämęß.
What would you recommend for a new project at a big bank, that isn't framework-of-the-month, and is reasonably secure and maintainable? -
2020-04-17 at 5:14 PM UTC
Originally posted by Cathay Coof Java is OK when you get into it, but super slow. Yeah, they bullshit about how Java is so fast because of how fast it executes loops or whatever, and blame it being slow on the programmers being Indian basically (if you read between the lines) but when you're sitting around a minute waiting for a Java program to load it's becomes obvious what the reality is.
Well there's no denying that the JVM is pretty damn heavy, but it is fast when it gets going. The language and culture around Java do lend it to ending up being slow, and I gotta be honest, poorly trained Indian (and non-Indian) programmers are a part of that. If you look at other JVM languages they have the performance characteristics you'd expect, e.g. Clojure takes forever to start up but then is fast, and like that's actually something observable in real programs because there isn't the AbstractDildoBeanFactoryStrategy culture.
Long startup times are someone people are willing to accept, if you think about how many programs these days are long running processes that offer up some kind of API you get to through some kind of IPC mechanism (web stuff is a huge chunk of this, but I mean even modern OSs use daemonized services heavily). In more dynamic languages than Java (again, see Clojure) where you can make a code change or do something useful without restarting the JVM this is even less of a problem.What would you recommend for a new project at a big bank, that isn't framework-of-the-month, and is reasonably secure and maintainable?
That's an interesting question! I actually think banks are exactly the right place for Haskell when you think about the general structure of banking operations (a bunch of logic, massive concurrency that is relatively amenable modern synchronization techniques, do-or-die commits, currency stuff is a good fit for strong/rich typing, long release cycles). Eiffel would also be a good fit and something that would have actually had a chance at adoption if it wasn't a Java in front of COBOL race-to-the-bottom on programmer skill/salary monoculture.The following users say it would be alright if the author of this post didn't die in a fire! -
2020-04-17 at 5:30 PM UTC
-
2020-04-18 at 8:34 PM UTC
-
2020-04-18 at 9:06 PM UTCin high school my friends wizard looking, pagan hippie acid freak programmer dad had a dog named Cobol. He smelled like shit and dug deep ass holes all over the yard. He ate the frozen piss when one of our friends pissed in the freezer in the garage.
thats my contribution to this thread.
But yeah the dad played Civ 2 until like 5am every night, smoked weed withus, talked me thru a mescaline trip and had worked on the alaskan satellite array. Cool dude.The following users say it would be alright if the author of this post didn't die in a fire! -
2020-04-18 at 9:12 PM UTCwhat the fuck y'all? cobol?? just type yo shit in english for me and ALL to care...
anything less is lazy and pathetic. PERIOD. -
2020-04-18 at 10:12 PM UTCfuck no op is a bitchnigga
-
2020-04-19 at 8:51 AM UTCRPG is even more obscure than Cobol, but still in use and still in demand.
https://en.wikipedia.org/wiki/IBM_RPG
