19 ms·

Interviewing my mother, a mainframe COBOL programmer

534 points by Svenskunganka 10y ago

niftich 10y ago
Interesting personal perspective, thanks for posting! It sounds like other than the very slow database, the biggest impediment in this space is the lack of new talent familiar with the environment.
- a_c_s 10y ago
  Every so often I do some research to see if the lack of talent is going to be reflected in salaries but COBOL jobs always seem to pay less than web development
  - jlarocco 10y ago
    It's not just web development, it pays less than almost any development. I would actually not mind learning COBOL and writing boring bank software, but why bother if I can make more money with C++ and Python, while working on more interesting stuff? If I'm going to take a pay cut to use an exotic language, I'm going to find a job writing Lisp.
  - StillBored 10y ago
    That was my experience too with the whole mainframe ecosystem. There are a few hotshot consultants that work for Sirius/mainline/etc that make the bucks, but the guys working for the banks/airlines/etc mostly seem to be underpaid relative to the shrinking knowledge base/talent pool and how critical their jobs are. Makes you wonder what would happen if the entire mainframe tech organization at one of these banks demanded to be paid on par with the traders working on the investment side of the bank.
    - morgante 10y ago
      > Makes you wonder what would happen if the entire mainframe tech organization at one of these banks demanded to be paid on par with the traders working on the investment side of the bank. It's for organizations like this where I really see unions making sense.
- zcdziura 10y ago
  Absolutely. In many cases, universities can't afford their own IBM mainframe environment to allow students to learn how to use it. Many folks, such as myself, have to have on-the-job training in order to learn COBOL and how to use the IBM mainframe itself.
  - niftich 10y ago
    Is that environment something that could be virtualized, were it not for intellectual property reasons? Almost seems to be more of a vendor lock-in issue than an a mere 'old and scarce platform' issue, albeit that's significant also.
    - drabiega 10y ago
      There's already an emulator called Hercules, but you need a license from IBM to run the operating system all of this runs on top of.
      - gkya 10y ago
        Maybe telling IBM about your interest would lead to them licence it free to emulators. They wouldn't like their platform to die because nobody knows how to use it.
        raesene9 10y ago
        you'd think that wouldn't you , instead they've sued them in the past http://arstechnica.com/information-technology/2010/04/ibm-breaks-oss-patent-promise-targets-mainframe-emulator/ http://arstechnica.com/information-technology/2010/04/ibm-br...
        gkya 10y ago
        That's because they've been a bit naughty though, not because of mere corporate evil. Quoting the article you linked: -----8<----- A well-designed System Z emulator that allows users to migrate their own mainframe applications to commodity hardware would obviously pose a serious threat to IBM's mainframe business, but IBM's software licensing terms have historically prevented such a threat from materializing. ... In many ways, the project arguably benefits IBM by encouraging interest in the mainframe platform. [...] What brought about IBM's change in perspective was an unexpected effort by the TurboHercules company to commercialize the project in some unusual ways. TurboHercules came up with a bizarre method to circumvent the licensing restrictions and monetize the emulator. IBM allows customers to transfer the operating system license to another machine in the event that their mainframe suffers an outage. Depending on how you choose to interpret that part of the license, it could make it legally permissible to use IBM's mainframe operating system with Hercules in some cases. Exploiting that loophole in the license, TurboHercules promotes the Hercules emulator as a "disaster recovery" solution that allows mainframe users to continue running their mainframe software on regular PC hardware when their mainframe is inoperable or experiencing technical problems. This has apparently opened up a market for commercial Hercules support with a modest number of potential customers, such as government entities that are required to have redundant failover systems for emergencies, but can't afford to buy a whole additional mainframe. -----8<-----
- Svenskunganka 10y ago
  Lack of new talent is indeed the biggest problem they are facing, but they've acknowledged that they've gotta upgrade these old systems before it's too late - instead of hoping for new talent to show up. Nordea in question has bought a new system that they want to gradually migrate to, but all their mainframe programmers, - including my mother - are all saying it's not going to work. The system is too large.
  - kpil 10y ago
    I've worked on a project that migrated an old cobol system and it went fine although everyone said it would not. But it's not easy and not cheap. The problem for the banks is that they have so many systems, typically thousands, and they are all interconnected. Enter the 'enterprise architects' that draw power points with boxes and buses on top of all the old shit and you have a receipt for a very expensive soup.
- drabiega 10y ago
  Talent is only half of the problem. Where I work they did relatively little hiring for a long time. Many of the people I work with have been working here for 30+ years. Now we have a massive, antiquated code base that is poorly documented and the system knowledge is evaporating due to retirements faster than we can transfer it to new hires.
