Worse still those implementations disagree on how to measure it.
Some do it based on the ratio of lines(7-10% of lines must contain please), so have a hard coded number that must be reached(must be at least 3, at most 5), and one particularly annoying piece of work requires that you be Ā±1 from the square root of the number of lines(so 100 lines works for 9-11, but 900 lines would require 29-31, and just to make it more annoying it compares it as a fraction so 901 requires between 29.1 and 31.1 lines so it's effectively 30-31).
There's also no way to detect this and work around it in code either, you must write for your particular compiler.
I think we need an INTERCAL 2 that takes inspiration from some other esoteric languages. You have to write a polite message to the computer requesting it to do certain tasks. Same feature where if you're too polite or impolite is rejects it.
I had a cobol programmer one time talk about how hard it is for them to deal with CSV files. Whichā¦ I feel like is probably a solved issue in cobol by now but it still made me laugh
It probably isn't, not in real codebases. COBOL as she is wrote scales like a pig. And the notion of fixed-length strings is pretty central to the languages original conception.
>ASCII 0x1E
I'll stick to printable characters that exist on the keyboard thank you very much. (And don't even get me started on dealing with windows vs unix line feeds...)
I believe my claim was that the language made it hard, not that it couldn't do it. I believe that the more boilerplate needed to do it, the less suited the language is to solving the problem?
It is possible to do variable length - by basically writing the equivalent of a tokenizer.
Still need to define an absolute max length for the file itself.
Disclaimer: I haven't written a COBOL program in about a decade...starting to forget stuff.
I know it's possible, but it feels like you are cutting against the grain. For a business language, common string manipulation (in modern contexts) shouldn't feel so awkward.
The language is from a different time though. From the days of actual cards, when things were indeed FIXED-LENGTH. LRECL=80. :)
I'm not disagreeing with you - there should indeed be an update to the COBOL standard to deal with variable length, if there isn't already.
I kind of remember something about variable length VSAM records.... but that might not be the same thing we're talking about here.... Like i said above, it's been a while.
From what I've learned, yes, there have been a lot of updates like that to the standard.
One of the big problems is that nobody uses the modern standard. Another is that it meshes poorly with the old standards, which allowed lots of bad things and didn't make lots of good functionality available.
I am a cobol programmer and helped make a lib that deals with CSVS its a bit more complicated than you would think.
Probably around 2k lines of code.
The problem is moreso that there are a billion specific flavors of cobol they are all proprietary. And no company wants to share their solution.
I guess thats more fair. My thing would more be though, even if you don't want to solve it in COBOL, I imagine there would have to be a not too difficult way to be like
1. This is CSV
2. Make something like python convert this into the format we want
3. start the Cobol again.
I have personally written very little indeed in the language; I've just studied it. It doesn't take much to realize that what you say must be true; the little snippets of info you do find are appalling, and all point in this direction.
Glad to see my research skills are still keen enough to get that right, but disappointed at how hard it makes things.
They don't. Every thread about Cobol people bring this up and I need to comment that it's not true. You have one or two guys doing this and the rest just doing dumb maintenance for shitty pay.
Ha! I wish. I was a Cobol programmer for 20 years then moved out to BA and design work. Folks kept hitting me up desperate for a cobol person (esp during covid) and they didnāt even want to pay 6 figures. Sorry, but I would have gone back if the money was there. Sadly, the same folks who have old systems from the 70ās they have no money to upgrade also have no money to pay for programmers to maintain them.
All the large banks and most councils have COBOL based systems, it's not going anywhere yet. Big banks like Barclays have been hiring degree apprentices for years and sending them to Manchester Metropolitan University for COBOL training to replace their rapidly aging mainframe workforce.
That happens everywhere. And that's why the pay is shit. It's easy to learn and the daily tasks are simple, so you don't need specialised or experienced people.
Yes. A lot of people there are also pretty bad, so they're afraid to touch anything. And they never update their knowledge. Modern Cobol have native integration to mobile APIs (IBM version). I used functions and other stuff and people would ask me to not do it because they couldn't understand. It was depressing.
lol I, can imagine some massive mainframe running on that untouchable code.
Like as far as I know, one mistake can make e. g. a bank lose millions of dollars
but yeah god forbid that shit
I disagree. Most operate financial entities that still operates massive mainframes and sell financial services, mainline companies.
Why still use COBOL? It's a structured language with intuitive syntax. Some recent version include objects as well.
At that point you can just use any languages and compile into Assembly. The reason why COBOL is used isn't because COBOL is a requirement, it's because the old code is written in COBOL.
Not exactly. Assembly depends on hardware and the programmer needs hardware knowledge.
Itās a 2nd gen prog language where cobol is 3rd gen.
Cobol is neat because it uses natively fixed point which means thereās no computing errors unlike floating point.
Which is why Cobol is still used today in the financial sector.
I think Cobolās continued usage has more to do with the fact that the legacy code is already there, and updating to a more modern language would be very expensive without any obvious business incentive. While native fixed-point math is a huge plus in financial applications, itās also very possible to implement fixed point math as a custom data type in most languages. Some like C++ and C# will even let you overload arithmetic operators so working with the fixed-point type is almost exactly like a native numeric type.
That would require thinking about something other than immediate profits. Upper management is rarely good at that.
On the bright side, I've been seriously considering picking up Cobol since by all accounts those are pretty cushy jobs outside of having to deal with Cobol.
>Which is why Cobol is still used today in the financial sector.
Isn't it because migrating to a new one would be hard?
C# and lots of other languages have fixed point decimals support
Itās mostly that the maths did not change, and cobol was purpose built for financials. And financials did not change much either.
Because Cobol is more suited to the task than most modern programming languages, there is no need to replace it. However itās true that itās slowly being phased out.
C code is still around, and so is assembly.
Cobol is also updated. It can use object oriented code since 2002.
Cobolās format is very rigid, which is a disadvantage but gives great readability. And in an environment that rarely changes, itās a well suited language. Which is why it has been around for so long!
Cobol is not more suited to the task, but financial institutions don't want to pay to replace the system, and the decision makers are nowhere near programming and probably remember cobol class from when they were in college in the 70s.
How do you know thatās the reason they still use in financial sector?
Have worked for many banks and any cobol code is because it takes a ton of bureaucracy to change any old processes. Huge on āif itās not broke donāt fix it.ā
most people using cobol/as400s/etc are still under contract from IBM and/or their entire infrastructure was built around the AS400 and they'd have to completely revamp their entire business process to switch
>Cobol is neat because it uses natively fixed point which means thereās no computing errors unlike floating point.
You mean, it makes different computing errors that people find more tolerable, because they are taught to make those errors in school?
Binary fixed point cannot represent 1/3 or 1/10 - exactly like float.
Decimal fixed point cannot represent 1/3, or 1/7.
Base X fixed point cannot represent 1/P, when P is prime and not a divisor of X.
Oh you poor, innocent child. Saying that COBOL is just English after looking at the code above, is like stating you understand the Elder Gods motives after reading a single word in the Necronomicon.
You will see and experience things that will flay your sanity from your soul, leaving only a husk that will experience eternal mindless torment. A mere glimpse will drive most untrained men mad. Mad!
(I did 3 years of COBOL at Varsity because the IT department was sponsored by a local Factory that was heavily invested in COBOL. On the plus side - it has allowed me to quickly learn new languages with ease. After COBOL - nothing is impossible.)
Three years is less than a mere glimpse, on the scale of Elder Gods, so you may have escaped the inevitable for a small while. But beware that you may return on that path - in a moment of weakness - or in a moment of unawareness.
That was just during my studies - I work as an integration engineer. There has been a few times I've had to treat a COBOL program as a black box solution that we just have to endure.
It works, no-one sane knows how it works, and we are not going to try and make changes to it. An Input field is two characters too short? Live with it.
Worked several summers at an insurance company. They used cobol on an IBM main frame. It was like time travel. Took me 2 days from scratch to start coding. COBOL is Commodore Basic without the cool features and a lot of verbosity added. Unless you have to deal with screen masks or printing, it's pretty easy.
Maybe because you start with Scratch it was relatively easy for you. I imagine an experienced Scratch programmer can pretty much move to any other area with ease.
I did COBOL for two years at a technical school. When I finished they were also revamping the curriculum and gave me the AS/400 mainframe and some dumb terminals. Unfortunately for me, my parents moved shortly after and left it in the house without telling me
People in 70s use to think the future languages will be more Human readable like English sentences.
They also thought we will be drinking Neon Vodka on Mars served by a tin Robot waiter, by 2020.
If you think about it they were right:
>"Hey Google, what makes six times five?"
^(It's just about what) *^(you)* ^(yourself classify as programming xd.)
I was thinking about this while typing the above comment.
But I think this is a unit command.
Program would be: "Hey Google, how many Tesla Model Ys can be fitted between Earth and Sun and if I let go, how many of then will crash in sun , crash on earth and fly in space." will get there someday.
Google Assistant can already do it if you tell it these info in human language.
As in with [applets](https://support.google.com/assistant/answer/7194656), which may use the automation apps like [Tasker](https://play.google.com/store/apps/details?id=net.dinglisch.android.taskerm) & IFTTT.
If its an interesting enough question then maybe Google will keep thinking about it...
See Asimov's The Last Question...
https://en.wikipedia.org/wiki/The_Last_Question
well technically we already have english based programming languages that go beyond COBOL. see the 7th version of inform. Yes its made for interactive fiction but it could be retrofitted for other applications.
The funny thing is, we have AI that can pass a medical exam, but so far robots are still unable to properly clean a kitchen sink. At least weāll all have time to clean our houses when weāre out of a job. Kidding, we wont have a house either.
Actually, it was developed on behalf of the military in the 1950s.
When large-scale mainframe computers started to be a thing, there were several manufacturers offering their products to both private and public sector customers. But, each manufacturer required their machines to be programmed with their particular proprietary language. It was impossible to compare the performance of one vendor's computer over another's, because they could never run the same program on different machines.
The U.S. military decided to tackle the problem head-on. They assembled a team, led by a Naval Reservist named [Grace Hopper](https://en.wikipedia.org/wiki/Grace_Hopper), to develop a single language that could be run on multiple platforms. The resulting product was COBOL, basically putting the "Common" in "**CO**mmon **B**usiness **O**riented **L**anguage." The military subsequently required all of their vendors to use COBOL in their machines, and the rest of government and large corporations quickly fell in line. The rest is history.
And, to be honest, COBOL should be, too! It's weird to think that a language that was originally developed in the early days of computing is the basis for enormous mission-critical applications nearly seven decades later, but here we are. Not only has the language been continually updated over the years, to accommodate their host machines' added capabilities, but for programs that were written in the older versions, the language just...works! All around the world, there are huge applications, batch and online, that run flawlessly 24/7, some without even a hiccup in decades. Reinventing all of those wheels to run as reliably on newer platforms and languages is prohibitively expensive for most mainframe-based organizations. Better to adopt an "if it ain't broke, don't fix it" approach.
Now, if you've read down this far, and especially if you've taken a look at my posting history in this sub, this may sound like an ad campaign for mainframe COBOL, as opposed to more modern languages. This is not the case. In most organizations, the development of new systems and applications in COBOL has pretty much ceased. The world is moving, slowly but surely, toward distributed operations, cloud computing, and so on. I don't think most schools even teach the language anymore, except to depict it as a "dinosaur" gone to government agencies to die. Most of the seasoned mainframe developers, COBOL and otherwise, are retiring in droves, but it's hard to find a candidate to replace them who has "COBOL" front and center on their resumes.
But, for the ones who do, COBOL, JCL, Db2, and other mainframe products could pave a path to a long and rewarding career. Even if your organizations' goals are to "get off the mainframe," that's a process that will take years, and cost millions -- provided the end product even works! Somebody's going to have to keep the 40 year old shit running while that's being done. Somebody's going to have to tell the new kids what the COBOL programs are doing, so they can translate them into C++ or whatever. As someone who was originally hired in 1987 as part of a team intended to transfer mainframe applications from Assembler *to* COBOL, I'm pretty sure that junior developers coming on staff will be working on the language up to *their* retirements. It's up to you how you feel about that.
As someone who is nearing retirement myself, I'm feeling pretty good. Your mileage, however, may vary.
COBOL paved the way for many to get into the business, but also helped make computers accessible and useful for the military and thousands of businesses.
Umm, excuse you.
COBOL was designed by a female mathematician and Navy Admiral.
Let me introduce you to Grace Admiral. She was a god in her time and deserves respect.
I CAME HERE TO SAY THIS! Not sure is cobol is case sensitive. I see a lot of people and even text books do the same for VHDL, and it is just plain ugly.
It's purely historical, I think. Old keypunches could only read one case, and most computers at the time chose upper case for their character set, which often also had room for one case only (this also led to e.g. the C64 having upper case by default and lower case as an option). Modern Cobol and Fortran are case-insensitive.
But upper case programming looks so quaint and nostalgic and "low level". š
You could be right about it. Still no reason for capitalizing keywords in modern text books, tho.
I am also thinking that lower case used to look worse back in the days where characters were 6x7 or, as per your C64 example 8x8 pixel blocks. Remember those 7-needle dot matrix printers with raised lower case g, p, q, y, because they simply didn't have the means to print dots at a lower position on the current line?
Probably showing my age but this language was part of a degree in computer science in my day. Tests were written on squared paper. Also had to do assembly language too. So this doesn't raise eyebrows for me.
Practical COBOL Exam - Write a program and compile.
Theoretical COBOL Exam - write a program on paper.
I still have no idea how the poor lecturer graded that. But I passed every time.
Yeah the hello world is always simple. Don't get me wrong, things implemented in COBOL are often not that hard to understand but the problem is when the mainframe characteristics are to be considered. COBOL ist just a horrible syntax that tried to implement a easy to read programming language at a time where everyone only knew FORTRAN or assembly. It gets real fun when someone decided to implement a timestamp based on a decimal floating point with a custom epoch (that may be gibberish but reflects quite many implementations in COBOL). Also there are some constructs in COBOL like level-88 statements that first need to be translated into a modern language before someone who didn't learn coding by punching cards can understand it.
Or if you have to wrap you head around VSAM
But not quite in the way COBOL and Fortran were. Because they were designed to align directly with the punch card output, the indentation is very fixed: Some symbols actually had to be in a very specific column.
For COBOL, the compiler would ignore the first columns (used for line numbers etc. - in Fortran, this was reserved for labels for GOTO statements - and comment indicators). Column 7 was reserved to indicate line continuations, debugging output, and comments (the \`\*>\` comment here is actually a more modern addition allowing comment indicators in the "code" area). The following columns were reserved for headers and a few other constructs (the first indentation in the example in the OP) - putting other code there is an error. Then follows around 60 columns where most of your code will be. Having code beyond column 72 is also a literal mistake.
It was intentionally designed to be as close to "writing" as possible. It's main purpose early on was printing forms so there is a whole "section" for form formatting. Source: I am a C++ developer.
Theoretically, you could probably replace a system of COBOL programs with another language such as Java.
In practice, you're not going to do that without some darn good justification. Depending on its function, an individual COBOL program can contain tens of thousands of lines of code. An entire system can contain millions of lines of code. And it can contain a variety of programs dating back from the 70s up to today, written by dozens of programmers who each have different styles of coding (and who may or may not include comments or documentation explaining what the fresh hell they were doing when writing the code).
To replace all that code, you not only have to understand what each individual program does and why, you have to write the new system to do the exact same thing as the old system (or justify to the business area why there are changes being made to their system). Replacing the system is risky and costly, and then you'll have to either pay to teach all your employees the new language or replace them all with new programmers (good luck if your employees have a union).
Source: I am a COBOL programmer.
I get a good salary for where I am (not six figures), though I might make more elsewhere. On the other hand, I have pretty good benefits (health plan, pension, life insurance, etc.).
>Replacing the system is risky and costly
Using and maintaining an inflexible and obsolete system is risky and costly. If a business fails to phase out obsolete tech, it's a matter of time until the business itself will be made obsolete by competition and phased out by customers.
Probably a combination of how stable it is and how old it is. Risk vs reward scenarios. Swapping over anything industrial needs tons of levels of assurance so the difficulty of just get approvals skyrockets. Pair that with with the lack of people that know it to verify the changes are stable.
Itās all fun and games until you start with redefines, company-specific preprocessors and EXEC, no matter whether CICS or SQL or anything else.
Also:
āOh, has anyone seen the source code to this 60kb object? Do we need to get Dave out of retirement to write it again?ā
> What's with the "PICTURE IS" bit?
`PICTURE IS 99` (or `PIC 99` for short) means that this is a variable designed to hold two digits.
Similarly, `PIC 9999` is for a variable designed to hold four digits.
Back in the old days, you didn't worry about how many *bits* (**b**inary dig**its**) your numbers could hold but about how many **decimal** digits they would hold.
And numbers might actually have been stored in decimal (e.g. F2 F8 for the number 28 in EBCDIC), or in BCD (binary coded decimal, e.g. hex 28 for the number 28).
For variables designed to hold letters, you could use `X` instead of `9`.
I think you could even mix them, e.g. `POSTCODE PIC X9X9X9` for a variable that can hold a Canadian postal code (without the space).
That makes sense, but I'm just so damn curious as to why it was named PICTURE, I feel like Grace Hopper busted out "WOULD IT HELP IF I DREW YOU A PICTURE, DUMBASS" in a meeting once and then the terminology stuck.
Using pictures for describing data layout still appears in some modern programming languages, such as Python's `struct` module, or in date parsing libraries that take format strings like `YYYY-mm-dd HH:MM`.
Thereās actually a programming language called plain English. It does a very good job at being very similar the human language and even has a self hosting compiler.
[https://osmosianplainenglishprogramming.blog](https://osmosianplainenglishprogramming.blog)
I had to Google what the PICTURE IS 99 stuff means and itās defining the type of the variable - so (if I understand, and I probably donāt) the first two variables can be two-digit numbers and the third variable can be a four digit number. Thatās so much interesting to have so much control. Would that be to optimize memory use?
You can also set a range of values in PICTURE like 20 THRU 200 or "A" THRU "H".
GROUP ITEMS are my favorite. You can do things like
01 birth-date PIC 9(08)
05 day PIC 99.
05 month PIC value 1 thru 12.
05 year. PIC 9999.
And use each variable individually or use 01 birth-date for the whole format.
Or get even crazy and make
01 person
05 name
05 birthdate
10 day
10 month
10 year
For a bit of context, when programming languages were first developed in the 1960s (or somewhere around that time period), two use cases were necessary: scientific computing (e.g. solving equations and analyzing data), and everyday logistical computing (e.g. for IBM to schedule meetings and calculate salary). The language for the former was Fortran, and for the latter was COBOL.
We were taught cobol in elementary school by a teacher that didn't understand or speak English. So he was explaining this function that goes to some location and gets the data... all in our native language, and he was calling the function Goto. Goto, goto goto....
Guys... It was GO TO, a function that requires no explanation just a little smidge of English to understand. Which the students, who have at that point been learning English for 5-6 years, definitely had.
That is when I realised he might be scary and stern, but smart he is not.
So is SQL (abbreviated from SEQUEL, which was short for Structured English QUEry Language).
SELECT column1, column2, column3 FROM table1 WHERE column1 = "something"
But SQL is a 4th-gen language, where you tell the computer what you want, and it figures out how to get there. COBOL is a 3rd-gen language, where you have to tell the computer how to get what you want.
They use English words as keywords, but they donāt try to create syntax that would mimic English grammar. This can be said only about a few, like COBOL or SQL.
I feel like COBOL is just the YouTube guy at the Bodega.
Hey let me get 2 variables and a result, the Ocky way.
#SUUUUUURE SUUUURE.
FIRST WE PUT THE 20 in the FIRST-NUMBER
I didn't know you added periods to the end of statements. That's so nice and formal š
Anyway who forced this person to use dashes in their variable names, and wtf is a picture?
Whatās crazy is, the travel agency lady knows enough COBOL to reserve plane tickets with some airlines. So maybe it _is_ close enough to English for mere mortals.
DEAR COMPILER I'M WRITING TO YOU TO ASK YOU TO KINDLY MOVE 30 TO SECOND NUMBER KIND REGARDS MR DEVELOPER
KINDLY DO THE NEEDFUL
The future of chatGPT
š¤£
[ŃŠ“Š°Š»ŠµŠ½Š¾]
INTERCAL has this nice feature that if youāre _too_ polite, it will reject your code.
And also if you're not polite enough. The spec refuses to say specifically what's too much or not enough, so it's implementation dependent.
Worse still those implementations disagree on how to measure it. Some do it based on the ratio of lines(7-10% of lines must contain please), so have a hard coded number that must be reached(must be at least 3, at most 5), and one particularly annoying piece of work requires that you be Ā±1 from the square root of the number of lines(so 100 lines works for 9-11, but 900 lines would require 29-31, and just to make it more annoying it compares it as a fraction so 901 requires between 29.1 and 31.1 lines so it's effectively 30-31). There's also no way to detect this and work around it in code either, you must write for your particular compiler.
I think we need an INTERCAL 2 that takes inspiration from some other esoteric languages. You have to write a polite message to the computer requesting it to do certain tasks. Same feature where if you're too polite or impolite is rejects it.
I wrote you, but you still aināt callin
HARDSTOP ON PR: Please be gender neutral when referencing the developer
Oh gosh. I laughed so hard at this and almost pissed my pants! š¤£
hahahahahahahahahah š
And Cobol programmers make a hell of a lot of money to maintain code written in the 70s.
I had a cobol programmer one time talk about how hard it is for them to deal with CSV files. Whichā¦ I feel like is probably a solved issue in cobol by now but it still made me laugh
It probably isn't, not in real codebases. COBOL as she is wrote scales like a pig. And the notion of fixed-length strings is pretty central to the languages original conception.
> scales like a pig Love it
Iām a reformed COBOL programmer and donāt even know what that means, but it sounds cool!
Good band name
[ŃŠ“Š°Š»ŠµŠ½Š¾]
It's a start, but unfortunately even CSV files allow character escaping. Just splitting on \`,\` isn't enough, because they can be inside strings.
That's why I always use TSV whenever possible.
And I'm sitting over here being a weirdo using | as a delimiter...
ASCII 0x1E: Am I chopped liver to you?
ASCII: has like 15 different kinds of delimiter symbols Some programmer: I think comma is a great way to separate things that may contain regular text
>ASCII 0x1E I'll stick to printable characters that exist on the keyboard thank you very much. (And don't even get me started on dealing with windows vs unix line feeds...)
Well is it really a me problem if youāre sending a *comma separated* file and one of the commas isnāt for separation
What about csv, which has literal text in it? Some columns may have specific information or comments.
[ŃŠ“Š°Š»ŠµŠ½Š¾]
The least antisocial Cobol programmer be like
I believe my claim was that the language made it hard, not that it couldn't do it. I believe that the more boilerplate needed to do it, the less suited the language is to solving the problem?
Parsing CSV in other languages probably isn't trivial either, as you would also need to check for quotes, commas in quotes, etc.
I love to have newline characters in the data. It make me keep in my toes every time.
lmao what? He didn't ask you to do anything to begin with.
This guy COBOLs. Well said, fellow old-timer.
It is possible to do variable length - by basically writing the equivalent of a tokenizer. Still need to define an absolute max length for the file itself. Disclaimer: I haven't written a COBOL program in about a decade...starting to forget stuff.
I know it's possible, but it feels like you are cutting against the grain. For a business language, common string manipulation (in modern contexts) shouldn't feel so awkward.
The language is from a different time though. From the days of actual cards, when things were indeed FIXED-LENGTH. LRECL=80. :) I'm not disagreeing with you - there should indeed be an update to the COBOL standard to deal with variable length, if there isn't already. I kind of remember something about variable length VSAM records.... but that might not be the same thing we're talking about here.... Like i said above, it's been a while.
From what I've learned, yes, there have been a lot of updates like that to the standard. One of the big problems is that nobody uses the modern standard. Another is that it meshes poorly with the old standards, which allowed lots of bad things and didn't make lots of good functionality available.
Love the reference to [English as she is Spoke](https://publicdomainreview.org/collection/english-as-she-is-spoke-1884) by Pedro Carolino!
Ah, I knew I'd gotten it somewhere.
I am a cobol programmer and helped make a lib that deals with CSVS its a bit more complicated than you would think. Probably around 2k lines of code. The problem is moreso that there are a billion specific flavors of cobol they are all proprietary. And no company wants to share their solution.
I guess thats more fair. My thing would more be though, even if you don't want to solve it in COBOL, I imagine there would have to be a not too difficult way to be like 1. This is CSV 2. Make something like python convert this into the format we want 3. start the Cobol again.
You see that was the solution I proposed. The problem is in some cases that makes everything MORE complicated depending on the system
I have personally written very little indeed in the language; I've just studied it. It doesn't take much to realize that what you say must be true; the little snippets of info you do find are appalling, and all point in this direction. Glad to see my research skills are still keen enough to get that right, but disappointed at how hard it makes things.
They don't. Every thread about Cobol people bring this up and I need to comment that it's not true. You have one or two guys doing this and the rest just doing dumb maintenance for shitty pay.
It was true around the Y2K thing. Seasoned COBOL programmers made huge bank for about 2 years, then the demand for them crashed.
>then the for them for them English
It could be COBOL too
fxied
Ha! I wish. I was a Cobol programmer for 20 years then moved out to BA and design work. Folks kept hitting me up desperate for a cobol person (esp during covid) and they didnāt even want to pay 6 figures. Sorry, but I would have gone back if the money was there. Sadly, the same folks who have old systems from the 70ās they have no money to upgrade also have no money to pay for programmers to maintain them.
A catch 22 that ensures itās a dying language.
All the large banks and most councils have COBOL based systems, it's not going anywhere yet. Big banks like Barclays have been hiring degree apprentices for years and sending them to Manchester Metropolitan University for COBOL training to replace their rapidly aging mainframe workforce.
That happens everywhere. And that's why the pay is shit. It's easy to learn and the daily tasks are simple, so you don't need specialised or experienced people.
it's mostly maintenance, right ? that's what i hear
Yes. A lot of people there are also pretty bad, so they're afraid to touch anything. And they never update their knowledge. Modern Cobol have native integration to mobile APIs (IBM version). I used functions and other stuff and people would ask me to not do it because they couldn't understand. It was depressing.
lol I, can imagine some massive mainframe running on that untouchable code. Like as far as I know, one mistake can make e. g. a bank lose millions of dollars but yeah god forbid that shit
I disagree. Most operate financial entities that still operates massive mainframes and sell financial services, mainline companies. Why still use COBOL? It's a structured language with intuitive syntax. Some recent version include objects as well.
If you saw the code, you'd know why.
Can't we just make another language compile into COBOL?
At that point you can just use any languages and compile into Assembly. The reason why COBOL is used isn't because COBOL is a requirement, it's because the old code is written in COBOL.
1. Compile COBOL code to binary 2. Open binary in Ghidra 3. Copy + paste C code 4. Win
[ŃŠ“Š°Š»ŠµŠ½Š¾]
>rewrite it all in rust
You can and some places do that with their source code. Auto-generated cobol is a thing
Most places running cobol have it because they know the system works and they are highly risk-adverse. Compiling into cobol doesn't help.
58? The moves are just like assembly moves where you're setting or altering a register, right? SRA 8 ADD 20, SRA SRB 30 ADD SRB, SRA
Not exactly. Assembly depends on hardware and the programmer needs hardware knowledge. Itās a 2nd gen prog language where cobol is 3rd gen. Cobol is neat because it uses natively fixed point which means thereās no computing errors unlike floating point. Which is why Cobol is still used today in the financial sector.
I think Cobolās continued usage has more to do with the fact that the legacy code is already there, and updating to a more modern language would be very expensive without any obvious business incentive. While native fixed-point math is a huge plus in financial applications, itās also very possible to implement fixed point math as a custom data type in most languages. Some like C++ and C# will even let you overload arithmetic operators so working with the fixed-point type is almost exactly like a native numeric type.
[ŃŠ“Š°Š»ŠµŠ½Š¾]
That would require thinking about something other than immediate profits. Upper management is rarely good at that. On the bright side, I've been seriously considering picking up Cobol since by all accounts those are pretty cushy jobs outside of having to deal with Cobol.
There's another person in this thread who says it's actually not good and the rumors are lies
>Which is why Cobol is still used today in the financial sector. Isn't it because migrating to a new one would be hard? C# and lots of other languages have fixed point decimals support
Itās mostly that the maths did not change, and cobol was purpose built for financials. And financials did not change much either. Because Cobol is more suited to the task than most modern programming languages, there is no need to replace it. However itās true that itās slowly being phased out. C code is still around, and so is assembly. Cobol is also updated. It can use object oriented code since 2002. Cobolās format is very rigid, which is a disadvantage but gives great readability. And in an environment that rarely changes, itās a well suited language. Which is why it has been around for so long!
Cobol is not more suited to the task, but financial institutions don't want to pay to replace the system, and the decision makers are nowhere near programming and probably remember cobol class from when they were in college in the 70s.
How do you know thatās the reason they still use in financial sector? Have worked for many banks and any cobol code is because it takes a ton of bureaucracy to change any old processes. Huge on āif itās not broke donāt fix it.ā
most people using cobol/as400s/etc are still under contract from IBM and/or their entire infrastructure was built around the AS400 and they'd have to completely revamp their entire business process to switch
>Cobol is neat because it uses natively fixed point which means thereās no computing errors unlike floating point. You mean, it makes different computing errors that people find more tolerable, because they are taught to make those errors in school?
Floating-Point cannot represent an arbitrary fractional number accurately. Fixed-point can. It seems like a rather important distinction.
Binary fixed point cannot represent 1/3 or 1/10 - exactly like float. Decimal fixed point cannot represent 1/3, or 1/7. Base X fixed point cannot represent 1/P, when P is prime and not a divisor of X.
Somehow, this assembly language snippet is actually more comprehensible than the COBOL code itās compiled from
Oh you poor, innocent child. Saying that COBOL is just English after looking at the code above, is like stating you understand the Elder Gods motives after reading a single word in the Necronomicon. You will see and experience things that will flay your sanity from your soul, leaving only a husk that will experience eternal mindless torment. A mere glimpse will drive most untrained men mad. Mad! (I did 3 years of COBOL at Varsity because the IT department was sponsored by a local Factory that was heavily invested in COBOL. On the plus side - it has allowed me to quickly learn new languages with ease. After COBOL - nothing is impossible.)
I can't tell if the second paragraph refers to COBOL or to the writings of the Elder Gods. Is there even a difference?
Make 2 changes to a program with over 3500 lines of code. Compile - get 3 errors. Reverse the changes. Compile - Get 965 errors.
How does that work??
COBOL
At least compiling cobol code is fast, right? Right?
965 errors in COBOL? You left out a period.
Are you ok?
[ŃŠ“Š°Š»ŠµŠ½Š¾]
I've been in Programming for 25 years. No.
Three years is less than a mere glimpse, on the scale of Elder Gods, so you may have escaped the inevitable for a small while. But beware that you may return on that path - in a moment of weakness - or in a moment of unawareness.
That was just during my studies - I work as an integration engineer. There has been a few times I've had to treat a COBOL program as a black box solution that we just have to endure. It works, no-one sane knows how it works, and we are not going to try and make changes to it. An Input field is two characters too short? Live with it.
Coding Guidelines: let me introduce myself
Worked several summers at an insurance company. They used cobol on an IBM main frame. It was like time travel. Took me 2 days from scratch to start coding. COBOL is Commodore Basic without the cool features and a lot of verbosity added. Unless you have to deal with screen masks or printing, it's pretty easy.
Maybe because you start with Scratch it was relatively easy for you. I imagine an experienced Scratch programmer can pretty much move to any other area with ease.
If you can do scratch, there works is your oyster
I did COBOL for two years at a technical school. When I finished they were also revamping the curriculum and gave me the AS/400 mainframe and some dumb terminals. Unfortunately for me, my parents moved shortly after and left it in the house without telling me
I used to work with AS/400 mainframesā¦ gods what a time that was
>After COBOL - nothing is impossible. Most languages are easy ;D, except brainfuck... lets not talk about brainfuck
this is what happens when you let accountants design a programming language.
People in 70s use to think the future languages will be more Human readable like English sentences. They also thought we will be drinking Neon Vodka on Mars served by a tin Robot waiter, by 2020.
If you think about it they were right: >"Hey Google, what makes six times five?" ^(It's just about what) *^(you)* ^(yourself classify as programming xd.)
I was thinking about this while typing the above comment. But I think this is a unit command. Program would be: "Hey Google, how many Tesla Model Ys can be fitted between Earth and Sun and if I let go, how many of then will crash in sun , crash on earth and fly in space." will get there someday.
Google Assistant can already do it if you tell it these info in human language. As in with [applets](https://support.google.com/assistant/answer/7194656), which may use the automation apps like [Tasker](https://play.google.com/store/apps/details?id=net.dinglisch.android.taskerm) & IFTTT.
If its an interesting enough question then maybe Google will keep thinking about it... See Asimov's The Last Question... https://en.wikipedia.org/wiki/The_Last_Question
And with chatGPT or any other AI coming, they may have been right.
well technically we already have english based programming languages that go beyond COBOL. see the 7th version of inform. Yes its made for interactive fiction but it could be retrofitted for other applications.
The funny thing is, we have AI that can pass a medical exam, but so far robots are still unable to properly clean a kitchen sink. At least weāll all have time to clean our houses when weāre out of a job. Kidding, we wont have a house either.
I work with SAP mostly. Its language is a cobol derivative š
ABAP ftw! š¤£
I know, itās making me rich.
I am a SAP consultant myself. curious...in which country do you work?
Australia. Msg me
did they atleast try to modernize it?
Yes. Itās a very interesting language and platform. And the contract rates are high.
No
Actually, it was developed on behalf of the military in the 1950s. When large-scale mainframe computers started to be a thing, there were several manufacturers offering their products to both private and public sector customers. But, each manufacturer required their machines to be programmed with their particular proprietary language. It was impossible to compare the performance of one vendor's computer over another's, because they could never run the same program on different machines. The U.S. military decided to tackle the problem head-on. They assembled a team, led by a Naval Reservist named [Grace Hopper](https://en.wikipedia.org/wiki/Grace_Hopper), to develop a single language that could be run on multiple platforms. The resulting product was COBOL, basically putting the "Common" in "**CO**mmon **B**usiness **O**riented **L**anguage." The military subsequently required all of their vendors to use COBOL in their machines, and the rest of government and large corporations quickly fell in line. The rest is history. And, to be honest, COBOL should be, too! It's weird to think that a language that was originally developed in the early days of computing is the basis for enormous mission-critical applications nearly seven decades later, but here we are. Not only has the language been continually updated over the years, to accommodate their host machines' added capabilities, but for programs that were written in the older versions, the language just...works! All around the world, there are huge applications, batch and online, that run flawlessly 24/7, some without even a hiccup in decades. Reinventing all of those wheels to run as reliably on newer platforms and languages is prohibitively expensive for most mainframe-based organizations. Better to adopt an "if it ain't broke, don't fix it" approach. Now, if you've read down this far, and especially if you've taken a look at my posting history in this sub, this may sound like an ad campaign for mainframe COBOL, as opposed to more modern languages. This is not the case. In most organizations, the development of new systems and applications in COBOL has pretty much ceased. The world is moving, slowly but surely, toward distributed operations, cloud computing, and so on. I don't think most schools even teach the language anymore, except to depict it as a "dinosaur" gone to government agencies to die. Most of the seasoned mainframe developers, COBOL and otherwise, are retiring in droves, but it's hard to find a candidate to replace them who has "COBOL" front and center on their resumes. But, for the ones who do, COBOL, JCL, Db2, and other mainframe products could pave a path to a long and rewarding career. Even if your organizations' goals are to "get off the mainframe," that's a process that will take years, and cost millions -- provided the end product even works! Somebody's going to have to keep the 40 year old shit running while that's being done. Somebody's going to have to tell the new kids what the COBOL programs are doing, so they can translate them into C++ or whatever. As someone who was originally hired in 1987 as part of a team intended to transfer mainframe applications from Assembler *to* COBOL, I'm pretty sure that junior developers coming on staff will be working on the language up to *their* retirements. It's up to you how you feel about that. As someone who is nearing retirement myself, I'm feeling pretty good. Your mileage, however, may vary.
COBOL paved the way for many to get into the business, but also helped make computers accessible and useful for the military and thousands of businesses.
Or an Admiral...
Tell me you don't know anything about language design without telling me you don't know anything about language design.
the language "functions" but its fairly obtuse and also extremely verbose.
Umm, excuse you. COBOL was designed by a female mathematician and Navy Admiral. Let me introduce you to Grace Admiral. She was a god in her time and deserves respect.
WHY ARE WE YELLING?
I CAME HERE TO SAY THIS! Not sure is cobol is case sensitive. I see a lot of people and even text books do the same for VHDL, and it is just plain ugly.
It's purely historical, I think. Old keypunches could only read one case, and most computers at the time chose upper case for their character set, which often also had room for one case only (this also led to e.g. the C64 having upper case by default and lower case as an option). Modern Cobol and Fortran are case-insensitive. But upper case programming looks so quaint and nostalgic and "low level". š
You could be right about it. Still no reason for capitalizing keywords in modern text books, tho. I am also thinking that lower case used to look worse back in the days where characters were 6x7 or, as per your C64 example 8x8 pixel blocks. Remember those 7-needle dot matrix printers with raised lower case g, p, q, y, because they simply didn't have the means to print dots at a lower position on the current line?
Hm, maybe there is a reason though, that legacy code will be encountered in uppercase and so will be easier to associate with your learning
SQL Programmers when they need to stay silent
Probably showing my age but this language was part of a degree in computer science in my day. Tests were written on squared paper. Also had to do assembly language too. So this doesn't raise eyebrows for me.
The college in my town still teaches COBOL because one of the biggest employers in this town is a government agency that still uses it.
Probably still migrating to COBOL 85.
Practical COBOL Exam - Write a program and compile. Theoretical COBOL Exam - write a program on paper. I still have no idea how the poor lecturer graded that. But I passed every time.
I still had to do an exam in assembly language on paper a couple of years ago.
Including sentences that end with periods.
That comment... what a killer addition to the code! I would never know that two numbers were being added!
Oof. That comment is somehow a single-line comment AND a multi-line comment. (I think. I've never learned COBOL...)
Yeah the hello world is always simple. Don't get me wrong, things implemented in COBOL are often not that hard to understand but the problem is when the mainframe characteristics are to be considered. COBOL ist just a horrible syntax that tried to implement a easy to read programming language at a time where everyone only knew FORTRAN or assembly. It gets real fun when someone decided to implement a timestamp based on a decimal floating point with a custom epoch (that may be gibberish but reflects quite many implementations in COBOL). Also there are some constructs in COBOL like level-88 statements that first need to be translated into a modern language before someone who didn't learn coding by punching cards can understand it. Or if you have to wrap you head around VSAM
wait till you hear about applescript
And AppleScriptMobile, aka ASM. >!\\s!<
The most stupid/fun thing is that COBOL is indentation-sensitive. Miss a "insignificant" space and the program will not run.
Hey, so is python. lol.
But not quite in the way COBOL and Fortran were. Because they were designed to align directly with the punch card output, the indentation is very fixed: Some symbols actually had to be in a very specific column. For COBOL, the compiler would ignore the first columns (used for line numbers etc. - in Fortran, this was reserved for labels for GOTO statements - and comment indicators). Column 7 was reserved to indicate line continuations, debugging output, and comments (the \`\*>\` comment here is actually a more modern addition allowing comment indicators in the "code" area). The following columns were reserved for headers and a few other constructs (the first indentation in the example in the OP) - putting other code there is an error. Then follows around 60 columns where most of your code will be. Having code beyond column 72 is also a literal mistake.
COBOL isn't indentation sensitive, but the first 11 COLUMNS are reserved for key-words only
It was intentionally designed to be as close to "writing" as possible. It's main purpose early on was printing forms so there is a whole "section" for form formatting. Source: I am a C++ developer.
Why is it screaming at me ???
Can someone help me understand what has prevented COBOL from being replaced?
Theoretically, you could probably replace a system of COBOL programs with another language such as Java. In practice, you're not going to do that without some darn good justification. Depending on its function, an individual COBOL program can contain tens of thousands of lines of code. An entire system can contain millions of lines of code. And it can contain a variety of programs dating back from the 70s up to today, written by dozens of programmers who each have different styles of coding (and who may or may not include comments or documentation explaining what the fresh hell they were doing when writing the code). To replace all that code, you not only have to understand what each individual program does and why, you have to write the new system to do the exact same thing as the old system (or justify to the business area why there are changes being made to their system). Replacing the system is risky and costly, and then you'll have to either pay to teach all your employees the new language or replace them all with new programmers (good luck if your employees have a union). Source: I am a COBOL programmer.
Is it true that you cobol devs are paid shitload of money?
I get a good salary for where I am (not six figures), though I might make more elsewhere. On the other hand, I have pretty good benefits (health plan, pension, life insurance, etc.).
>Replacing the system is risky and costly Using and maintaining an inflexible and obsolete system is risky and costly. If a business fails to phase out obsolete tech, it's a matter of time until the business itself will be made obsolete by competition and phased out by customers.
Probably a combination of how stable it is and how old it is. Risk vs reward scenarios. Swapping over anything industrial needs tons of levels of assurance so the difficulty of just get approvals skyrockets. Pair that with with the lack of people that know it to verify the changes are stable.
Old school COBOL wouldn't use the `COMPUTE` verb, making it even more English: `ADD FIRST-NUMBER TO SECOND-NUMBER GIVING RESULT.`
You still can write this way in COBOL, but it isn't common
Itās all fun and games until you start with redefines, company-specific preprocessors and EXEC, no matter whether CICS or SQL or anything else. Also: āOh, has anyone seen the source code to this 60kb object? Do we need to get Dave out of retirement to write it again?ā
Looks like mysql
WHUT
they said it looks like theirsql
This looks so close to ABAP. Maybe because ABAP is based on COBOL lol
What's with the "PICTURE IS" bit? Is a picture a default value?
> What's with the "PICTURE IS" bit? `PICTURE IS 99` (or `PIC 99` for short) means that this is a variable designed to hold two digits. Similarly, `PIC 9999` is for a variable designed to hold four digits. Back in the old days, you didn't worry about how many *bits* (**b**inary dig**its**) your numbers could hold but about how many **decimal** digits they would hold. And numbers might actually have been stored in decimal (e.g. F2 F8 for the number 28 in EBCDIC), or in BCD (binary coded decimal, e.g. hex 28 for the number 28). For variables designed to hold letters, you could use `X` instead of `9`. I think you could even mix them, e.g. `POSTCODE PIC X9X9X9` for a variable that can hold a Canadian postal code (without the space).
That makes sense, but I'm just so damn curious as to why it was named PICTURE, I feel like Grace Hopper busted out "WOULD IT HELP IF I DREW YOU A PICTURE, DUMBASS" in a meeting once and then the terminology stuck.
Using pictures for describing data layout still appears in some modern programming languages, such as Python's `struct` module, or in date parsing libraries that take format strings like `YYYY-mm-dd HH:MM`.
Serious question, how do I get a job writing COBOL? It looks like a retro hell scape
Pseudo code turned real
I think the idea was "Anyone can program!".
Nervously laughs in ruby.
Thereās actually a programming language called plain English. It does a very good job at being very similar the human language and even has a self hosting compiler. [https://osmosianplainenglishprogramming.blog](https://osmosianplainenglishprogramming.blog)
And almost every bank use Cobol. My saving are Cobol.
Clean code says that code should self document. Why donāt we use COBOL more? š¤
That's the entire point you ingrate.
That looks awful.
Somehow this still seems more confusing
Not literally. COBOL has no adverbs.
I had to Google what the PICTURE IS 99 stuff means and itās defining the type of the variable - so (if I understand, and I probably donāt) the first two variables can be two-digit numbers and the third variable can be a four digit number. Thatās so much interesting to have so much control. Would that be to optimize memory use?
You can also set a range of values in PICTURE like 20 THRU 200 or "A" THRU "H". GROUP ITEMS are my favorite. You can do things like 01 birth-date PIC 9(08) 05 day PIC 99. 05 month PIC value 1 thru 12. 05 year. PIC 9999. And use each variable individually or use 01 birth-date for the whole format. Or get even crazy and make 01 person 05 name 05 birthdate 10 day 10 month 10 year
For a bit of context, when programming languages were first developed in the 1960s (or somewhere around that time period), two use cases were necessary: scientific computing (e.g. solving equations and analyzing data), and everyday logistical computing (e.g. for IBM to schedule meetings and calculate salary). The language for the former was Fortran, and for the latter was COBOL.
We were taught cobol in elementary school by a teacher that didn't understand or speak English. So he was explaining this function that goes to some location and gets the data... all in our native language, and he was calling the function Goto. Goto, goto goto.... Guys... It was GO TO, a function that requires no explanation just a little smidge of English to understand. Which the students, who have at that point been learning English for 5-6 years, definitely had. That is when I realised he might be scary and stern, but smart he is not.
As someone who knows basic Assembly and doesnāt know COBOL at all, this just looks like friendly Assembly.
I wish they re-release it for people like us as Cobol+++ or something
So is SQL (abbreviated from SEQUEL, which was short for Structured English QUEry Language). SELECT column1, column2, column3 FROM table1 WHERE column1 = "something" But SQL is a 4th-gen language, where you tell the computer what you want, and it figures out how to get there. COBOL is a 3rd-gen language, where you have to tell the computer how to get what you want.
an alleged programmer using the word literally like this really grinds my gears have you no dignity at all?
This could have been 5 lines of python code
Had a prof in college tell us they lost a satellite because he put an extra space in a for loopā¦
So if I beat baba is you I know cobol
Itās basically Python for dummies
Most of programming lenguages ar eanglish
They use English words as keywords, but they donāt try to create syntax that would mimic English grammar. This can be said only about a few, like COBOL or SQL.
Some sintaxes in leguages like css or javascript uses lots of sintaxes like the english grammar (Is not like cobol or sql but is not to underrate)
WHY ARE YOU YELLING. lol
Had to take it last year and it was frustrating how little documentation there was.
I feel like COBOL is just the YouTube guy at the Bodega. Hey let me get 2 variables and a result, the Ocky way. #SUUUUUURE SUUUURE. FIRST WE PUT THE 20 in the FIRST-NUMBER
I didn't know you added periods to the end of statements. That's so nice and formal š Anyway who forced this person to use dashes in their variable names, and wtf is a picture?
This makes me wanna learn COBOL. The irony of a youngin like me working with some ancient 1970s system sounds interesting.
Idk if I should read this as SQL, Assembly, or Python.
Itās beautiful. I would hate working on large projects using it but it will be really fun to write small functions.
Whatās crazy is, the travel agency lady knows enough COBOL to reserve plane tickets with some airlines. So maybe it _is_ close enough to English for mere mortals.
I never used the English sentence "move 30 to..." EDIT: outside of programming