9 ms·
COBOL’s youth culture
- sitzkrieg 4y agoi like cobol, i would enjoy pivoting into maintaining it
- vanderZwan 4y agoDoes anyone else ever wonder if the bus factor of the economies of some countries equals the number of cobol programmers that keep the biggest banks and similar institutions running? Probably (hopefully) that's a bit of an exaggeration but still
- derekbaker783 4y agoCan confirm this is the case at the some very large American companies.
- ElevenLathe 4y agoPresumably if trillions were literally on the line, a bank could buy some extremely highly-paid consultants who have been training for exactly this situation precisely so that they can get massively well-paid in just this scenario. Probably some kind of special ops unit inside Capgemini.
- vanderZwan 4y agoEh, that might mitigate some of the damage, but the older the system, the more quirks and workarounds there are that are not documented anywhere and for which the required knowledge only exist in the minds of the current programming team. I don't see how any team of consultants can protect against that in a case of emergencies.
- raverbashing 4y agoI wonder if the banks are getting cold feet and pushing PR articles about how "kids this days" should get off their behinds and learn COBOL because "someone needs to work on this mess and we can't find anyone" Yeah, no thanks.
- nix23 4y agoWhy not? Good salary, no stress, nearly never deadlines, working with massive mainframes, no hw failures, no OS failures, and in bank/insurance pretty good bonuse's...but hey maybe you like systems like borg/kubernetes where everything is build on cheap stuff and your deployment is like a babylonian tower build on unstable ground.
- raverbashing 4y agoI leave the propaganda to those who believe in it > working with massive mainframes This is the kind of vapid marketing nugget that doesn't impress anyone that doesn't suffer from oxygen deprivation due to neck decorations. Why in tarnation should I care for overpriced obsolete technology? Do you see Google or FB investing in this? No? Ok then > where everything is build on cheap stuff pulled straight out of the IBM sales book I see I won't touch anything that came out of those 3 letters
- deleted 4y ago[deleted]
- nix23 4y ago>Do you see Google or FB investing in this? No? Ok then As if AD-Company's are any measurement for innovation, you could have said Oxide or hell even Amazon...but NOOO you take the lamest two Firm's out of the "FAANG"-Gang. You obviously never worked with mainframes....that's sad.
- sophacles 4y agoThis strikes me as just as much propaganda. I mean if it's so obsolete, why are "modern" server manufacturers still touting new features that have been in the IBM mainframes for decades?
- AlbertoGP 4y agoThis part sounds alluring to me: > “It does exactly what you tell it to do on a line [of code],” explains Stuart. ”Sometimes you get files that are 2,000 lines long, but they’re easy to understand because they simply do what they say they’re doing at that line.” I don’t think COBOL is a good match for the programs I write in my spare time, but as a job it sounds nice. I guess the main problem if I were to find a job doing it would be the corporate culture at the kinds of companies that use it, but if I could do it remotely using my own workstation with any tools I choose I would do it.
- sweezyjeezy 4y agoSorry to be dense, but what does that actually mean, relative to a modern programming language?
- sclangdon 4y agoThings such as function overloading, operator overloading, dynamic dispatch, etc, are all conveinient but also obscure what is actually happening. To take C++ as an example (I love C++ btw, this isn't another C++ bashing), a line as simple as "variable1 = variable2;", could be doing all kinds of things (including not even assigning) because of the ability to overload the asignment operator. As someone reading this line of code for the first time, you don't really know for sure what is actually happening unless you also go and read the code for "=".
- pdw 4y agoThough COBOL infamously has the ALTER statement, which allows you to rewrite code at run time ;)
- valenterry 4y ago> DNA is really simple. It just consists of small parts that are being used in a chemical reaction. It's very simple to understand the chemical reaction because it's only based on four chemical bases. Sometimes DNA is really long, but it's easy to understand what it does because it simply does what each of its parts does. I guess it's easy to see the difference between "easy to read a line" and "easy to understand a whole program" now?
- worthless-trash 4y agoI've recently started messing with a little cobol, the "display/accept" screen creation is really quite a nice method of developing a TUI. It can be made amazingly quickly and changed quicker than most apps (See https://wmealing.github.io/simple-cobol-query.html https://wmealing.github.io/simple-cobol-query.html for example). The GNUcobol implementation doesn't seem to support UTF-8 characters, that'd be awesome if it did, preventing even more awesome "screen/accept" input screens. My big beef that I have with the language is that there is third party "extensions" built right into the language, which is very frustrating when trying to understand as a new user.
- BasiliusCarver 4y agoNicely presented. It’s fun but the new-user learning curve is definitely frustrating (especially because most of the documentation is super dry). I ended up with this after a while of playing with the language https://github.com/ShaunLawrie/TicTacTOBOL https://github.com/ShaunLawrie/TicTacTOBOL
- digitalsankhara 4y agoVery good. I've never had to use COBOL in anger in my career. I do have fond memories of a little DBASE work and building TUI screens that bind to data/procedures was really easy and productive. Geez, I wish it was as easy to build web apps the same way.
- mikewarot 4y agoIn the MS-DOS days, I once wrote a CRUD in Turbo Pascal that was part of an inspection tracking system. To make it easier on myself, I stole an idea from dBase (the PC program, not the huge IBM Mainframe thing) and wrote myself a library that did screen editing fields in much the same way. It's a good idea with wide applicability.
- tdeck 4y agoThe terminals originally used on these IBM mainframes were interesting too. Their hardware protocol let you define an entire screen with multiple input fields and would handle accepting all the input in those regions, buffering it all until you submitted the screen. It's very different from the line-oriented and character-oriented terminals we're used to in the UNIX/DOS world. https://en.wikipedia.org/wiki/IBM_3270 https://en.wikipedia.org/wiki/IBM_3270
- MichaelMoser123 4y agoWhat are the chances that COBOL jobs will be outsourced to low cost countries?
- Cthulhu_ 4y agoI'm confident they already are.
- dachryn 4y agothey already are, but actually most COBOL stuff is pretty safe as far as job security goes. As with anything, its not about the programming language, its about the business context. COBOL outsourcing means having great documentation so they know what the fuck is actually going on in the codebase. Also, COBOL has less boilerplate than for example java. The boilerplate is not standardized and usually unique to each company, again highering the difficulty to outsource everything offshore. Most succesfull approach seems to be to import 10 indian guys on premise, and have them work along your existing team. Dont underestimate the effectiveness of a 59 year old cobol programmer who knows the program in and out, and knows exactly where to adapt something without breaking anything else. There are no dependency checks, linters or unit testing for most of these programs. You basically want 5 newbies working alongside one of these senior level programmers for a year or 2 before you confidently can let them retire.
- mellavora 4y agoAlso don't underestimate the potential damage of NOT having that 59 year old programmer. talk to some people who work in banks, they have stories which could make your toes curl.
- ngcc_hk 4y agoSometimes the user promote elsewhere and after a decade the only guy or ladies know what is going on is the IT lot. Have to advise them what to do, what not to and what is possible. They Ss try their new thing. Just break the system. The only way out is to redo the whole system sometimes. It is not ease.
- sclangdon 4y agoMy first job was as a COBOL programmer on an IBM mainframe (OS/370 I believe) for Xerox. The system was absolutely massive and incredibly difficult to navigate. There were thousands of files with names that only had 6 characters. So everything was a two-letter system code, followed by four digits. LP0456, OP0234, SB1245, etc. Then, in each of those files the variables had similar names in order to cut down on unique identifiers. WP100, WP101, up to the max number you needed at any given time. It was a nightmare. There was as much external documentation to keep track of all of this stuff as there was code. On top of that, you could only build programs overnight in a batch process with the rest of the system, which was run by a different team in a different country (Spain, I believe). So you would write your program in the day, phone up the guys in Spain and explain that there was a new program going in and you were responsible for it. Problem was, if your program failed to build it would hold up the whole system, which HAD to be up and running and live again by the morning. This meant that every time you made a change that went into the nightly build you also had to be on call. I remember eagerly watching the build queue at 1AM, waiting for my file's turn. Then immediately shutting everything down and going to sleep the moment it was successful. If it wasn't successful, well, then you had to fix it on the spot and phone Spain again to tell them to give it another try. Unfortunately, you rarely knew why it was failing.
- CodeSgt 4y agoGood God that's awful lol. Say what you will about the state of software development today but at least we aren't there lmao
- dewey 4y agoI shall never complain about resolving merge conflicts or dependency issues ever again.
- univacky 4y agoFilenames? We used to DREAM of having filenames! Writing COBOL on the UNIVAC 490 series (30 bit word, FIELDATA character set), our files were on tapes. A tape request was submitted to the tape library, they would pull the tape(s) containing your file(s), and deliver them to the operations floor. The customer would submit hand-written transactions, which would be sent to the keypunchers, who would punch them onto cards. The tapes and transaction cards would be sent to the ops floor (where there was the actual computer). The operator would load the first tape in each file onto a UNISERVO tape drive, and go to the patch panel to run wires to assign logical devices to physical devices. ( https://www.computerhistory.org/collections/catalog/102666865 https://www.computerhistory.org/collections/catalog/10266686... see page 57) Then they would put the job deck into the card reader and enter the "UR" (read the Unit Record device) command into the console, which had a spool of paper, not a screen. When the program was awaiting input, they would load the transaction cards and give the console command to continue the program. We did have a fearsome beast of a FASTRAND drum system for random-access storage, but that was just for executable code and temporary files. Then you might well get called in the middle of the night, because one of the programs in the job aborted. They called it "aborted" then. Or ABEND (ABnormal END), if you were an IBM person. You would come in, read the core dump (reading core dumps was a valuable skill), and determine that there was a data problem in a transaction (e.g. an alpha character in a numeric field). You would find the offending card, pull it, tear it in half and set it aside to be addressed in the morning as a missing transaction, and tell ops to rerun the job. With luck, there were no bad cards after that one. Tell that to kids today, and they won't believe you.
- cntlzw 4y ago> “Logic doesn't deteriorate,” said Bob England, a COBOL developer and president of England Technical Services. “Until the business rules change, that code is as good as the day it was born.” True, but the business context always changes. I doubt most of the payroll logic from 50 years ago is still in use today. Therefore someone needs to write new code, or change the old code. > Many COBOL applications are large; rewriting them isn’t cost-effective—or even necessary. Yes, your IBM sales rep makes sure of it.
- mellavora 4y ago> True, but the business context always changes. What about the regulatory context? I'm thinking of banks, for example.
- raverbashing 4y ago> What about the regulatory context? It's probably even worse
- alex-nt 4y agoRegulatory changes in banks kept accelerating in the last 50Y and I see no reason this will stop. It is harder and harder for them to keep up. Reasons for this are: * Banks still have very old codebases and changing anything is fear inducing for everyone (automated testing is a new things for a lot of teams) * Banks control very little of their core software. They have a lot of vendors for the same thing. You will see multiple vendors delivering basically the same thing in different parts of the bank, and at the same time multiple versions of those vendor applications in diferent parts of the bank. Integrating this is a nightmare (it can take more than 1Y to move a tag in a XML). * IT is still mostly used for marketing purposes in banks, it's not a way of doing things. The design/integration is mostly discussed/designed by functional people. They are great, but it does happen that they don't see the full implications of their choices till it is too late. Also, because this is a design 'from above' changing anything takes a lot longer. For any change you have to convince a lot more people till you get to the actual person that will have to do it. * A lot more complicated management reasons. Nobody wants to take a hit on a new IT project, and few people have the IT & banking knowledge to move such a project (why would you? they pay is average). You cannot progress with just one of them. Places where these projects happen is mostly close to pricing/trading as those are seen as profit centers and the bank is more willing to fail a few times till it can build something decent. As you get closer to the guts of the bank things get more and more...problematic. Edit: I had to add this. Central banks are also bad at IT, they do not set an example worth following. I consider this the main reason why all our interactions with banks are less than ideal online.
- HeckFeck 4y agohttps://github.com/azac/cobol-on-wheelchair https://github.com/azac/cobol-on-wheelchair I need to share this in all its glory. There is a working COBOL web framework. "Still got it!" it croaked from the corner.
- bhedgeoser 4y agohttps://www.youtube.com/watch?v=nCPfJxSxZQk&ab_channel=Dan https://www.youtube.com/watch?v=nCPfJxSxZQk&ab_channel=Dan
- Hardwired8976 4y agoYeah I am doing an apprenticeship at a large bank currently (20 Years old) and I am learning Cobol.
- tomcam 4y agoWait don’t leave us hanging. What dialect? What OS, IDE, brand of COBOL, and learning resources are you getting? Also AFAIK you also need to know lots of environment specific things like job control languages?
- Hardwired8976 4y agoSure, I would like to reply to all but sadly we haven't moved to the host yet and are just developing on Windows machines using an old Cobol Compiler (1974 dialect). The host system uses COBOL 1985 as far as I know and runs on the newest IBM hardware. Learning resources: A script our teacher wrote and his exercises and one big IBM book as well as one German "Cobol insiders" book that is not available anymore. As far as environment specific things: We have guidelines for our code of course but I am not aware of job control languages. But like I said, we aren't on the host system yet.
- tomcam 4y agoThanks for sharing and good luck. Hoping you’ll update us after you move to the new system.
- jmclnx 4y agoAn instructor I had many years ago said, doing "boring like COBOL pretty much ensures good Job Security". For me turned out true, I never had job security worries. And I was able to branch out to other things, thus was able to program in many environments. And working on old tech can still be fun. Wish you luck going forward
- Hardwired8976 4y agoYeah my apprenticeship is kinda special as I am essentially guaranteed a job afterwards, which you can‘t say for every apprenticeship.
- deleted 4y ago[deleted]
- ontouchstart 4y agoFollow the article and some Googling, I found this VSCode extension. Idea like this might help people (and AI?) read, analyze and build some automation on old COBOL code with modern tool chains. https://marketplace.visualstudio.com/items?itemName=Micro-Focus-AMC.mfcobol https://marketplace.visualstudio.com/items?itemName=Micro-Fo...
- rbanffy 4y agoThere's also the Zowe family (which are tied to IBM mainframes, but a lot of COBOL code runs on them)
- ontouchstart 4y agoThanks for the info. It is very interesting https://github.com/zowe/vscode-extension-for-zowe https://github.com/zowe/vscode-extension-for-zowe
- implements 4y agoNot a computer scientist, but surely COBOL could be machine translated to another more modern language - or even a dialect of a modern language specifically created to make such a translation verifiably correct?
- bregma 4y agoWhy? OK, sure, Shakespeare is better when it's been rewritten into modern hip hop rhymes and reinterpreted through lyrical dance but what's the advantage of rewriting something that's working and workable in some other form just because that form is not old?
- kryptiskt 4y agoSure, there are such translators on the market. The problem is that if you translate COBOL to Java which is the most likely target, you won't end up with any nice OO abstractions but a ton of Java code that looks just like transliterated COBOL.
- andylynch 4y agoThere are tools in the market to do this kind of thing, eg to Java. But the typical problem is that you then have a non-idiomatic code base and it’s harder to maintain and operate than the original. So unless it’s an intermediate step on a much larger and more expensive project to replace the whole system it’s too risky for benefit.
- Spooky23 4y agoCOBOL was designed for financial analysts, accountants, etc to computerize analog processes. They took it literally sometimes. My favorite example of this was a data entry routine that was insane - and lifted to a web interface circa 2004. “Turns out” when processing paper, several key transactions filtered through a gentleman, long since passed, who lost an arm in Korea. When paperwork was received, they were arranged and stapled in a way that accommodated his mobility limitations. Every COBOL code base has stories like that, and there’s no functions or modern metaphors as it’s procedural. So your opportunities for code translation are really scoped to things that you can make a “black box”, never to be touched again. Remember too this is shitty, unsexy, non-portable work. Top talent started looking elsewhere in the 90s, and often you’re left with a couple of people who understand how stuff works, then mostly folks who value stability over all else. Companies tend to pay for shiny skills, and the folks who really understand their business get second fiddle.
- hyperman1 4y agoThis reeks as PR for some ancient companies desperate enough to please please PLEASE find someone to keep their unholy mess alive. I've seen the COBOL world, and it wasn't pretty. Each line on its own is indeed simple. But you have a few thousands or ten thousands of them in 1 transaction or batch process. And that batch process is just 1 in a long chain of batch processes. So you'll need to get a grip on 10-100K lines before you understand the whole process. Procedures are easily 1000 lines long, and any line in there can undo any other line if someone from 30 years ago did not find another way to fix a bug. There is no abstraction, so code duplication is everywhere. 5 things that seem mostly identical, except in some edge cases means in reality 1 that is correct, 3 that were forgotten in the update process, and 1 that really is different. Every company is different. As there is almost no human movement, and this is from before networking was widespread, knowledge from each company is an island on its own. The thing is deeply legacy. Ideas like encryption, unicode, a hostile internet network, ... are alien to the COBOL world. The underlying assumption is that the central computer is holy, and humans need to adapt to its whims. You'd better change your name if it contains an accent not available in the local EBCDIC variant. Putting an € sign in a string? That newby char only exists for 2 decades, hope someone migrated to a code page containing it. On the pro side, Hacking attempts are only allowed in the business hours, as the thing switches to batch processing mode at night. An organized testing methodology is rare. The cobol world depends on the knowledge of the programmer to remember the edge cases. No things like automated unit testing, maybe a private db with a few records. The data model is horrible. Choose the size of a record and live with it. You want more chars? Find some spot that's still free and put it in there. The overlays, C unions on steroids, mean any location can contain anything, and any missing IF means you're overwriting someone else's data. I saw cobol devs argue for truncating email adresses. They'd done it with physical mail adresses too, and the mail still arrives. Those mail servers should learn to guess the missing chars at the end, just like the postal workers did. You can use COBOL in a modern setting, but it is not COBOL itself that is the problem. It is the whole ecosystem around it. And of course, they want you to have a 30% pay cut, as COBOL is easy.
- mojo982 4y agoCompanies want to pay less to work with COBOL? I was always told you’d get a nice bump to work with COBOL because so few people are still around to maintain these critical systems?
- Bakary 4y agoI was looking for a more concise version of a classic joke but here it is anyway. https://www.acsu.buffalo.edu/~uoi/Jokes/Cobol.html https://www.acsu.buffalo.edu/~uoi/Jokes/Cobol.html
- jmclnx 4y agoFunny, a little pedantic, but year 3000 will be fine, now year 10000, that will be an issue for COBOL :)
- timbit42 4y agoSome COBOL was fixed by ensuring the code assumed years after "50" is the 20th century and before "50" is the 21st century. This removed the need to modify the database.
- deleted 4y ago[deleted]
- archi42 4y agoUrgs, this reads like an ad. You can replace COBOL with another language (e.g. s/COBOL/Perl/g) and it doesn't change much: > I had no experience with COBOL^W Perl before [my current] job, and I was surprised at how quickly I was able to get in and make my first commit
- vivegi 4y agoI had COBOL as one of the subjects during my engineering course in the early '90s in India. Absolutely hated it. We first learnt Pascal. There is a lot to love about Pascal and in those days the Borland TurboPascal compiler was a breeze to use. Then they dropped the COBOL hammer. We learnt programming this on our comp lab's mini computer. This was the most excruciating class of all. Finally, we moved to C, followed by Compiler construction, Operating systems etc., The trauma of COBOL still lingers. Luckily, I never had to touch COBOL as a professional. ps: In India, for Comp Sci & Engg in those days, we had a fixed set of subjects for the first, second and third years. The fourth year is when we had two electives in each semester. The programming languages were mandatory during the second/third years.
- Koshkin 4y agoFor a perspective on the language, here is the (in)famous pun on the name “C++”: ADD 1 TO COBOL GIVING COBOL
- Frummy 4y agoI'm 23 and finished my second day at a COBOL traineeship at a bank. 2 months of paid education then work. Really fun
- timbit42 4y agoDid you also learn SQL? Most COBOL code I've seen contains SQL. I've always felt SQL statements fit well into COBOL code as the syntaxes are similar in their verboseness.
- Frummy 4y agoYes, I've learned SQL to an introductory level. I have trouble with different joins and so on, but I haven't spent much time on it. Only studied it in the beginning of the year because I thought I could get a T-SQL job. It's going to be covered by this training anyway, it's used a lot here
- tdeck 4y agoWhat was the interview process like?
- Frummy 4y agoIt was extremely spread out timewise but otherwise very tolerant and pleasant. More potential based than experience based. I applied in like april, got a writing question and a coding question split in two parts in may (cobol snippet, loop with conditions to change variables until exit condition is met, answer is all values in order of appearance), then a logic test online. Then in June an on location interview with two people from the bank, hr and manager. Then I had to provide two references, preferably two bosses but I could give a boss and a coworker. Then sign a contract same month. Begin now in september.
- peckrob 4y agoI’m in my early 40s. I know a guy from my college years who is now making a TON of money because he got into COBOL development early in his career and most of his peers are now in their 60s and 70s and retiring. I think he was among the people who helped New Jersey fix some of their COBOL problems a couple years ago [0]. I sometimes wonder what’s going to happen in about 40 years when some then Fortune 50 company who built their entire operation on Node suddenly can’t find Javascript programmers because they’re all retiring. :P [0] https://www.cnbc.com/2020/04/06/new-jersey-seeks-cobol-programmers-to-fix-unemployment-system.html https://www.cnbc.com/2020/04/06/new-jersey-seeks-cobol-progr...
- deadbeeves 4y agoNot every industry is as rewrite-averse as the financial sector.
- Ratfor 4y agotechbeacon.com is a MicroFocus “publication”; you know them, the company selling COBOL tools.