robkwok 10y ago
Awesome story, thanks for sharing! It's important to take a step back and appreciate history.
- diiq 10y ago
  I'm not sure it's fair to call it history -- it is because of history (what isn't?), but what is described is the way things are right now, eh?
diiq 10y ago
I'd love to have heard some actual quotes from your mother; how did she get into it, what are the best/worst/strangest parts of her day, how does she think the future will look given the lack of young COBOLists, etc.
- Svenskunganka 10y ago
  You are right, I apologize, I'll ask her about how her days looks like and her best/worst/strangest parts. I'll add that directly to the post and reply to you when it's done! EDIT: I've added some Q&A at the bottom, will add more as more questions come in.
  - stuaxo 10y ago
    The q and a bit was my best part, it sounded more life direct quotes.
  - diiq 10y ago
    Thanks, that's lovely! I agree with stuaxo, it is my favorite part.
FatAmericanDev 10y ago
Was expecting a Question and A...
- Svenskunganka 10y ago
  Yeah, sorry about that! I'll add some direct Q&A at the bottom of the post!
  - devuo 10y ago
    Yeah, please do! Here's some questions I would ask: 1. How/when did you decide you wanted to be a programmer? 2. What were the challenges you've faced as a female programmer that started in the 90's? 3. You've been working for the same entity and possibly the same code base for more than 20 years. Does it ever gets old? 4. How scary is it to write code for a bank? I'm certain I would have 100's more questions to ask, but I'll be satisfied with at least these :-)
    - Svenskunganka 10y ago
      There! I've added those to the post at the bottom, with one more quite funny story that I didn't knew about myself. Thank you all for asking questions, there are many questions that I couldn't come up with myself that I'm very happy to get answers from!
jbgreer 10y ago
I think you are overgeneralizing IMS performance. "IMS is extremely old and very slow. Searching for data can take hours." Especially when you later point out that they have 10TB of DB2 data and probably more than that in IMS. Not all IMS databases are slow. Not all MySQL / Postgres, etc. databases are fast.
- Svenskunganka 10y ago
  Definitely not! I'm mostly quoting what she said, but IBM has a lot of nice tech, but you have to understand that these are very old versions of IMS and the volume of data they have does not make the case better. Hierarchical databases are not always slow, but once you want to find stuff at the very bottom of the hierarchy, it'll start take some time.
  - SSLy 10y ago
    Um, what about indexes?
    - giardini 10y ago
      These older databases often allow the use of indexes as an option. Of course ISAM (Indexed Sequential Access Method) is indexed. But also it is often possible to add indexes to the networked database internal structures. An alternative is to use hash tables with overflow. In any case you must usually periodically scan through the database reorganizing the indices and/or location of records, which can take up a lot of time and usually requires taking the database offline. Here's a good read(first is PDF): https://www.google.com/url?q=http://advsys.net/ghs/publications/DBReorgPAP.pdf&sa=U&ved=0ahUKEwiznqms3vTNAhVC7GMKHdpyC7cQFggUMAA&usg=AFQjCNGMpZbH9wAWbDq-6FiMhtn1fBIg4w https://www.google.com/url?q=http://advsys.net/ghs/publicati... or the same paper at Google Books: https://books.google.com/books?id=YqM3pqFVt8IC&pg=PA8&lpg=PA4&ots=ehTAPwbseo&focus=viewport&dq=CODASYL++REORG https://books.google.com/books?id=YqM3pqFVt8IC&pg=PA8&lpg=PA...
  - dandrews 10y ago
    Hierarchical and network DBMSs can scream, but you have to have a competent DBA curate the so-called "physical" relationships (indexes, record and index pointers, child record locality, block sizes, buffers, what-have-you) that support the logical views defined by the application schema. In either IMS or IDMS (where I have some experience) this can be a lot of work, done right. Measure, tweak, repeat. Those older DBMSs can be finicky, but properly monitored are great performers. Conversely, a lazy DBA can cost you a lot of money. And lazy DBAs can be hard to identify - their domain is rather arcane after all.
bitmapbrother 10y ago
>There’s nothing wrong with the language itself, the problem is that barely anyone knows it — at least not in the context of mainframe programming. What data did you use to determine that barely anyone knows mainframe COBOL? There are a significant amount of companies that still use it because it just works and they're in no need to upgrade to current technologies.
- Jtsummers 10y ago
  That it works and that "barely anyone knows it" are not contradictory. Fortran (particularly in the context of embedded systems developed in the 70s and 80s) is another "barely known" language that's quite widely used (particularly in historical and maintenance contexts, if not in widespread current development outside certain engineering and scientific domains).
- scottwhudson 10y ago
  I don't have any data for that point, but I get the sense that this shortage of labor is caused more by aging workforce than obscurity. My dad is an engineering manager for a large credit card processor that uses a very similar mainframe setup, and they're constantly putting enormous pressure on their offshore contracting firms to provide young COBOL programmers because they can barely find them here. It's a job that pays people enough that they can retire well if they're good with money, and they're retiring constantly. At 57, he's one of the youngest on the team.
  - raesene9 10y ago
    unfortunately even assuming the outsourcer can find people who really have COBOL experience there's a world of difference between knowing COBOL and being able to maintain the 30+ years of hacks that many large companies will have built up in these systems. Unfortunately the alternative (re-write the mainframe/COBOL systems in a more modern platform) is a risky and costly process....
    - thomasfortes 10y ago
      In college a few years ago I had to work with a system written in FORTRAN 77 in the early 90s that has been hacked new features and bug fixes on and off for almost 20 years, one single file with more than 20k lines of code, it worked all right, but understanding it was troublesome. I lost the count of how many times I thought about rewriting the entire beast in C or even a more recent iteration of FORTRAN. In the end, it wasn't something that I would use for much longer and I just mapped what all functions that i needed did on a spreadsheet and added a couple of hacks for the next unfortunate person to handle. Maintaining old codebases full of hacks and without good documentation that can fail without big consequences is boring, but code that handles the kind of data that banks have is something straight from hell.
jhallenworld 10y ago
The statements about batch processing are interesting. For example, when you transfer money to someone at a different bank, one way is for the banks to have correspondent accounts with each other, so the transfer is just within accounts at one bank. When one of the correspondent accounts is out of money, they have to do a real inter-bank transfer, probably via the fed or some larger bank. Bottom line is that there is parked money in these accounts. The banks should have every incentive in the world to minimize this parked money (either to get access to their own money or to avoid paying interest on someone else's). So there should be pressure to make the systems as real-time as possible, not batched.
- Symbiote 10y ago
  Would it make much difference? There will be a transaction in the other direction soon enough.
  - kpil 10y ago
    Yes. All current "direct transfer" solutions, more or less requires that you keep a rather large sum of money in a common pool (at the 3rd party) to cover for the event that you run out of money and have to close the bank, to guarantee that all (or at least most of) the money is actually available when the debts are settled, typically a few times a day. I don't think real time settlements involving the central banks will happen any time soon, but maybe more frequent batches.
- nevi-me 10y ago
  Banks already do some of that locally and internationally. In South Africa we have BankServ, which is a local interchange and clearing house. Transactions are still in batches, but the settlement between banks happens nett between the local banks. Internationally, MasterCard, VISA, Amex etc. manage the clearing. Banks then have to pay within 2 days via Swift to either other banks or their designated international settling bank. Going back to your suggestion, it could work because the banks could just pay each other when they run out of funds. The challenge becomes fraud and other legal issues, which often mandate settling houses. The real-time problem is a legacy hardware problem as well as the settling issue. On your last point, money is normally parked at the Central Banks, mostly as a legal requirement. From my experience, banks in healthy financial economies like mine don't keep a lot more than the minimum cash reserve with the Central Bank.
fiatjaf 10y ago
Where is the interview? I want the interview!
akeruu 10y ago
About the IMS to DB2 migration, intuitively I would try to write a translation layer between the two databases. Do you know if this was already attempted or deemed undoable (or silly) from the beginning ?
- kyllo 10y ago
  My last job was at a COBOL shop that used Ordat ti2sql (an emulation layer) to run its HP mainframe code on top of Solaris and DB2. I'm sure similar products exist for other mainframe architectures. http://www.ordat.com/en/solutions/tisql/ http://www.ordat.com/en/solutions/tisql/
- saint_fiasco 10y ago
  DB2 is a relational database and IMS is not. The programs that use IMS probably do lots of things that are just not done in relational databases for good reason, so if you just translate it you will either get errors in relational constraint or you will configure DB2 to stop enforcing relations, losing most of the advantages DB2 has in the first place.
jhallenworld 10y ago
My mother indirectly used COBOL in the microcomputer era: she used Real World Accounting on 68000 based Radio Shack Model-16's under something called Ryan McFarland COBOL Operating System (RM/COS). Eventually this became available on Xenix and SCO UNIX on PCs. My one and so far only COBOL program was an ASCII-graphics game of checkers for the TRS-80 model 16.
- nickpsecurity 10y ago
  That's interesting because (a) it's first I've heard of COS and (b) I cant find jack on it. A bunch of ComputerWorld articles and a patent reference it with a description it's a custom OS for COBOL apps. A web site says it's for an abstract, C machine but nothing to confirm. BitSavers doesnt have anything that stands out to me. Checked jnder Tandy as adds indicated it was licensed to them. I'd be interested in links to guides on this product or scanned pages that show whether OS itself was COBOL. I'll put it on Wikipedia's Timeline of Operating Systems list if I get the info. I got quite a few added there so far. Edit: Some paydirt showing ghe company along with at least compilers absorbed by MicroFocus. Tech might still live on somehow. https://en.m.wikipedia.org/wiki/Digitek https://en.m.wikipedia.org/wiki/Digitek Looking with Digitek, MicroFocus, and Liant still didnt get me jack. This is some phantom of a product.
  - webtechgal 10y ago
    > first I've heard of COS and (b) I cant find jack on it. If you can lay your hands on some issues of BYTE and PC Magazine (Ziff Davis) dated between 1985 and 1990, you would find plenty on RM COBOL.
    - nickpsecurity 10y ago
      That's another angle of the confusion. Most of the search results are old magazines with basically the same advertisements. They advertise both RM/COBOL and RM/COS. They're different products. There's a bit of RM/COBOL information given it basically worked its way into MicroFocus. It's RM/COS that they never describe past "an operating system specifically for COBOL." Note: It's going to be irritating if I find it's another DOS variant after all this work haha.
peterjlee 10y ago
If you're interested in knowing how banking works between banks, Planet Money had a podcast on it few years ago. Apparently bankers met at a parking lot in New York and traded bags of paper checks back in the days. http://www.npr.org/sections/money/2013/10/04/229224964/episode-489-the-invisible-plumbing-of-our-economy http://www.npr.org/sections/money/2013/10/04/229224964/episo...
SilasX 10y ago
Hm, my mom programmed on a mainframe with the pre-Fortran "Michigan Analog Decoder", is that interview-worthy?
- laumars 10y ago
  If it makes an interesting read, then yes :)
- hluska 10y ago
  Very much so! I'd love to read it...
- nickpsecurity 10y ago
  I found lots of analog companies Googling for it but no references to Michelin being in the business. So, yeah, I'd be interested in a link about it and/or the story.
  - SilasX 10y ago
    Just googled it myself and found the same -- following up with her about the name.
  - SilasX 10y ago
    K, turns out it was actually Michigan Algorithm Decoder: https://en.wikipedia.org/wiki/MAD_(programming_language) https://en.wikipedia.org/wiki/MAD_(programming_language) So, not quite as old-school as the analog days :-p
    - nickpsecurity 10y ago
      I was trying to imagine how an analogue component could be anything but a sensor for a mainframe in a factory or something. A programming language called MAD makes so much more sense. :)
nevi-me 10y ago
Interesting article! I've sometimes wondered if I should learn more COBOL. I'm 26, one of my gigs was to reverse-engineer loads of COBOL code whose functionality was being migrated to something modern. There was a few of these very long scripts, written in the 70's. At the top was "Here be Dragons". It felt cool after I figured out what interest calculations it was performing, I ended up leaving a comment "Dragon Slayer was Here" at the end of the script.
- cmdrfred 10y ago
  I don't know man, you can't kill COBOL dragons with a Ruby sword.
- unexistance 10y ago
  you should learn the domain knowledge there while the experts is still around, then migrate it out to ruby or .NET or whatever
  - nevi-me 10y ago
    I think most if not all Mainframes run Java, so I think saner would be to learn so I can port to Java. There are still younger guys in our banks who COBOL, but the domain expertise sits with the much older guys. It's lately common for the older guys who go on pension to come back as "independent consultants". They earn a lot of course.
    - unexistance 10y ago
      eh, modern mainframe even runs Linux, so not really a problem there technically Just find one of the experts that are willing to answer whatever question you have on the legacy COBOL code
- SmellTheGlove 10y ago
  It's a solid skill, and one where a lot of the talent in the industry is going to retire soon. Mainframe skills in general, and COBOL specifically, are still very entrenched in financial services (namely insurance). I don't know a lot of people under 35 who don't shit themselves writing JCL.
Matt3o12_ 10y ago
Not compeltely related to article but I've often heard that banks argue that COBOL is more reliable and maintainable then any "modern" language. I've always wondered why this is the case. Is it because people are way more careful when entering code? The article points out that their IDE is connected to the Mainframe directly which makes me believe an error is much more severe. I'm more confident that the compile and unit tests can catch my mistake than I'm in my own coding skills (which is why I am not always afraid of changing tightly coupled systems). And even if worse comes to worse, i'd still be confident that some system will detect that change and roll back my commit before all goes south. With COBOLT (in such old environments), it seems that things must not break at any point so developer are a lot more careful with what they do, which makes the code do what it is designed for very well. The problem with such an approach is of course upgradability (I would not want to touch undocumented code that has not been updated for 20 years because some government decided to replace an old "protocol". Or maybe, COBOLT is considered more reliable (by Banks, etc) because managers just see the fact "this system has been running for 15 years" while ignoring the problems that come with it. But I'd like to hear your opinion about it.
- ben_jones 10y ago
  I also imagine they are fault-tolerant in ways we no longer consider today.
- delinka 10y ago
  COBOL development had (has?) a completely different development and deployment experience. Sure, you keyed your code directly into the mainframe, but your code and your session were isolated - you, the developer, had limited privileges. Only once your code took the prescribed input and produce the prescribed output was it allowed near "production" data. That said, the language itself was (is?) so limited in scope and ability that stability was nearly guaranteed. You READ and PRINT using tape or disk and printers, but the programmer didn't worry about what devices were available - some system admin pointed these devices at a job, and READ came from that tape and PRINT went to that printer. The setup and management of the jobs that ran your code was a very manual process. No pointers, no memory management ... nothing low-level at all. Just high-level abstraction. Then there's hardware reliability. As an example: you can walk inside the mainframe, pull a CPU, and the thing keeps working. Replace that CPU, and the system makes use of it. None of the system's users ever know that it happened.
david-given 10y ago
You can interface Cobol with modern technologies. See, for example, this web framework: http://www.coboloncogs.org/ http://www.coboloncogs.org/
alexhawdon 10y ago
Really interesting! Thank you both. I would love to know what a 'typical day' and the general working environment are like. (A vague question, I know, but sort-of on purpose.)
Animats 10y ago
It's not that COBOL is particularly good or bad. It's that COBOL-era database technology is painfully-obsolete. Flat files, ISAM, and IMS are all pre-SQL, and old shops are likely to still be running some of that stuff. DB2 isn't too bad; it speaks SQL and runs on various platforms including Linux. With the older systems, the database update logic and the business logic are in the same programs. This is not good.
- zingermc 10y ago
  > With the older systems, the database update logic and the business logic are in the same programs. This is not good. Can you elaborate? Sometimes it seems that business logic must be implemented in SQL, for example, or else you will get a massive performance hit.
  - greglindahl 10y ago
    The article has an explanation of this point, I thought it was plenty to understand what was going on.
  - pc86 10y ago
    Why would you want to be forced to rewrite business logic just because you're using a different database provider?
- wvenable 10y ago
  The COBOL I worked with was all SQL with DB2. Admittedly we were the most "modernized" part of the company.
  - rodgerd 10y ago
    It was interesting, because they interview gave the impression they were quite behind the curve on mainframe technologies - our mainframers work predominantly with DB2 as a back end and have mostly migrated off the more primitive stores quite a long time ago.
lumberjack 10y ago
You know you have job security when you fuck up so badly the government steps in and you still don't get fired. Most of us can only dream of ever achieving that kind of job security. Very nice article. Captivating read. I was interested about what kind of 'previous computer experience' your mom had. That era of computing is completely alien to me.
- clifanatic 10y ago
  > Most of us can only dream of ever achieving that kind of job security. Work on something that nobody else wants to do for 50% of what you could make doing something more fashionable.
- Smurf4 10y ago
  Also comes down to Sweden having a "how do we fix this and make sure it never happens again" culture rather than a US-style blame culture. You can get fired in Sweden if you're grossly negligent or disloyal, but not for a simple mistake that anyone could have made.
  - pm90 10y ago
    This is a very good attitude. In general, the impression I get of Nordic countries is of a more egalitarian social contract with people looking out for each other rather than the culture of personal progress at any cost that we see elsewhere.
    - gaius 10y ago
      I suspect the climate has something to do with it, over hundreds if not thousands of years.
- ebiester 10y ago
  If you have one developer that can make a mistake that bad that the government steps in, you have a process problem, not a developer problem.
- visarga 10y ago
macjohnmcc 10y ago
I studied Fortran, COBOL and RPG II later doing RPG II programming on IBM S/36 computers for 4 years until I went to the PC.
mikejmoffitt 10y ago
"We used to have personal desks, but now we have this “pick whatever spot is available” open area. I dislike it a lot." This fits in line with what nearly everybody I know thinks. Does anyone _actually_ like open-plan offices without dedicated desks? How long until that trend passes?
- gaius 10y ago
  When the sun rises in the West, Hell freeze over and HR goes back to be Personnel.
  - Bromskloss 10y ago
    > Personnel Wow, that's a much better name for it!
    - abraae 10y ago
      There's a weird effect where people become disgruntled with the current terminology because its offensive/demeaning and come up with new words to take their place. Thus Personnel became Human Resources. But often the new words are, with the passage of time, clearly just as, or more offensive than their predecessors. I mean, "Human Resources"?!! WTF! Are people really just "resources"? To me, Personnel sounds way friendlier. Another one is around disability. We would never describe someone today as retarded. Yet really, is disabled any better? I'd rather be retarded (as in, slowed down a little) than disabled (completely stopped). [close to my heart: we write HR software :)]
      - lizzard 10y ago
        I agree about HR! What an annoying term. But, unlike "the r-word", which has lots of history of being used as a direct insult and slur meant to be hurtful, "disability" has quite some time of history as use for political organizing and as a political identity. So while I would actually describe myself as having some physical impairments (such as not being able to walk much) I also would say I am disabled, as a social and political identity. No matter if I mean something different by it than people might think as they use the word to describe me, because it is a point of struggle. Hope that makes sense. It is super interesting how and why people shift the meanings of words!
webwanderings 10y ago
There are tons of (young) Mainframe programmers and experts from India. Banks are facing no such problems. And no, they don't necessarily earn fat paychecks. And I think you have broken a security rule if your screen shot of ISFP is from her bank. This whole article seems risky for her job.
- Svenskunganka 10y ago
  That's not her ISFP, she got much nicer colors! That's an image I found of an ISFP.
mywittyname 10y ago
>I can only imagine the fat paycheck a 20-year old mainframe programmer would get though, because your age in this case would be invaluable. I have a sneaking suspicion that this is not the case. Companies that want top talent and are willing to pay for it are not shy about that fact. Seeing a legit job posting for a position that pays double your current salary is a solid incentive to apply. I'm guessing that the subject of this interview probably makes a less-than-competitive salary. Programmer pay has handily out-paced inflation for decades now. She probably started at around $30,000/yr in 1991, if she managed to get a 3% raise every year, that would only bring her to like $63,000/yr. Naturally, I'd love to be wrong about this. This woman has a demanding and important job and deserves a generous salary for it.
- Svenskunganka 10y ago
  Yeah you're probably right, that was just me asking the question to myself more or less. I've been raised to not ask what people make, that it's considered rude - so I have no clue what she makes.
  - Nullabillity 10y ago
    > I've been raised to not ask what people make, that it's considered rude - so I have no clue what she makes. Sure, but within the same family? While I was a kid this was vital to get some idea of the family budget. :P Of course, it's simple enough to look up at Skatteverket...
- clifanatic 10y ago
  You're not wrong. COBOL programmers aren't paid well AT ALL.
  - Taylor_OD 10y ago
    I've got a uncle whose a COBOL solutions architect at a large company and he makes less than 125K. It's a decent living but he doesnt really have the ability to make a move like many of his .net based colleagues.
ams6110 10y ago
The COBOL programmer shortage is solvable if they simply pay people enough money. COBOL programmers do not make SV salaries, far from it. Yet the code they write generally is handling more critical tasks than most of the stuff SV startups are producing (bank balances, payroll, insurance claims, etc.) Though I found it to be stifling, I would work with mainframes again if the price was right.
- shas3 10y ago
  It is generally true. Less 'fancy' work, you get less money, irrespective of how critical your code/work is. It is an irrational element that is not necessarily driven by supply-demand dynamics.
  - deleted 10y ago
    [deleted]
- swiley 10y ago
  It's well known that Financial companies are generally among the worst places for programmers to work. Learning COBOL just sets you up for a lot of that.
  - kpil 10y ago
    I guess it depends. The pay is ok, the domain is interesting, and the work load is manageable. When I look at some friends doing game development, they seem to work a lot more for a lot less. They have a cooler office though... But I think it's a good idea to try to avoid COBOL.
  - pc86 10y ago
    Well known by whom? Sure it's Enterprise-y and you'll be in a cubicle. You'll also have a very secure position, reasonable working hours and demands, and work at a place with the financial resources to compensate you at market rate (or above). There are a lot of places where it is a lot worse to be a programmer than a bank.
  - clappski 10y ago
module0000 10y ago
Thank you for writing this! This was a very fascinating read - very insightful.
smegel 10y ago
I knew someone who just retired from being a mainframe programmer (not just COBOL). She reckons she could have kept working for another 20 years if she wanted.
c-smile 10y ago
Nice article. Reminded me my own experience of creating bank software system for a State Bank of one of republics that was in the middle of separating from former USSR. "Perestroika" they named that process. No mainframes, where we would get those at that time? Only i386 as a server and PC XTs as terminals. Connected by ropes essentially, but NetBIOS was working over them. Plus 1200 bod or so modems to connect with other banks in the republic. But we (team of two developers) did it in 9 months. Excellent Zortech C++ by Walter Bright (creator of D language). Editor - MultiEdit the Great. What we would do without it - I don't know. Database - dbVista (later known as dbRaima). Everything was working on PTDOS (Russian MSDOS alike thing) Yet multitasking C library providing cooperative multitasking (same execution model Node.js is using). And everything in 640k of RAM that "should be enough for anybody". We were young and nobody hadn't even a chance to tell us that this is "too serious", "impossible" and the like. A lot of manual input by operators, so usability requirements were surprisingly high: http://www.terrainformatica.com/2016/02/ui-usability-solution-i-am-especially-proud-of/ http://www.terrainformatica.com/2016/02/ui-usability-solutio... :)
- jhallenworld 10y ago
  Nice. In that era we had an even cheaper solution for a multi-user accounting system, the VNA by Advanced Micro Research / the "UnTerminal": https://books.google.com/books?id=AlnQ5OJS6XgC&pg=PT167&lpg=PT167&dq=vna+unterminal&source=bl&ots=fcS46ZxES4&sig=a7M14fRPWpXf8wZ2e6hAi2wQO7E&hl=en&sa=X&ved=0ahUKEwigtduGofTNAhWGmR4KHQCyCJkQ6AEIJjAD#v=onepage&q=vna%20unterminal&f=false https://books.google.com/books?id=AlnQ5OJS6XgC&pg=PT167&lpg=... So basically no networking, just multiple video cards and keyboard interfaces in a single 386 PC (it used RS-422 to move the video signals to the screens). In SCO Xenix this worked extremely well. No networking needed.
- shitgoose 10y ago
  musical verification - very nice! a completely unexplored area of UI design. very powerful can be.
  - c-smile 10y ago
    Oh, yeah. Girls were especially happy when we've added an option to choose octave :) I still hear sometimes in my night dreams sound of bank's operation hall orchestra :) Twenty workstations or so at closing of operational day ... It was actually not that bad. The only problem was with 10 digits and 12-tone chromatic scale. Added '.' and '-' to that.
tcopeland 10y ago
Andrew Turley has given a nice COBOL talk; the title alone - "What We Can Learn from COBOL" - is worth the price of admission: http://confreaks.tv/videos/goruco2014-what-we-can-learn-from-cobol http://confreaks.tv/videos/goruco2014-what-we-can-learn-from...
agentgt 10y ago
My grandmother who is in her 80s was one of the US military's first female programmers... and she was a widow... and she was German expatriate (as you can imagine the difficulty of that post WWII). They programmed in punch cards and drank a lot of coffee. If it sounds like I am bragging.. I am.. I am very proud of her. What I'm not proud of is not spending enough time with her to extract more details. I did ask her a similar question about being a German widow working with predominately males and she basically had the same answer as the articles mother... "no problems what so ever". This article is a great reminder that I need to call my grandmother more often :)
- khedoros 10y ago
  My grandfather was instrumental in developing several key products and technologies at IBM in the 60s and 70s. I'd been meaning to call him, and he suddenly died last Saturday. You never know when your opportunity to talk to your grandmother will disappear.
- xxr 10y ago
  Please do. My grandmother (my last living grandparent for over 20 years) passed away in January, and I am indeed happy that I took the opportunity to learn things from her about her life over the years.
- clifanatic 10y ago
  Was her name Grace Hopper?
  - egjerlow 10y ago
    She wasn't a German expatriate, as far as I can tell!
  - agentgt 10y ago
    No it was not. I wish I could provide an official link of her work but I can't seem to google anything. She isn't famous by any means and is exceedingly humble (hence the difficulty on finding details indirectly). Interestingly though she absolutely loves all things sci-fi. She records almost everything the SyFy channel produces and loves Babylon 5, Dr. Who, etc... She is exceedingly good at board games. Even ones she has never played before she often wins. I remember brining Chinese checkers once to her with my wife. She had never played before but she absolutely trashed my wife and me in multiple games. She grew up in Germany and I have often wondered if that had any affect on her non-traditional-gender hobbies and likes. Or maybe it is just her personality (as I love board games and SciFi as well).
sbierwagen 10y ago
I can only imagine the fat paycheck a 20-year old mainframe programmer would get though, because your age in this case would be invaluable. As long as you're on the topic of compensation, how much does she make right now?
- slowmotiony 10y ago
  Not OP; but working in an investment bank in Western Europe as we speak. The mainframe guys next to me are making around 1-2k EUR a day as contractors.
jxramos 10y ago
I remember a professor at Stanford for an early CS class (I'm pretty sure it was Jerry Cain) mentioning COBOL programming and drawing a graph with salary vs time for a given language that manages to be adopted widely. First when the language is rare there's a great ascent up, then as more people gain knowledge the rates drop to some minimum as the knowledge supply broadens. Then as the language shifts into a legacy context the graph ramps up again. If I remember right he claimed the ramp exceeded the initial peak in the earliest days of the language. I forget what the context was but I think it started out with a question about what languages paid the most. I think I recall him quoting a $300/hr figure for COBOL because it's so old school and the knowledgeable population so small. Then come to think of it I think he said the rates essentially drop to zero when the language is all but abandoned and transitions to modern equivalents have befallen.
- davidjnelson 10y ago
  It's funny what most of us consider "a lot of money". An uber driver yesterday mentioned overhearing two organ replacement surgeons talking at his gym in Palo Alto. One said, "man, the pay sucks. It's only $13,000,000 a year :-(". And the other one responded "sheesh, come work for us and we could at least get you up to $19,000,000 a year." Kind of puts things in perspective...
  - jxramos 10y ago
    Yah, the free market is an amazing thing where free individuals freely agree upon rates even as astounding as those figures. The even cooler thing is that there even exist institutions that can fit that into their payroll! Maybe cooler still is that economies exist that even hold institutions such as those. I remember going to this Bay.net talk with Juval Lowy who beat down on everyone calling devs code monkeys who got paid peanuts. Haha, ~100K range is definitely peanuts compared to a seven figure salary. What a world.
    - dangerlibrary 10y ago
      Almost nothing about healthcare in the United States resembles a functioning market, much less one worth marveling at because of all the freely available choices being made.
anabis 10y ago
Japan's Mizuho bank is notorious for struggling with the system update. Big mergers bring big office politics. They were in news in 2002, 2011, and also right now, where they are struggling to finally merge the 3 systems of their pre-merge banks together.
cafard 10y ago
At the end of the 1980s, I was in a systems administration class for a now gone minicomputer line. There were two women in it who seemed quite mature, but must have been younger than I am now. One told a story about her introduction to computing that has stuck with me. She passed an aptitude test to become a programmer: by now I have forgotten whether she worked for a computer manufacturer or a customer the size of a utility company. Whichever it was, the company had a machine room with a glass window opening onto a busy street in Manhattan. In those days, programs mostly resided on punch cards, and data mostly resided on tapes. One would bring one's cards and I suppose tapes to the operators. They would hang the tapes, run the cards through the reader, and the tapes would commence to spin back and forth. If all went well, the program ended with the tapes spinning on back to the reel. In case of an ABEND, everything stopped, and every New Yorker on the sidewalk could say that the program didn't work. It struck me as being far more public a test than most of us my age and younger have ever had to deal with.
peter303 10y ago
COBOL is one of the "big 3" compiled languages developed in the late 1950s; the other two FORTRAN and LISP. All three are still in use. COBOLs fortee was you instructed the computer in English-like sentences and paragraphs.
ank_the_elder 10y ago
I love this article. My own stepmother just retired from a 30+ year old career as a COBOL programmer. One of my first gigs was actually doing a bit of COBOL myself - it's an interesting language in that the database access is built into the language itself, rather than being a library or add-on.
js8 10y ago
I am sad to see the mainframe platform go away. There are still some things that modern platforms could learn from, my biggest favorite is probably the heavy system instrumentation that comes with it (system traces, SMF and RMF). And WLM is also neat. I am afraid it became a victim of its own success. IBM and other SW companies got used to so huge margins so they stopped innovating enough, in order to protect the revenue.
jeffcaijf 10y ago
nice to see such interview, especially it's from parent
wingerlang 10y ago
Is it possible to get into COBOL still? I don't know anything about it, most people seem to say it is horrible to use. Would it be career suicide? Will it be totally gone in X years? Given the chance, I'd probably jump onto the opportunity to work with it. For reference I do iOS development now and I have ZERO experience with COBOL.
jdiez17 10y ago
Thank you for sharing this. Off topic, but I thought the article was very well written!
shiggerino 10y ago
I can understand why the big banks are reluctant to re-write the big systems now that they have painted themselves so far into the corner, but what I don't understand is why they seemed so disinterested in the massive advances that were made in the 1970s that would have made COBOL and IMS long obsolete already then.
- gaius 10y ago
  Reinventing the wheel is not the same as advancing.
krylon 10y ago
Very interesting article, thank you very much! I spent about 9 months in total in a mainframe team during my training, but that team mainly took care of hooking up the mainframes to the corporate network, so I did not do any coding except for small Perl script. (I came close to having to code in REXX, but I dodged that bullet. I played around with REXX at home and did not like it very much.) But it was very interesting to see all the examples of parallel evolution in the mainframe world, at least where the terminology was concerned. A reboot was an IPL (also used as a verb), the OS kernel was a nucleus (a term I really liked), they also had a term for network interfaces I forgot about. A strange but interesting world, it's a shame those beasts are so expensive.
jetcata 10y ago
This tech stack is basically the same as what most insurance companies in Australia use! IBM mainframes, IMS, DB2, Endeavour etc. there's a lot of this type of work still out there.
jason_slack 10y ago
Is there really a market for my COBOL knowledge still? It was one of my favorite languages and honestly it is what got me into SQL and other data analysis languages.
la6470 10y ago
We’ve recently moved to a more “hip” location. We used to have personal desks, but now we have this “pick whatever spot is avaiable” open area. I dislike it a lot. - love it :) she knows what we threw away in the name of being agile and hip.
Shivetya 10y ago
We have the full suite of IBM systems at work, z, i, and p, plus a multitude of other VM systems and windows servers. They have been talking about retiring the z-series for the last twenty years yet have yet to do so. The reason is probably similar to that of the banks, not that there isn't sufficient talent to do so but just because it works, works well, and damn if every silly project a portion off the z, i, or p, doesn't go wrong in some form or another. the new thing is wrappers, extending the life of the applications and their data but allowing modern interfaces via the web and hand held devices. if anything its the best example of code reuse there is. on another note, I don't know if we have anyone under fifty who knows COBOL well enough to do new work but a few can do maintenance just fine
bpyne 10y ago
First off, great post. It's very nostalgic for me because the author is fascinated by the technology of the day. COBOL, hierarchical databases, batch processing were still a norm in IT when I got into the field. My first programming job was around 1992-93 on a Vax using SQR and PL/SQL for an accounting department. We also had to be able to read COBOL. By contrast, my friend got into the field 5 years ahead of me and was hired into an insurance company. His IT department was just switching from assembly and IMS on an IBM mainframe to the "newfangled" COBOL going against DB2. I left IBM after a year, stayed in my first programming job for a year, and then started a 5-year stint with startups. When I hit the startup scene I realized how a new norm was developing. Small servers, C/C++, relational databases, and OLTP were the dominant paradigm in smaller organizations. The author did a nice job describing this period in the history of computing.
chmaynard 10y ago
From a technology perspective, the mainframe software described in this interview is clearly an evolutionary dead-end. It was written in an era when every bank had its own programmers and wrote its own proprietary software. Because of the widespread use of these homegrown systems in the banking industry, however, it appears that management is not yet ready for a total break with the past. The investors that own these companies need to demand change and indicate they are willing to pay the cost.

534 points by Svenskunganka 10y ago

Interesting personal perspective, thanks for posting! It sounds like other than the very slow database, the biggest impediment in this space is the lack of new talent familiar with the environment.

a_c_s 10y ago
Every so often I do some research to see if the lack of talent is going to be reflected in salaries but COBOL jobs always seem to pay less than web development
- jlarocco 10y ago
  It's not just web development, it pays less than almost any development. I would actually not mind learning COBOL and writing boring bank software, but why bother if I can make more money with C++ and Python, while working on more interesting stuff? If I'm going to take a pay cut to use an exotic language, I'm going to find a job writing Lisp.
- StillBored 10y ago
  That was my experience too with the whole mainframe ecosystem. There are a few hotshot consultants that work for Sirius/mainline/etc that make the bucks, but the guys working for the banks/airlines/etc mostly seem to be underpaid relative to the shrinking knowledge base/talent pool and how critical their jobs are. Makes you wonder what would happen if the entire mainframe tech organization at one of these banks demanded to be paid on par with the traders working on the investment side of the bank.
  - morgante 10y ago
    > Makes you wonder what would happen if the entire mainframe tech organization at one of these banks demanded to be paid on par with the traders working on the investment side of the bank. It's for organizations like this where I really see unions making sense.
zcdziura 10y ago
Absolutely. In many cases, universities can't afford their own IBM mainframe environment to allow students to learn how to use it. Many folks, such as myself, have to have on-the-job training in order to learn COBOL and how to use the IBM mainframe itself.
- niftich 10y ago
  Is that environment something that could be virtualized, were it not for intellectual property reasons? Almost seems to be more of a vendor lock-in issue than an a mere 'old and scarce platform' issue, albeit that's significant also.
  - drabiega 10y ago
    There's already an emulator called Hercules, but you need a license from IBM to run the operating system all of this runs on top of.
    - gkya 10y ago
      Maybe telling IBM about your interest would lead to them licence it free to emulators. They wouldn't like their platform to die because nobody knows how to use it.
      - raesene9 10y ago
        you'd think that wouldn't you , instead they've sued them in the past http://arstechnica.com/information-technology/2010/04/ibm-breaks-oss-patent-promise-targets-mainframe-emulator/ http://arstechnica.com/information-technology/2010/04/ibm-br...
        gkya 10y ago
        That's because they've been a bit naughty though, not because of mere corporate evil. Quoting the article you linked: -----8<----- A well-designed System Z emulator that allows users to migrate their own mainframe applications to commodity hardware would obviously pose a serious threat to IBM's mainframe business, but IBM's software licensing terms have historically prevented such a threat from materializing. ... In many ways, the project arguably benefits IBM by encouraging interest in the mainframe platform. [...] What brought about IBM's change in perspective was an unexpected effort by the TurboHercules company to commercialize the project in some unusual ways. TurboHercules came up with a bizarre method to circumvent the licensing restrictions and monetize the emulator. IBM allows customers to transfer the operating system license to another machine in the event that their mainframe suffers an outage. Depending on how you choose to interpret that part of the license, it could make it legally permissible to use IBM's mainframe operating system with Hercules in some cases. Exploiting that loophole in the license, TurboHercules promotes the Hercules emulator as a "disaster recovery" solution that allows mainframe users to continue running their mainframe software on regular PC hardware when their mainframe is inoperable or experiencing technical problems. This has apparently opened up a market for commercial Hercules support with a modest number of potential customers, such as government entities that are required to have redundant failover systems for emergencies, but can't afford to buy a whole additional mainframe. -----8<-----
Svenskunganka 10y ago
Lack of new talent is indeed the biggest problem they are facing, but they've acknowledged that they've gotta upgrade these old systems before it's too late - instead of hoping for new talent to show up. Nordea in question has bought a new system that they want to gradually migrate to, but all their mainframe programmers, - including my mother - are all saying it's not going to work. The system is too large.
- kpil 10y ago
  I've worked on a project that migrated an old cobol system and it went fine although everyone said it would not. But it's not easy and not cheap. The problem for the banks is that they have so many systems, typically thousands, and they are all interconnected. Enter the 'enterprise architects' that draw power points with boxes and buses on top of all the old shit and you have a receipt for a very expensive soup.
drabiega 10y ago
Talent is only half of the problem. Where I work they did relatively little hiring for a long time. Many of the people I work with have been working here for 30+ years. Now we have a massive, antiquated code base that is poorly documented and the system knowledge is evaporating due to retirements faster than we can transfer it to new hires.

robkwok 10y ago

Awesome story, thanks for sharing! It's important to take a step back and appreciate history.

diiq 10y ago
I'm not sure it's fair to call it history -- it is because of history (what isn't?), but what is described is the way things are right now, eh?

diiq 10y ago

I'd love to have heard some actual quotes from your mother; how did she get into it, what are the best/worst/strangest parts of her day, how does she think the future will look given the lack of young COBOLists, etc.

Svenskunganka 10y ago
You are right, I apologize, I'll ask her about how her days looks like and her best/worst/strangest parts. I'll add that directly to the post and reply to you when it's done! EDIT: I've added some Q&A at the bottom, will add more as more questions come in.
- stuaxo 10y ago
  The q and a bit was my best part, it sounded more life direct quotes.
- diiq 10y ago
  Thanks, that's lovely! I agree with stuaxo, it is my favorite part.

FatAmericanDev 10y ago

Was expecting a Question and A...

Svenskunganka 10y ago
Yeah, sorry about that! I'll add some direct Q&A at the bottom of the post!
- devuo 10y ago
  Yeah, please do! Here's some questions I would ask: 1. How/when did you decide you wanted to be a programmer? 2. What were the challenges you've faced as a female programmer that started in the 90's? 3. You've been working for the same entity and possibly the same code base for more than 20 years. Does it ever gets old? 4. How scary is it to write code for a bank? I'm certain I would have 100's more questions to ask, but I'll be satisfied with at least these :-)
  - Svenskunganka 10y ago
    There! I've added those to the post at the bottom, with one more quite funny story that I didn't knew about myself. Thank you all for asking questions, there are many questions that I couldn't come up with myself that I'm very happy to get answers from!

jbgreer 10y ago

I think you are overgeneralizing IMS performance. "IMS is extremely old and very slow. Searching for data can take hours." Especially when you later point out that they have 10TB of DB2 data and probably more than that in IMS. Not all IMS databases are slow. Not all MySQL / Postgres, etc. databases are fast.

Svenskunganka 10y ago
Definitely not! I'm mostly quoting what she said, but IBM has a lot of nice tech, but you have to understand that these are very old versions of IMS and the volume of data they have does not make the case better. Hierarchical databases are not always slow, but once you want to find stuff at the very bottom of the hierarchy, it'll start take some time.
- SSLy 10y ago
  Um, what about indexes?
  - giardini 10y ago
    These older databases often allow the use of indexes as an option. Of course ISAM (Indexed Sequential Access Method) is indexed. But also it is often possible to add indexes to the networked database internal structures. An alternative is to use hash tables with overflow. In any case you must usually periodically scan through the database reorganizing the indices and/or location of records, which can take up a lot of time and usually requires taking the database offline. Here's a good read(first is PDF): https://www.google.com/url?q=http://advsys.net/ghs/publications/DBReorgPAP.pdf&sa=U&ved=0ahUKEwiznqms3vTNAhVC7GMKHdpyC7cQFggUMAA&usg=AFQjCNGMpZbH9wAWbDq-6FiMhtn1fBIg4w https://www.google.com/url?q=http://advsys.net/ghs/publicati... or the same paper at Google Books: https://books.google.com/books?id=YqM3pqFVt8IC&pg=PA8&lpg=PA4&ots=ehTAPwbseo&focus=viewport&dq=CODASYL++REORG https://books.google.com/books?id=YqM3pqFVt8IC&pg=PA8&lpg=PA...
- dandrews 10y ago
  Hierarchical and network DBMSs can scream, but you have to have a competent DBA curate the so-called "physical" relationships (indexes, record and index pointers, child record locality, block sizes, buffers, what-have-you) that support the logical views defined by the application schema. In either IMS or IDMS (where I have some experience) this can be a lot of work, done right. Measure, tweak, repeat. Those older DBMSs can be finicky, but properly monitored are great performers. Conversely, a lazy DBA can cost you a lot of money. And lazy DBAs can be hard to identify - their domain is rather arcane after all.

bitmapbrother 10y ago

>There’s nothing wrong with the language itself, the problem is that barely anyone knows it — at least not in the context of mainframe programming. What data did you use to determine that barely anyone knows mainframe COBOL? There are a significant amount of companies that still use it because it just works and they're in no need to upgrade to current technologies.

Jtsummers 10y ago
That it works and that "barely anyone knows it" are not contradictory. Fortran (particularly in the context of embedded systems developed in the 70s and 80s) is another "barely known" language that's quite widely used (particularly in historical and maintenance contexts, if not in widespread current development outside certain engineering and scientific domains).
scottwhudson 10y ago
I don't have any data for that point, but I get the sense that this shortage of labor is caused more by aging workforce than obscurity. My dad is an engineering manager for a large credit card processor that uses a very similar mainframe setup, and they're constantly putting enormous pressure on their offshore contracting firms to provide young COBOL programmers because they can barely find them here. It's a job that pays people enough that they can retire well if they're good with money, and they're retiring constantly. At 57, he's one of the youngest on the team.
- raesene9 10y ago
  unfortunately even assuming the outsourcer can find people who really have COBOL experience there's a world of difference between knowing COBOL and being able to maintain the 30+ years of hacks that many large companies will have built up in these systems. Unfortunately the alternative (re-write the mainframe/COBOL systems in a more modern platform) is a risky and costly process....
  - thomasfortes 10y ago
    In college a few years ago I had to work with a system written in FORTRAN 77 in the early 90s that has been hacked new features and bug fixes on and off for almost 20 years, one single file with more than 20k lines of code, it worked all right, but understanding it was troublesome. I lost the count of how many times I thought about rewriting the entire beast in C or even a more recent iteration of FORTRAN. In the end, it wasn't something that I would use for much longer and I just mapped what all functions that i needed did on a spreadsheet and added a couple of hacks for the next unfortunate person to handle. Maintaining old codebases full of hacks and without good documentation that can fail without big consequences is boring, but code that handles the kind of data that banks have is something straight from hell.

jhallenworld 10y ago

The statements about batch processing are interesting. For example, when you transfer money to someone at a different bank, one way is for the banks to have correspondent accounts with each other, so the transfer is just within accounts at one bank. When one of the correspondent accounts is out of money, they have to do a real inter-bank transfer, probably via the fed or some larger bank. Bottom line is that there is parked money in these accounts. The banks should have every incentive in the world to minimize this parked money (either to get access to their own money or to avoid paying interest on someone else's). So there should be pressure to make the systems as real-time as possible, not batched.

Symbiote 10y ago
Would it make much difference? There will be a transaction in the other direction soon enough.
- kpil 10y ago
  Yes. All current "direct transfer" solutions, more or less requires that you keep a rather large sum of money in a common pool (at the 3rd party) to cover for the event that you run out of money and have to close the bank, to guarantee that all (or at least most of) the money is actually available when the debts are settled, typically a few times a day. I don't think real time settlements involving the central banks will happen any time soon, but maybe more frequent batches.
nevi-me 10y ago
Banks already do some of that locally and internationally. In South Africa we have BankServ, which is a local interchange and clearing house. Transactions are still in batches, but the settlement between banks happens nett between the local banks. Internationally, MasterCard, VISA, Amex etc. manage the clearing. Banks then have to pay within 2 days via Swift to either other banks or their designated international settling bank. Going back to your suggestion, it could work because the banks could just pay each other when they run out of funds. The challenge becomes fraud and other legal issues, which often mandate settling houses. The real-time problem is a legacy hardware problem as well as the settling issue. On your last point, money is normally parked at the Central Banks, mostly as a legal requirement. From my experience, banks in healthy financial economies like mine don't keep a lot more than the minimum cash reserve with the Central Bank.

fiatjaf 10y ago

Where is the interview? I want the interview!

akeruu 10y ago

About the IMS to DB2 migration, intuitively I would try to write a translation layer between the two databases. Do you know if this was already attempted or deemed undoable (or silly) from the beginning ?

kyllo 10y ago
My last job was at a COBOL shop that used Ordat ti2sql (an emulation layer) to run its HP mainframe code on top of Solaris and DB2. I'm sure similar products exist for other mainframe architectures. http://www.ordat.com/en/solutions/tisql/ http://www.ordat.com/en/solutions/tisql/
saint_fiasco 10y ago
DB2 is a relational database and IMS is not. The programs that use IMS probably do lots of things that are just not done in relational databases for good reason, so if you just translate it you will either get errors in relational constraint or you will configure DB2 to stop enforcing relations, losing most of the advantages DB2 has in the first place.

jhallenworld 10y ago

My mother indirectly used COBOL in the microcomputer era: she used Real World Accounting on 68000 based Radio Shack Model-16's under something called Ryan McFarland COBOL Operating System (RM/COS). Eventually this became available on Xenix and SCO UNIX on PCs. My one and so far only COBOL program was an ASCII-graphics game of checkers for the TRS-80 model 16.

nickpsecurity 10y ago
That's interesting because (a) it's first I've heard of COS and (b) I cant find jack on it. A bunch of ComputerWorld articles and a patent reference it with a description it's a custom OS for COBOL apps. A web site says it's for an abstract, C machine but nothing to confirm. BitSavers doesnt have anything that stands out to me. Checked jnder Tandy as adds indicated it was licensed to them. I'd be interested in links to guides on this product or scanned pages that show whether OS itself was COBOL. I'll put it on Wikipedia's Timeline of Operating Systems list if I get the info. I got quite a few added there so far. Edit: Some paydirt showing ghe company along with at least compilers absorbed by MicroFocus. Tech might still live on somehow. https://en.m.wikipedia.org/wiki/Digitek https://en.m.wikipedia.org/wiki/Digitek Looking with Digitek, MicroFocus, and Liant still didnt get me jack. This is some phantom of a product.
- webtechgal 10y ago
  > first I've heard of COS and (b) I cant find jack on it. If you can lay your hands on some issues of BYTE and PC Magazine (Ziff Davis) dated between 1985 and 1990, you would find plenty on RM COBOL.
  - nickpsecurity 10y ago
    That's another angle of the confusion. Most of the search results are old magazines with basically the same advertisements. They advertise both RM/COBOL and RM/COS. They're different products. There's a bit of RM/COBOL information given it basically worked its way into MicroFocus. It's RM/COS that they never describe past "an operating system specifically for COBOL." Note: It's going to be irritating if I find it's another DOS variant after all this work haha.

peterjlee 10y ago

If you're interested in knowing how banking works between banks, Planet Money had a podcast on it few years ago. Apparently bankers met at a parking lot in New York and traded bags of paper checks back in the days. http://www.npr.org/sections/money/2013/10/04/229224964/episode-489-the-invisible-plumbing-of-our-economy http://www.npr.org/sections/money/2013/10/04/229224964/episo...

SilasX 10y ago

Hm, my mom programmed on a mainframe with the pre-Fortran "Michigan Analog Decoder", is that interview-worthy?

laumars 10y ago
If it makes an interesting read, then yes :)
hluska 10y ago
Very much so! I'd love to read it...
nickpsecurity 10y ago
I found lots of analog companies Googling for it but no references to Michelin being in the business. So, yeah, I'd be interested in a link about it and/or the story.
- SilasX 10y ago
  Just googled it myself and found the same -- following up with her about the name.
- SilasX 10y ago
  K, turns out it was actually Michigan Algorithm Decoder: https://en.wikipedia.org/wiki/MAD_(programming_language) https://en.wikipedia.org/wiki/MAD_(programming_language) So, not quite as old-school as the analog days :-p
  - nickpsecurity 10y ago
    I was trying to imagine how an analogue component could be anything but a sensor for a mainframe in a factory or something. A programming language called MAD makes so much more sense. :)

nevi-me 10y ago

Interesting article! I've sometimes wondered if I should learn more COBOL. I'm 26, one of my gigs was to reverse-engineer loads of COBOL code whose functionality was being migrated to something modern. There was a few of these very long scripts, written in the 70's. At the top was "Here be Dragons". It felt cool after I figured out what interest calculations it was performing, I ended up leaving a comment "Dragon Slayer was Here" at the end of the script.

cmdrfred 10y ago
I don't know man, you can't kill COBOL dragons with a Ruby sword.
unexistance 10y ago
you should learn the domain knowledge there while the experts is still around, then migrate it out to ruby or .NET or whatever
- nevi-me 10y ago
  I think most if not all Mainframes run Java, so I think saner would be to learn so I can port to Java. There are still younger guys in our banks who COBOL, but the domain expertise sits with the much older guys. It's lately common for the older guys who go on pension to come back as "independent consultants". They earn a lot of course.
  - unexistance 10y ago
    eh, modern mainframe even runs Linux, so not really a problem there technically Just find one of the experts that are willing to answer whatever question you have on the legacy COBOL code
SmellTheGlove 10y ago
It's a solid skill, and one where a lot of the talent in the industry is going to retire soon. Mainframe skills in general, and COBOL specifically, are still very entrenched in financial services (namely insurance). I don't know a lot of people under 35 who don't shit themselves writing JCL.

Matt3o12_ 10y ago

Not compeltely related to article but I've often heard that banks argue that COBOL is more reliable and maintainable then any "modern" language. I've always wondered why this is the case. Is it because people are way more careful when entering code? The article points out that their IDE is connected to the Mainframe directly which makes me believe an error is much more severe. I'm more confident that the compile and unit tests can catch my mistake than I'm in my own coding skills (which is why I am not always afraid of changing tightly coupled systems). And even if worse comes to worse, i'd still be confident that some system will detect that change and roll back my commit before all goes south. With COBOLT (in such old environments), it seems that things must not break at any point so developer are a lot more careful with what they do, which makes the code do what it is designed for very well. The problem with such an approach is of course upgradability (I would not want to touch undocumented code that has not been updated for 20 years because some government decided to replace an old "protocol". Or maybe, COBOLT is considered more reliable (by Banks, etc) because managers just see the fact "this system has been running for 15 years" while ignoring the problems that come with it. But I'd like to hear your opinion about it.

ben_jones 10y ago
I also imagine they are fault-tolerant in ways we no longer consider today.
delinka 10y ago
COBOL development had (has?) a completely different development and deployment experience. Sure, you keyed your code directly into the mainframe, but your code and your session were isolated - you, the developer, had limited privileges. Only once your code took the prescribed input and produce the prescribed output was it allowed near "production" data. That said, the language itself was (is?) so limited in scope and ability that stability was nearly guaranteed. You READ and PRINT using tape or disk and printers, but the programmer didn't worry about what devices were available - some system admin pointed these devices at a job, and READ came from that tape and PRINT went to that printer. The setup and management of the jobs that ran your code was a very manual process. No pointers, no memory management ... nothing low-level at all. Just high-level abstraction. Then there's hardware reliability. As an example: you can walk inside the mainframe, pull a CPU, and the thing keeps working. Replace that CPU, and the system makes use of it. None of the system's users ever know that it happened.

david-given 10y ago

You can interface Cobol with modern technologies. See, for example, this web framework: http://www.coboloncogs.org/ http://www.coboloncogs.org/

alexhawdon 10y ago

Really interesting! Thank you both. I would love to know what a 'typical day' and the general working environment are like. (A vague question, I know, but sort-of on purpose.)

Animats 10y ago

It's not that COBOL is particularly good or bad. It's that COBOL-era database technology is painfully-obsolete. Flat files, ISAM, and IMS are all pre-SQL, and old shops are likely to still be running some of that stuff. DB2 isn't too bad; it speaks SQL and runs on various platforms including Linux. With the older systems, the database update logic and the business logic are in the same programs. This is not good.

zingermc 10y ago
> With the older systems, the database update logic and the business logic are in the same programs. This is not good. Can you elaborate? Sometimes it seems that business logic must be implemented in SQL, for example, or else you will get a massive performance hit.
- greglindahl 10y ago
  The article has an explanation of this point, I thought it was plenty to understand what was going on.
- pc86 10y ago
  Why would you want to be forced to rewrite business logic just because you're using a different database provider?
wvenable 10y ago
The COBOL I worked with was all SQL with DB2. Admittedly we were the most "modernized" part of the company.
- rodgerd 10y ago
  It was interesting, because they interview gave the impression they were quite behind the curve on mainframe technologies - our mainframers work predominantly with DB2 as a back end and have mostly migrated off the more primitive stores quite a long time ago.

lumberjack 10y ago

You know you have job security when you fuck up so badly the government steps in and you still don't get fired. Most of us can only dream of ever achieving that kind of job security. Very nice article. Captivating read. I was interested about what kind of 'previous computer experience' your mom had. That era of computing is completely alien to me.

clifanatic 10y ago
> Most of us can only dream of ever achieving that kind of job security. Work on something that nobody else wants to do for 50% of what you could make doing something more fashionable.
Smurf4 10y ago
Also comes down to Sweden having a "how do we fix this and make sure it never happens again" culture rather than a US-style blame culture. You can get fired in Sweden if you're grossly negligent or disloyal, but not for a simple mistake that anyone could have made.
- pm90 10y ago
  This is a very good attitude. In general, the impression I get of Nordic countries is of a more egalitarian social contract with people looking out for each other rather than the culture of personal progress at any cost that we see elsewhere.
  - gaius 10y ago
    I suspect the climate has something to do with it, over hundreds if not thousands of years.
ebiester 10y ago
If you have one developer that can make a mistake that bad that the government steps in, you have a process problem, not a developer problem.
visarga 10y ago

macjohnmcc 10y ago

I studied Fortran, COBOL and RPG II later doing RPG II programming on IBM S/36 computers for 4 years until I went to the PC.

mikejmoffitt 10y ago

"We used to have personal desks, but now we have this “pick whatever spot is available” open area. I dislike it a lot." This fits in line with what nearly everybody I know thinks. Does anyone _actually_ like open-plan offices without dedicated desks? How long until that trend passes?

gaius 10y ago
When the sun rises in the West, Hell freeze over and HR goes back to be Personnel.
- Bromskloss 10y ago
  > Personnel Wow, that's a much better name for it!
  - abraae 10y ago
    There's a weird effect where people become disgruntled with the current terminology because its offensive/demeaning and come up with new words to take their place. Thus Personnel became Human Resources. But often the new words are, with the passage of time, clearly just as, or more offensive than their predecessors. I mean, "Human Resources"?!! WTF! Are people really just "resources"? To me, Personnel sounds way friendlier. Another one is around disability. We would never describe someone today as retarded. Yet really, is disabled any better? I'd rather be retarded (as in, slowed down a little) than disabled (completely stopped). [close to my heart: we write HR software :)]
    - lizzard 10y ago
      I agree about HR! What an annoying term. But, unlike "the r-word", which has lots of history of being used as a direct insult and slur meant to be hurtful, "disability" has quite some time of history as use for political organizing and as a political identity. So while I would actually describe myself as having some physical impairments (such as not being able to walk much) I also would say I am disabled, as a social and political identity. No matter if I mean something different by it than people might think as they use the word to describe me, because it is a point of struggle. Hope that makes sense. It is super interesting how and why people shift the meanings of words!

webwanderings 10y ago

There are tons of (young) Mainframe programmers and experts from India. Banks are facing no such problems. And no, they don't necessarily earn fat paychecks. And I think you have broken a security rule if your screen shot of ISFP is from her bank. This whole article seems risky for her job.

Svenskunganka 10y ago
That's not her ISFP, she got much nicer colors! That's an image I found of an ISFP.

mywittyname 10y ago

>I can only imagine the fat paycheck a 20-year old mainframe programmer would get though, because your age in this case would be invaluable. I have a sneaking suspicion that this is not the case. Companies that want top talent and are willing to pay for it are not shy about that fact. Seeing a legit job posting for a position that pays double your current salary is a solid incentive to apply. I'm guessing that the subject of this interview probably makes a less-than-competitive salary. Programmer pay has handily out-paced inflation for decades now. She probably started at around $30,000/yr in 1991, if she managed to get a 3% raise every year, that would only bring her to like $63,000/yr. Naturally, I'd love to be wrong about this. This woman has a demanding and important job and deserves a generous salary for it.

Svenskunganka 10y ago
Yeah you're probably right, that was just me asking the question to myself more or less. I've been raised to not ask what people make, that it's considered rude - so I have no clue what she makes.
- Nullabillity 10y ago
  > I've been raised to not ask what people make, that it's considered rude - so I have no clue what she makes. Sure, but within the same family? While I was a kid this was vital to get some idea of the family budget. :P Of course, it's simple enough to look up at Skatteverket...
clifanatic 10y ago
You're not wrong. COBOL programmers aren't paid well AT ALL.
- Taylor_OD 10y ago
  I've got a uncle whose a COBOL solutions architect at a large company and he makes less than 125K. It's a decent living but he doesnt really have the ability to make a move like many of his .net based colleagues.

ams6110 10y ago

The COBOL programmer shortage is solvable if they simply pay people enough money. COBOL programmers do not make SV salaries, far from it. Yet the code they write generally is handling more critical tasks than most of the stuff SV startups are producing (bank balances, payroll, insurance claims, etc.) Though I found it to be stifling, I would work with mainframes again if the price was right.

shas3 10y ago
It is generally true. Less 'fancy' work, you get less money, irrespective of how critical your code/work is. It is an irrational element that is not necessarily driven by supply-demand dynamics.
- deleted 10y ago
  [deleted]
swiley 10y ago
It's well known that Financial companies are generally among the worst places for programmers to work. Learning COBOL just sets you up for a lot of that.
- kpil 10y ago
  I guess it depends. The pay is ok, the domain is interesting, and the work load is manageable. When I look at some friends doing game development, they seem to work a lot more for a lot less. They have a cooler office though... But I think it's a good idea to try to avoid COBOL.
- pc86 10y ago
  Well known by whom? Sure it's Enterprise-y and you'll be in a cubicle. You'll also have a very secure position, reasonable working hours and demands, and work at a place with the financial resources to compensate you at market rate (or above). There are a lot of places where it is a lot worse to be a programmer than a bank.
- clappski 10y ago

module0000 10y ago

Thank you for writing this! This was a very fascinating read - very insightful.

smegel 10y ago

I knew someone who just retired from being a mainframe programmer (not just COBOL). She reckons she could have kept working for another 20 years if she wanted.

c-smile 10y ago

Nice article. Reminded me my own experience of creating bank software system for a State Bank of one of republics that was in the middle of separating from former USSR. "Perestroika" they named that process. No mainframes, where we would get those at that time? Only i386 as a server and PC XTs as terminals. Connected by ropes essentially, but NetBIOS was working over them. Plus 1200 bod or so modems to connect with other banks in the republic. But we (team of two developers) did it in 9 months. Excellent Zortech C++ by Walter Bright (creator of D language). Editor - MultiEdit the Great. What we would do without it - I don't know. Database - dbVista (later known as dbRaima). Everything was working on PTDOS (Russian MSDOS alike thing) Yet multitasking C library providing cooperative multitasking (same execution model Node.js is using). And everything in 640k of RAM that "should be enough for anybody". We were young and nobody hadn't even a chance to tell us that this is "too serious", "impossible" and the like. A lot of manual input by operators, so usability requirements were surprisingly high: http://www.terrainformatica.com/2016/02/ui-usability-solution-i-am-especially-proud-of/ http://www.terrainformatica.com/2016/02/ui-usability-solutio... :)

jhallenworld 10y ago
Nice. In that era we had an even cheaper solution for a multi-user accounting system, the VNA by Advanced Micro Research / the "UnTerminal": https://books.google.com/books?id=AlnQ5OJS6XgC&pg=PT167&lpg=PT167&dq=vna+unterminal&source=bl&ots=fcS46ZxES4&sig=a7M14fRPWpXf8wZ2e6hAi2wQO7E&hl=en&sa=X&ved=0ahUKEwigtduGofTNAhWGmR4KHQCyCJkQ6AEIJjAD#v=onepage&q=vna%20unterminal&f=false https://books.google.com/books?id=AlnQ5OJS6XgC&pg=PT167&lpg=... So basically no networking, just multiple video cards and keyboard interfaces in a single 386 PC (it used RS-422 to move the video signals to the screens). In SCO Xenix this worked extremely well. No networking needed.
shitgoose 10y ago
musical verification - very nice! a completely unexplored area of UI design. very powerful can be.
- c-smile 10y ago
  Oh, yeah. Girls were especially happy when we've added an option to choose octave :) I still hear sometimes in my night dreams sound of bank's operation hall orchestra :) Twenty workstations or so at closing of operational day ... It was actually not that bad. The only problem was with 10 digits and 12-tone chromatic scale. Added '.' and '-' to that.

tcopeland 10y ago

Andrew Turley has given a nice COBOL talk; the title alone - "What We Can Learn from COBOL" - is worth the price of admission: http://confreaks.tv/videos/goruco2014-what-we-can-learn-from-cobol http://confreaks.tv/videos/goruco2014-what-we-can-learn-from...

agentgt 10y ago

My grandmother who is in her 80s was one of the US military's first female programmers... and she was a widow... and she was German expatriate (as you can imagine the difficulty of that post WWII). They programmed in punch cards and drank a lot of coffee. If it sounds like I am bragging.. I am.. I am very proud of her. What I'm not proud of is not spending enough time with her to extract more details. I did ask her a similar question about being a German widow working with predominately males and she basically had the same answer as the articles mother... "no problems what so ever". This article is a great reminder that I need to call my grandmother more often :)

khedoros 10y ago
My grandfather was instrumental in developing several key products and technologies at IBM in the 60s and 70s. I'd been meaning to call him, and he suddenly died last Saturday. You never know when your opportunity to talk to your grandmother will disappear.
xxr 10y ago
Please do. My grandmother (my last living grandparent for over 20 years) passed away in January, and I am indeed happy that I took the opportunity to learn things from her about her life over the years.
clifanatic 10y ago
Was her name Grace Hopper?
- egjerlow 10y ago
  She wasn't a German expatriate, as far as I can tell!
- agentgt 10y ago
  No it was not. I wish I could provide an official link of her work but I can't seem to google anything. She isn't famous by any means and is exceedingly humble (hence the difficulty on finding details indirectly). Interestingly though she absolutely loves all things sci-fi. She records almost everything the SyFy channel produces and loves Babylon 5, Dr. Who, etc... She is exceedingly good at board games. Even ones she has never played before she often wins. I remember brining Chinese checkers once to her with my wife. She had never played before but she absolutely trashed my wife and me in multiple games. She grew up in Germany and I have often wondered if that had any affect on her non-traditional-gender hobbies and likes. Or maybe it is just her personality (as I love board games and SciFi as well).

sbierwagen 10y ago

I can only imagine the fat paycheck a 20-year old mainframe programmer would get though, because your age in this case would be invaluable. As long as you're on the topic of compensation, how much does she make right now?

slowmotiony 10y ago
Not OP; but working in an investment bank in Western Europe as we speak. The mainframe guys next to me are making around 1-2k EUR a day as contractors.

jxramos 10y ago

I remember a professor at Stanford for an early CS class (I'm pretty sure it was Jerry Cain) mentioning COBOL programming and drawing a graph with salary vs time for a given language that manages to be adopted widely. First when the language is rare there's a great ascent up, then as more people gain knowledge the rates drop to some minimum as the knowledge supply broadens. Then as the language shifts into a legacy context the graph ramps up again. If I remember right he claimed the ramp exceeded the initial peak in the earliest days of the language. I forget what the context was but I think it started out with a question about what languages paid the most. I think I recall him quoting a $300/hr figure for COBOL because it's so old school and the knowledgeable population so small. Then come to think of it I think he said the rates essentially drop to zero when the language is all but abandoned and transitions to modern equivalents have befallen.

davidjnelson 10y ago
It's funny what most of us consider "a lot of money". An uber driver yesterday mentioned overhearing two organ replacement surgeons talking at his gym in Palo Alto. One said, "man, the pay sucks. It's only $13,000,000 a year :-(". And the other one responded "sheesh, come work for us and we could at least get you up to $19,000,000 a year." Kind of puts things in perspective...
- jxramos 10y ago
  Yah, the free market is an amazing thing where free individuals freely agree upon rates even as astounding as those figures. The even cooler thing is that there even exist institutions that can fit that into their payroll! Maybe cooler still is that economies exist that even hold institutions such as those. I remember going to this Bay.net talk with Juval Lowy who beat down on everyone calling devs code monkeys who got paid peanuts. Haha, ~100K range is definitely peanuts compared to a seven figure salary. What a world.
  - dangerlibrary 10y ago
    Almost nothing about healthcare in the United States resembles a functioning market, much less one worth marveling at because of all the freely available choices being made.

anabis 10y ago

Japan's Mizuho bank is notorious for struggling with the system update. Big mergers bring big office politics. They were in news in 2002, 2011, and also right now, where they are struggling to finally merge the 3 systems of their pre-merge banks together.

cafard 10y ago

At the end of the 1980s, I was in a systems administration class for a now gone minicomputer line. There were two women in it who seemed quite mature, but must have been younger than I am now. One told a story about her introduction to computing that has stuck with me. She passed an aptitude test to become a programmer: by now I have forgotten whether she worked for a computer manufacturer or a customer the size of a utility company. Whichever it was, the company had a machine room with a glass window opening onto a busy street in Manhattan. In those days, programs mostly resided on punch cards, and data mostly resided on tapes. One would bring one's cards and I suppose tapes to the operators. They would hang the tapes, run the cards through the reader, and the tapes would commence to spin back and forth. If all went well, the program ended with the tapes spinning on back to the reel. In case of an ABEND, everything stopped, and every New Yorker on the sidewalk could say that the program didn't work. It struck me as being far more public a test than most of us my age and younger have ever had to deal with.

peter303 10y ago

COBOL is one of the "big 3" compiled languages developed in the late 1950s; the other two FORTRAN and LISP. All three are still in use. COBOLs fortee was you instructed the computer in English-like sentences and paragraphs.

ank_the_elder 10y ago

I love this article. My own stepmother just retired from a 30+ year old career as a COBOL programmer. One of my first gigs was actually doing a bit of COBOL myself - it's an interesting language in that the database access is built into the language itself, rather than being a library or add-on.

js8 10y ago

I am sad to see the mainframe platform go away. There are still some things that modern platforms could learn from, my biggest favorite is probably the heavy system instrumentation that comes with it (system traces, SMF and RMF). And WLM is also neat. I am afraid it became a victim of its own success. IBM and other SW companies got used to so huge margins so they stopped innovating enough, in order to protect the revenue.

jeffcaijf 10y ago

nice to see such interview, especially it's from parent

wingerlang 10y ago

Is it possible to get into COBOL still? I don't know anything about it, most people seem to say it is horrible to use. Would it be career suicide? Will it be totally gone in X years? Given the chance, I'd probably jump onto the opportunity to work with it. For reference I do iOS development now and I have ZERO experience with COBOL.

jdiez17 10y ago

Thank you for sharing this. Off topic, but I thought the article was very well written!

shiggerino 10y ago

I can understand why the big banks are reluctant to re-write the big systems now that they have painted themselves so far into the corner, but what I don't understand is why they seemed so disinterested in the massive advances that were made in the 1970s that would have made COBOL and IMS long obsolete already then.

gaius 10y ago
Reinventing the wheel is not the same as advancing.

krylon 10y ago

Very interesting article, thank you very much! I spent about 9 months in total in a mainframe team during my training, but that team mainly took care of hooking up the mainframes to the corporate network, so I did not do any coding except for small Perl script. (I came close to having to code in REXX, but I dodged that bullet. I played around with REXX at home and did not like it very much.) But it was very interesting to see all the examples of parallel evolution in the mainframe world, at least where the terminology was concerned. A reboot was an IPL (also used as a verb), the OS kernel was a nucleus (a term I really liked), they also had a term for network interfaces I forgot about. A strange but interesting world, it's a shame those beasts are so expensive.

jetcata 10y ago

This tech stack is basically the same as what most insurance companies in Australia use! IBM mainframes, IMS, DB2, Endeavour etc. there's a lot of this type of work still out there.

jason_slack 10y ago

Is there really a market for my COBOL knowledge still? It was one of my favorite languages and honestly it is what got me into SQL and other data analysis languages.

la6470 10y ago

We’ve recently moved to a more “hip” location. We used to have personal desks, but now we have this “pick whatever spot is avaiable” open area. I dislike it a lot. - love it :) she knows what we threw away in the name of being agile and hip.

Shivetya 10y ago

We have the full suite of IBM systems at work, z, i, and p, plus a multitude of other VM systems and windows servers. They have been talking about retiring the z-series for the last twenty years yet have yet to do so. The reason is probably similar to that of the banks, not that there isn't sufficient talent to do so but just because it works, works well, and damn if every silly project a portion off the z, i, or p, doesn't go wrong in some form or another. the new thing is wrappers, extending the life of the applications and their data but allowing modern interfaces via the web and hand held devices. if anything its the best example of code reuse there is. on another note, I don't know if we have anyone under fifty who knows COBOL well enough to do new work but a few can do maintenance just fine

bpyne 10y ago

First off, great post. It's very nostalgic for me because the author is fascinated by the technology of the day. COBOL, hierarchical databases, batch processing were still a norm in IT when I got into the field. My first programming job was around 1992-93 on a Vax using SQR and PL/SQL for an accounting department. We also had to be able to read COBOL. By contrast, my friend got into the field 5 years ahead of me and was hired into an insurance company. His IT department was just switching from assembly and IMS on an IBM mainframe to the "newfangled" COBOL going against DB2. I left IBM after a year, stayed in my first programming job for a year, and then started a 5-year stint with startups. When I hit the startup scene I realized how a new norm was developing. Small servers, C/C++, relational databases, and OLTP were the dominant paradigm in smaller organizations. The author did a nice job describing this period in the history of computing.

chmaynard 10y ago

From a technology perspective, the mainframe software described in this interview is clearly an evolutionary dead-end. It was written in an era when every bank had its own programmers and wrote its own proprietary software. Because of the widespread use of these homegrown systems in the banking industry, however, it appears that management is not yet ready for a total break with the past. The investors that own these companies need to demand change and indicate they are willing to pay the cost.