26 ms·

COBOL programmers answer call

320 points by furcyd 7y ago

cable2600 7y ago
Someone invent a COBOL to Python converter to get rid of these old dinosaurs IBM Mainframes.
- klodolph 7y ago
  This is a misunderstanding of the problem. It’s not the fact that it’s COBOL, per se, that’s the problem. The issue is with making changes to an entire system. A program written in COBOL may be at the center of that system, but that program is only one part of it.
- deleted 7y ago
  [deleted]
- nimih 7y ago
  Given that the Python foundation has been trying to get folks to run a python-to-python converter for more than a decade and have not completely succeeded, I'm skeptical that an AST transformer is really sufficient for migrating off those legacy systems. More constructively, having worked on a (close to decade-long, by the time I joined) project to migrate a financial institution's business logic off an IBM mainframe onto more modern architecture, my main takeaway was that these systems have worked pretty darn well for decades with relatively little maintenance. The reluctance of companies to migrate god-knows-how-much data, business rules, and institutional knowledge (e.g. of data entry folks, business-level administrators who have to navigate these systems to do their job, etc) off a time-tested system they trust at massive expense, is completely understandable.
- lukevp 7y ago
  Mainframes aren’t some old crusty thing that’s about to die from all the bugs stuck in the fans or something. We have a cobol system and it runs on modern IBM hardware. Besides, almost everything is virtualized now anyway. The mainframes aren’t the problem, and doing a code conversion of COBOL is not trivial. Their data types are completely at odds to normal data types in modern languages (for example, you can specify a string that is always exactly 30 ascii characters long, the 4th character must be a numeric, the 18th must be ascii but not numeric, the 22nd through 30th must be alphanumeric. All with a native datatype. And that’s just the scalar types, Cobol data types natively support recurrences and redefines and heirarchies. And the language has like 400 keywords.) You end up having to wrap every single line of code in compatibility layers upon compatibility layers, and then it doesn’t even look like python, it just looks like a crappier version of Cobol, to make it function identically. It’s much easier (though more time consuming) to read the code and determine the business rules being enforced and reimplement them in a modern language. I have worked with a lot of Cobol translators and their output is worse than the original code by far. With a lot less confidence and experience with maintaining it.
- wiz21c 7y ago
  I don't know if it's still true, but COBOL systems were really well optimized for I/O, for performance, etc. Python won't stand a chance...
triska 7y ago
COBOL can be a real pleasure to use. For instance, it allows programmers to quickly create user interfaces by declaratively describing them, in a so called SCREEN SECTION. The resulting interfaces are very efficient for text entry, and allow users to quickly get a lot of work done. The interaction is so much more efficient than what we are used to with current technologies that it can barely be described or thought about in today's terms. Regarding the underlying theme of legacy systems, here is an interesting presentation by Jonathan Blow, citing various examples of earlier civilizations losing access to technologies they once had: https://www.youtube.com/watch?v=pW-SOdj4Kkk https://www.youtube.com/watch?v=pW-SOdj4Kkk I think in terms of user interfaces, we are on a downward path in several important ways, and I highly recommend checking out earlier technologies that were in many ways an improvement over what we are working with today.
- adzm 7y ago
  I was blown away by some reporting systems in COBOL that were surprisingly understandable and simple.
- apfsx 7y ago
  Do you have a video that shows an example of this text entry system? I'm interested in seeing this.
  - triska 7y ago
    Sometimes I see it on terminals for instance when checking into a hotel, opening an account in a bank, booking a flight, interacting with the tax administration etc. One important point that makes them so efficient to use is that everything can be accessed using only the keyboard. For my personal use, I have simulated such forms using Emacs, and especially its Widget Library: https://www.gnu.org/software/emacs/manual/html_mono/widget.html https://www.gnu.org/software/emacs/manual/html_mono/widget.h... This is a bit similar to what you get with a SCREEN SECTION in COBOL.
    - userbinator 7y ago
      Anyone who has used the BIOS setup function of a PC before the EFI bloat took over will find that interface familiar, it's certainly easy to use and quite efficient. Here's an example screenshot: http://www.buildeasypc.com/wp-content/uploads/2011/11/step12_bios_setup_h.jpg http://www.buildeasypc.com/wp-content/uploads/2011/11/step12...
avgDev 7y ago
I am wondering if my old professor answered the call. He used to work in the banking industry, is very outspoken against Capitalism and got fired for wearing jeans. I have been working on a project and have some experience with DB2/AS400, it is not as old as COBOL. It is not very fun or exciting and stackoverflow lacks much information, a lot of trial and error. I can't believe how widespread these old systems are. I am surprised nobody has decided to update them, I mean when these old developers die or retire......they will have a hard time migrating to a newer systems. Bonus: I HATE IBM, .Net Core provider to access database? That is a few $$. Crappy documentation? Check. Deleted code examples I had bookmarked? Check. IBM forum questions answered in private messages, so nobody else can use the information and the question needs to be asked hundreds of times? Check. IBM is so upside down.
- artificial 7y ago
  I thought IBM handles this by making VMs so old things can run on the new(er) things? Isn't it turtles all the way down? I worked for a company that specialized in distribution and circulation software for all the big papers at one point in time or another and it was all COBOL with some of the code bases as old as I was (a handful of engineers remained which laid down a few of them were still on staff, pretty cool resources since they've solved pretty much everything). I bagged a bunch of AS400 operating manuals which were on their way to the trash. I've got one on my shelf I wish I could share with you. Anyway to complete the anecdote one of the younger engineers found their way to greener pastures by creating a screen scraper of sorts for the AS400 to expose it to another API. My mind was blown at the time but it makes sense since these were the webforms of their day.
  - avgDev 7y ago
    In our case we have an IBM iSeries box, AS400 uses DB2 as its database. I am writing an application that communicates with DB2, and I perform a lot of queries directly on the database. We also do have a book on AS400 but most development is done by our old school dev. There is plans to migrate to a newer system but the cost is quite expensive. I mostly work in .Net MVC/Core. However, connecting to db, obtaining licenses, etc have been a real pain.
jerhewet 7y ago
I coded COBOL and RPGII programs back in the late 70's, and I'd flip burgers before writing another line.
- artificial 7y ago
  Thanks for the laugh.
- wglb 7y ago
  And I wonder how the pay compares.
- elliekelly 7y ago
  Oddly enough I suspect you’d have a much harder time getting hired for a burger flipping gig at the moment. What a strange time.
  - DoofusOfDeath 7y ago
    Maybe, maybe not. If we make these (very questionable) assumptions: - Most qualified mainframe COBOL programmers are in an age bracket for which COVID-19 is very dangerous, - and most COBOL shops are reluctant to allow all-remote teams, then it might be harder to fill those jobs than it is to hire risk-tolerant / risk-ignorant young adults to flip burgers.
    - wpietri 7y ago
      For what it's worth, my dad was doing remote COBOL in the early 1980s, so the technology is available.
- downerending 7y ago
  I wouldn't want to spend more time doing it, but I do think today's newbies have missed something in not seeing them and playing with them for a bit.
meerita 7y ago
My father programmed in COBOL, but he never talked me about this. Anyone mind to share his experience? What would be to do this today? is it hard to learn?
- artificial 7y ago
  Evidently it's a faux pas to ask about :P akin to asking veterans about war stories. You may get a kick out of this: http://www.coboloncogs.org/HOME.HTM http://www.coboloncogs.org/HOME.HTM
  - dylan604 7y ago
    The first rule of COBOL programming is you don't talk about COBOL programming. The second rule of COBOL programming is...
- Alex63 7y ago
  I used COBOL on PDP 11/7X (RSTS/E) and VAXen (VMS) back in the 80s, and on IBM mainframes (I graduated in '85). I can't say that I was a big fan of the language, or the SCREEN SECTION specifically. The SCREEN SECTION is basically a description of labels, input fields, and display areas and where they appear on the screen (line, column). The COBOL program can reference the input fields and display areas as a variable. Typically you would use the 'move' statement to copy a value from a variable or a literal to the display variable. I don't know that anyone would ever want to do things the same way today. Today we expect interfaces to adjust to the available screen and font size, which to the best of my recollection was not something that the old COBOL screens could do. There are still 'text-based user interface' tools available, although the modern approach is to link them into the program as a library rather than having them built into the language runtime. The curses (or ncurses) and s-lang libraries are what comes to mind.
- donarb 7y ago
  First you need to order your COBOL coding pads: https://www.ebay.com/c/911841529 https://www.ebay.com/c/911841529
throaway1990 7y ago
COBOL programmers rise!
- avgDev 7y ago
  Back from the dead!
  - DoofusOfDeath 7y ago
    I saw the best minds of my generation destroyed by COBOL copybooks...
codenesium 7y ago
I worked in COBOL at an internship and this was around 2012. This system runs over 1000 court systems in the U.S. It's graphical too and sort of looks like vb6 on the frontend. It was a nightmare to work in even though the team was disciplined and took care of the codebase. You can't write 10k line programs with all global variables and have something that's nice to work on.
- marpstar 7y ago
  AcuCOBOL? I used AcuCOBOL at my internship back in 2009-2010 to build VB6-style forms with COBOL.
  - codenesium 7y ago
    For me it was micro focus Cobol.
    - acdha 7y ago
      MicroFocus bought AcuCorp, so that might have been the same product.
      - techdevangelist 7y ago
        Ah MicroFocus where enterprise products go to die a very slow drawn out death
        droithomme 7y ago
        Ah, so that's why MicroFocus stock suddenly started surging a few days ago. I got stuck with some shares when they spun off from HP. It's my worst performing stock and I couldn't figure out what the heck they did. But now COBOL oriented companies are booming.
- stoksc 7y ago
  My first gig was a HLASM/COBOL internship at an insurance company.. so true, 10k line programs with all globals was the entire codebase. Navigating it with only a 3270 emulator gave me headaches but in a way it was fun. Coding it felt like doing a sudoku.
newprint 7y ago
Just put the entire COBOL source code on the github and let us rework it in the Java or C# and be done with this abomination.
- bluejekyll 7y ago
  Or just put it on github... might find people interested in helping without a full rewrite.
- DoofusOfDeath 7y ago
  Verifying the equivalence of two large programs can be very difficult. Developers often underestimate the effort needed to achieve a correct rewrite.
  - aNoob7000 7y ago
    Exactly and figuring out all the logic with code that's been refined and built out of 20-30 years. Any developer saying, "Hey, go and rewrite the code" underestimate all the edge cases that end up all over the place in the application.
- brobinson 7y ago
  If I were doing financial stuff, I'd probably use a language with a better type system than Java or C#
  - hashbig 7y ago
    Like what?
    - brobinson 7y ago
      Anything to the right of Rust on the type safety spectrum... F#, OCaml, Haskell, etc. Compile-time guarantees of runtime type safety are :100: when dealing with money and other critical things. Search for "jane street ocaml" and "standard chartered haskell" for examples of companies using languages with good type systems in financial code.
kristopolous 7y ago
I asked a few friends about the New Jersey call. They (2 of them, both retired and over 70) claimed there's no work to be done and it's actually an incompetently administered administration with human problems who are scapegoating the technology. Also supposedly the New Jersey govt sacked their team and then was trying to contract out the work at $50/hr. Now they are offering $0/hr. And the solution isn't in software, or so they claimed. This assessment was after both signed up to volunteer to do the work and saw it was a human process failing and not a software issue. People tend to point to the parts most mysterious to them when things start to fail - a zSeries frame is in actual reality, a very important big black mystery box that officials with access to microphones are not allowed to touch - perfect. Don't let this discourage you though, their problems are still very real.
- zamadatix 7y ago
  "Human problems" is even more vague than "software issues". Any details as to what in the process is actually the bottleneck or failing?
  - deleted 7y ago
    [deleted]
  - chrisfinazzo 7y ago
    No piece of software survives contact with humans.
- DoofusOfDeath 7y ago
  > Don't let this discourage you though, their problems are still very real. Is that statement directed a programmers who want to help NJ? Because you made a pretty good argument earlier in your post that this isn't a software development problem.
  - kristopolous 7y ago
    The opinions of two people hardly can be considered as constituting any true reality. I'd love for them to be wrong, that'd be great.
themodelplumber 7y ago
We should have a celebratory COBOL-thon this weekend. Everyone write a minimal COBOL app. Just for fun. Not sure if the COBOL bridge for Node is allowed. :-) Resources: https://opensource.com/life/15/10/open-source-cobol-development https://opensource.com/life/15/10/open-source-cobol-developm... https://archive.org/search.php?query=COBOL%20programming https://archive.org/search.php?query=COBOL%20programming
- chx 7y ago
  And what about https://github.com/azac/cobol-on-wheelchair https://github.com/azac/cobol-on-wheelchair ? display "content-type: text/html" newline end-display. Most of your webapp is already done :D
- plughs 7y ago
  Step 1: Write a JetBrains Cobol plugin
e_commerce 7y ago
Any entity still using COBOL should shut down immediately. Use of this language implies a shocking lack of concern for software from leaders.
hestefisk 7y ago
Can any of you seasoned COBOL programmers in here please point to the best learning resources for this? I would love to learn it but I don’t have any old IBM mainframes lying around.
- my_usernam3 7y ago
  Pretty sure you can practice locally on any machine. The few people I know working with COBOL use virtual machines on modern computers before pushing to production. Also, I'm sure if you search "COBOL tutorials" on the engine of choice, you'll find tons of stuff.
- rbanffy 7y ago
  GNU COBOL runs on pretty much anything. You can play with it right now. No need for a mainframe. In fact, a lot of COBOL code running these days is not running on mainframes. Mainframes are not big Unix boxes. Their OSs were evolving for decades before Unix booted for the first time and are very different from anything most people have direct experience with. You can boot up a legal copy of MVS 3.8j (or an illegal one of its modern descendant z/OS) but expect a learning curve. You can also get something similar from Unisys for their Clearpath machines.
  - Aloha 7y ago
    The thing that struck me from coming from a unix background was that the entire OS was record aware, all the native tools, everything. Stuff that is just hard in unix is trivial in z/OS
    - deleted 7y ago
      [deleted]
    - Taniwha 7y ago
      Having grown up in the older 'record aware' systems unix bytestreams were a wonderful breath of fresh air (this was back in v6/v7) - I guess perspective is everything
yingw787 7y ago
I wonder if I'm personally addicted to easiness. I stand on the shoulders of giants and I forget just how nice it is to dig my toes into the soil. I have a full set of Donald Knuth's "The Art of Computer Programming" sitting on my shelf, unopened after two years. Maybe it is time to rifle through it and learn how to program like the pioneers did in the old days.
- dylan604 7y ago
  Just remember, it was uphill both ways when those guys walked to work. They also could only write code by candle light.
- Alex63 7y ago
  No criticism of TACP intended, but I don't think you would find it very helpful in learning "how to program like the pioneers did in the old days." I don't remember too many of my older colleagues in the 1980s having copies of Knuth. It was something you might encounter among computer scientists, but not day-to-day working programmers. We rarely thought about algorithms in that way when we were building business systems. If we did need an algorithm (maybe to sort some customer records that were stored on tape) we would dig out the IBM or DEC binders and look up the system call that we were supposed to use. I suspect that programmers who have grown up in the era of the PC would be surprised at how much the vendors supplied. The IBM mainframes came with huge libraries of software and documentation. I remember being given a UNIX box for a project at the telco where I worked, and being a little surprised at how little was included compared to the IBM or DEC machines of the day. There certainly were some good programmers around, but a lot of "development" consisted of taking a copy of some existing COBOL program and tweaking a few things to create a new report. Out of two or three years of working in COBOL, I don't think I ever wrote a program completely from scratch. As a creative outlet, it was much more interesting to work in C and try to figure out how the guys at Bell Labs were doing things. Those are the shoulders that many of us stand on today.
neonate 7y ago
https://archive.md/ns6F8 https://archive.md/ns6F8
dang 7y ago
Robert Glass wrote a series of articles in the 80s and 90s defending COBOL. I once wrote him (the old fashioned way, with an enclosed check!) to get back issues of his old printed newsletter because I wanted to hear what he had to say about it. Those don't appear to be online, but here's an article he wrote in 1997 for CACM: https://www.thefreelibrary.com/Cobol+-+a+contradiction+and+an+enigma.-a020378493 https://www.thefreelibrary.com/Cobol+-+a+contradiction+and+a...
- IggleSniggle 7y ago
  That was honestly a great read. Would love to read the same article but rewritten for today's context. Thanks for sharing it.
  - dang 7y ago
    Glass is probably best known now for his book "Facts and Fallacies of Software Engineering", which is a pretty good entry in a pretty lame genre, which is the attempt to draw meaningful conclusions from the research literature on software engineering. The main lesson of the book is how poor the studies are, but it's still worth reading for his own wisdom.
aazaa 7y ago
It's not so clear that COBOL is to blame: > COBOL “remains one of the fastest programming languages,” said John Zeanchock, associate professor of computer and information systems at Robert Morris University. “We get calls from big companies in Pittsburgh, like Bank of New York Mellon and PNC Bank, looking for COBOL programmers. The limitations of COBOL itself are probably not the problem with New Jersey’s system,” Zeanchock said, adding that a single mainframe computer could probably handle the processing needed for an individual state’s UI unemployment insurance system, even if the number of applications increased tenfold. https://slate.com/technology/2020/04/new-jersey-unemployment-cobol-coronavirus.html https://slate.com/technology/2020/04/new-jersey-unemployment... The article goes on to note: > When it comes to our broken social safety net, COBOL isn’t really the bad guy: blame Congress for underfunding the programs, and states for failing to make up the gaps. And later: > “We’ve known for a long time that even a much smaller crisis would lead to daunting challenges,” said Dutta-Gupta. He points out that during the Great Recession, state unemployment agencies were so understaffed that their agency heads spent shifts answering applicant phone calls. Even if states weren’t getting federal funding, they still could have paid for better technology with their own tax revenue. According to reporting by the Tampa Bay Times, former Florida Gov. Rick Scott and current Gov. Ron DeSantis ignored repeated warnings that the state’s website barely functioned. This looks a lot less like a computer problem and more of a process and institution problem made much worse by chronic underfunding and understaffing.
- lotsofpulp 7y ago
  > This looks a lot less like a computer problem and more of a process and institution problem made much worse by chronic underfunding and understaffing. It’s a political issue. Some states are broke (e.g. NJ), and some are hell bent on not helping others in society so they handicap social welfare systems (e.g. FL). Real solution won’t come from a few COBOL programmers, it will have to be voters voting in people who will address the issues.
  - pas 7y ago
    How broke is NJ? What could they do? Why aren't they?
zelly 7y ago
If you want me to work on it for free, a mechanism already exists for this. It's called open source. Put the codebase on Github or wherever and I'll contribute.
- rbanffy 7y ago
  The odds that their actual problem is COBOL code and not mismanagement are vanishingly small. That said, if it's paid with public funds, it should be open source.
- dylan604 7y ago
  Or, if you're a resident of NJ, then how about a no-money-exchange deal. I'll do the work, but I won't owe state taxes for the 2020 year. Win-win
Animats 7y ago
COBOL was the first language to take data format seriously, with "records" and a "data division". To some extent, it still is. Look at the gyrations people go through to get Java or Python to talk to an SQL database. The programming language itself has no clue about database layout.
- ptx 7y ago
  Python takes care of the records pretty well with named tuples (and since it's dynamically typed, not knowing the fields until runtime is expected). It doesn't have anything for the query part through, like C# does with LINQ - are you saying that COCOL does? What does this knowledge of database layout look like in COBOL?
  - skissane 7y ago
    > It doesn't have anything for the query part through, like C# does with LINQ - are you saying that COCOL does? What does this knowledge of database layout look like in COBOL? COBOL has built-in support for accessing flat file databases with either sequential or indexed organisation. On many mainframe and minicomputer operating systems, the filesystem provides native support for record-oriented files (with fixed or variable width records) and indexed-key files, and COBOL directly integrates with that. COBOL has syntax for defining nested record structures which was often used to define the data schema for these files. You could store the definitions in a "copybook" (conceptually equivalent to an include file in C/C++) and reuse it in many programs which would manipulate the same files. COBOL itself doesn't directly support "querying", except for the strategies of (1) manually iterating through every record in a sequential file to find matching records or (2) looking up a key-indexed file by its key field. There are commonly implemented extensions to COBOL to access relational databases (SQL), hierarchical databases (e.g. IMS), etc. However, those are not part of the core COBOL language, and comparable facilities are defined for many other languages, so COBOL isn't really unique on that point.
    - ptx 7y ago
      Thanks. It doesn't seem to me that having built-in syntax for this is necessarily a big advantage, since Python can easily and naturally work with such databases using the built-in dbm module in the standard library (and has no need for defining the schema up front): https://docs.python.org/3/library/dbm.html https://docs.python.org/3/library/dbm.html If you do need to define the database schema in code, there are many third-party libraries that allow you to do this cleanly using classes and fields, e.g. Django. Even Java can do this with Hibernate.
hanoz 7y ago
What's the equivalent technology of today to get in on, in order to get some of this kind of money for old rope action in our retirement?
- icedchai 7y ago
  C and Java are going to be around forever.
api 7y ago
Was there a COBOL search light bat signal? Because there should be.
AzzieElbab 7y ago
What exactly are these Cobol programmers supposed to do? Process punch cards manually?
TheYahiaBakour 7y ago
lmao
RickJWagner 7y ago
This seems like the makings of a movie. Along the lines of "Space Cowboys" or maybe another "Grumpy Old Men".
nonamenoslogan 7y ago
I work in County IT in a medium large county in my state, about 110K residents. We just finished a migration from COBOL on HP3000 to SQL+ColdFusion and some ASPX. COBOL is infinitely faster at computation on PARisc than SQL is on Intel; our HP3000 is a 120MHz with 500mb of ram and our Intel stuff is VM on ESXi. Running a tax roll on COBOL for 45K parcels takes a fifth of the time on the HP despite the massive hardware differences!
- sgillen 7y ago
  wow, this feels like a case of really poorly optimized software.
- PaulWaldman 7y ago
  Why was "SQL+ColdFusion and some ASPX" selected as the replacement stack?
  - waynesonfire 7y ago
    yeah, wtf...
  - nonamenoslogan 7y ago
    Two systems, one for Tax/Assessment which was provided by the state is SQL and ASPX and the other which is used for historical inquiry and document generation which is in-house code in SQL and Coldfusion. The ASPX taxing/assessment system is the slow one in comparison when it comes to calculating. The ColdFusion system is not as hindered but its used for making letters and reports, exporting layers to GIS, and generally replacing COBOL-screens for information retrieval. Is/are there better solutions, yes, but I was giving an example rather than critiquing the County’s choice of software that happened well before I came along.
xvilka 7y ago
And at the same time, Gentoo maintainers are reluctant[1][2][3] to update the shipped version of GnuCOBOL. Similar to Fedora/RHEL[4]. And it's far from dead - GnuCOBOL is actively developed[5] and preparing[6] an upcoming release this year. [1] https://bugs.gentoo.org/641888 https://bugs.gentoo.org/641888 (reported 3 years ago!) [2] https://bugs.gentoo.org/685960 https://bugs.gentoo.org/685960 (reported 1 year ago!) [3] https://github.com/gentoo/gentoo/pull/12067 https://github.com/gentoo/gentoo/pull/12067 [4] https://bugzilla.redhat.com/show_bug.cgi?id=1714241 https://bugzilla.redhat.com/show_bug.cgi?id=1714241 [5] https://sourceforge.net/p/open-cobol/code/commit_browser https://sourceforge.net/p/open-cobol/code/commit_browser [6] https://sourceforge.net/p/open-cobol/discussion/cobol/thread/7dc2941f/?page=4 https://sourceforge.net/p/open-cobol/discussion/cobol/thread...
- pas 7y ago
  wow, those gentoo bugs are very disappointing, are they typical of gentoo?
- tasubotadas 7y ago
  Ah. Gentoo. That brings up memories - I've used it as my main OS for ~3yrs. Updating OpenOffice with 4h compilation times used to be fun :). It's great to see that they are alive and kicking.
xyst 7y ago
I would answer the call for 250K, up front.
- snicker7 7y ago
  In NJ, they are asking for volunteers. And they wonder how it got this bad.
  - xyst 7y ago
    It's like an unpaid internship, smh years of "it already works, dont fuck with it" policy and tech illiterate politicians.
joeblau 7y ago
I don't know why New Jersey doesn't just npm install unemployment-benefits-system and be done with it.
- Forge36 7y ago
  Legal click-through requires proper signoff
bobbydreamer 7y ago
“Cobalt” skills. Really. Learning just COBOL is not enough, you will have to learn ISPF, SDSF, JMR, JCL, Db2, CICS, CA7, ENDEVOR. Think about it 40yr old system still running. Amazing right. Pick any language today, write a program little bit enterprise level, will it run for another 40yrs without any major changes.

320 points by furcyd 7y ago

cable2600 7y ago

Someone invent a COBOL to Python converter to get rid of these old dinosaurs IBM Mainframes.

klodolph 7y ago
This is a misunderstanding of the problem. It’s not the fact that it’s COBOL, per se, that’s the problem. The issue is with making changes to an entire system. A program written in COBOL may be at the center of that system, but that program is only one part of it.
deleted 7y ago
[deleted]
nimih 7y ago
Given that the Python foundation has been trying to get folks to run a python-to-python converter for more than a decade and have not completely succeeded, I'm skeptical that an AST transformer is really sufficient for migrating off those legacy systems. More constructively, having worked on a (close to decade-long, by the time I joined) project to migrate a financial institution's business logic off an IBM mainframe onto more modern architecture, my main takeaway was that these systems have worked pretty darn well for decades with relatively little maintenance. The reluctance of companies to migrate god-knows-how-much data, business rules, and institutional knowledge (e.g. of data entry folks, business-level administrators who have to navigate these systems to do their job, etc) off a time-tested system they trust at massive expense, is completely understandable.
lukevp 7y ago
Mainframes aren’t some old crusty thing that’s about to die from all the bugs stuck in the fans or something. We have a cobol system and it runs on modern IBM hardware. Besides, almost everything is virtualized now anyway. The mainframes aren’t the problem, and doing a code conversion of COBOL is not trivial. Their data types are completely at odds to normal data types in modern languages (for example, you can specify a string that is always exactly 30 ascii characters long, the 4th character must be a numeric, the 18th must be ascii but not numeric, the 22nd through 30th must be alphanumeric. All with a native datatype. And that’s just the scalar types, Cobol data types natively support recurrences and redefines and heirarchies. And the language has like 400 keywords.) You end up having to wrap every single line of code in compatibility layers upon compatibility layers, and then it doesn’t even look like python, it just looks like a crappier version of Cobol, to make it function identically. It’s much easier (though more time consuming) to read the code and determine the business rules being enforced and reimplement them in a modern language. I have worked with a lot of Cobol translators and their output is worse than the original code by far. With a lot less confidence and experience with maintaining it.
wiz21c 7y ago
I don't know if it's still true, but COBOL systems were really well optimized for I/O, for performance, etc. Python won't stand a chance...

triska 7y ago

COBOL can be a real pleasure to use. For instance, it allows programmers to quickly create user interfaces by declaratively describing them, in a so called SCREEN SECTION. The resulting interfaces are very efficient for text entry, and allow users to quickly get a lot of work done. The interaction is so much more efficient than what we are used to with current technologies that it can barely be described or thought about in today's terms. Regarding the underlying theme of legacy systems, here is an interesting presentation by Jonathan Blow, citing various examples of earlier civilizations losing access to technologies they once had: https://www.youtube.com/watch?v=pW-SOdj4Kkk https://www.youtube.com/watch?v=pW-SOdj4Kkk I think in terms of user interfaces, we are on a downward path in several important ways, and I highly recommend checking out earlier technologies that were in many ways an improvement over what we are working with today.

adzm 7y ago
I was blown away by some reporting systems in COBOL that were surprisingly understandable and simple.
apfsx 7y ago
Do you have a video that shows an example of this text entry system? I'm interested in seeing this.
- triska 7y ago
  Sometimes I see it on terminals for instance when checking into a hotel, opening an account in a bank, booking a flight, interacting with the tax administration etc. One important point that makes them so efficient to use is that everything can be accessed using only the keyboard. For my personal use, I have simulated such forms using Emacs, and especially its Widget Library: https://www.gnu.org/software/emacs/manual/html_mono/widget.html https://www.gnu.org/software/emacs/manual/html_mono/widget.h... This is a bit similar to what you get with a SCREEN SECTION in COBOL.
  - userbinator 7y ago
    Anyone who has used the BIOS setup function of a PC before the EFI bloat took over will find that interface familiar, it's certainly easy to use and quite efficient. Here's an example screenshot: http://www.buildeasypc.com/wp-content/uploads/2011/11/step12_bios_setup_h.jpg http://www.buildeasypc.com/wp-content/uploads/2011/11/step12...

avgDev 7y ago

I am wondering if my old professor answered the call. He used to work in the banking industry, is very outspoken against Capitalism and got fired for wearing jeans. I have been working on a project and have some experience with DB2/AS400, it is not as old as COBOL. It is not very fun or exciting and stackoverflow lacks much information, a lot of trial and error. I can't believe how widespread these old systems are. I am surprised nobody has decided to update them, I mean when these old developers die or retire......they will have a hard time migrating to a newer systems. Bonus: I HATE IBM, .Net Core provider to access database? That is a few $$. Crappy documentation? Check. Deleted code examples I had bookmarked? Check. IBM forum questions answered in private messages, so nobody else can use the information and the question needs to be asked hundreds of times? Check. IBM is so upside down.

artificial 7y ago
I thought IBM handles this by making VMs so old things can run on the new(er) things? Isn't it turtles all the way down? I worked for a company that specialized in distribution and circulation software for all the big papers at one point in time or another and it was all COBOL with some of the code bases as old as I was (a handful of engineers remained which laid down a few of them were still on staff, pretty cool resources since they've solved pretty much everything). I bagged a bunch of AS400 operating manuals which were on their way to the trash. I've got one on my shelf I wish I could share with you. Anyway to complete the anecdote one of the younger engineers found their way to greener pastures by creating a screen scraper of sorts for the AS400 to expose it to another API. My mind was blown at the time but it makes sense since these were the webforms of their day.
- avgDev 7y ago
  In our case we have an IBM iSeries box, AS400 uses DB2 as its database. I am writing an application that communicates with DB2, and I perform a lot of queries directly on the database. We also do have a book on AS400 but most development is done by our old school dev. There is plans to migrate to a newer system but the cost is quite expensive. I mostly work in .Net MVC/Core. However, connecting to db, obtaining licenses, etc have been a real pain.

jerhewet 7y ago

I coded COBOL and RPGII programs back in the late 70's, and I'd flip burgers before writing another line.

artificial 7y ago
Thanks for the laugh.
wglb 7y ago
And I wonder how the pay compares.
elliekelly 7y ago
Oddly enough I suspect you’d have a much harder time getting hired for a burger flipping gig at the moment. What a strange time.
- DoofusOfDeath 7y ago
  Maybe, maybe not. If we make these (very questionable) assumptions: - Most qualified mainframe COBOL programmers are in an age bracket for which COVID-19 is very dangerous, - and most COBOL shops are reluctant to allow all-remote teams, then it might be harder to fill those jobs than it is to hire risk-tolerant / risk-ignorant young adults to flip burgers.
  - wpietri 7y ago
    For what it's worth, my dad was doing remote COBOL in the early 1980s, so the technology is available.
downerending 7y ago
I wouldn't want to spend more time doing it, but I do think today's newbies have missed something in not seeing them and playing with them for a bit.

meerita 7y ago

My father programmed in COBOL, but he never talked me about this. Anyone mind to share his experience? What would be to do this today? is it hard to learn?

artificial 7y ago
Evidently it's a faux pas to ask about :P akin to asking veterans about war stories. You may get a kick out of this: http://www.coboloncogs.org/HOME.HTM http://www.coboloncogs.org/HOME.HTM
- dylan604 7y ago
  The first rule of COBOL programming is you don't talk about COBOL programming. The second rule of COBOL programming is...
Alex63 7y ago
I used COBOL on PDP 11/7X (RSTS/E) and VAXen (VMS) back in the 80s, and on IBM mainframes (I graduated in '85). I can't say that I was a big fan of the language, or the SCREEN SECTION specifically. The SCREEN SECTION is basically a description of labels, input fields, and display areas and where they appear on the screen (line, column). The COBOL program can reference the input fields and display areas as a variable. Typically you would use the 'move' statement to copy a value from a variable or a literal to the display variable. I don't know that anyone would ever want to do things the same way today. Today we expect interfaces to adjust to the available screen and font size, which to the best of my recollection was not something that the old COBOL screens could do. There are still 'text-based user interface' tools available, although the modern approach is to link them into the program as a library rather than having them built into the language runtime. The curses (or ncurses) and s-lang libraries are what comes to mind.
donarb 7y ago
First you need to order your COBOL coding pads: https://www.ebay.com/c/911841529 https://www.ebay.com/c/911841529

throaway1990 7y ago

COBOL programmers rise!

avgDev 7y ago
Back from the dead!
- DoofusOfDeath 7y ago
  I saw the best minds of my generation destroyed by COBOL copybooks...

codenesium 7y ago

I worked in COBOL at an internship and this was around 2012. This system runs over 1000 court systems in the U.S. It's graphical too and sort of looks like vb6 on the frontend. It was a nightmare to work in even though the team was disciplined and took care of the codebase. You can't write 10k line programs with all global variables and have something that's nice to work on.

marpstar 7y ago
AcuCOBOL? I used AcuCOBOL at my internship back in 2009-2010 to build VB6-style forms with COBOL.
- codenesium 7y ago
  For me it was micro focus Cobol.
  - acdha 7y ago
    MicroFocus bought AcuCorp, so that might have been the same product.
    - techdevangelist 7y ago
      Ah MicroFocus where enterprise products go to die a very slow drawn out death
      - droithomme 7y ago
        Ah, so that's why MicroFocus stock suddenly started surging a few days ago. I got stuck with some shares when they spun off from HP. It's my worst performing stock and I couldn't figure out what the heck they did. But now COBOL oriented companies are booming.
stoksc 7y ago
My first gig was a HLASM/COBOL internship at an insurance company.. so true, 10k line programs with all globals was the entire codebase. Navigating it with only a 3270 emulator gave me headaches but in a way it was fun. Coding it felt like doing a sudoku.

newprint 7y ago

Just put the entire COBOL source code on the github and let us rework it in the Java or C# and be done with this abomination.

bluejekyll 7y ago
Or just put it on github... might find people interested in helping without a full rewrite.
DoofusOfDeath 7y ago
Verifying the equivalence of two large programs can be very difficult. Developers often underestimate the effort needed to achieve a correct rewrite.
- aNoob7000 7y ago
  Exactly and figuring out all the logic with code that's been refined and built out of 20-30 years. Any developer saying, "Hey, go and rewrite the code" underestimate all the edge cases that end up all over the place in the application.
brobinson 7y ago
If I were doing financial stuff, I'd probably use a language with a better type system than Java or C#
- hashbig 7y ago
  Like what?
  - brobinson 7y ago
    Anything to the right of Rust on the type safety spectrum... F#, OCaml, Haskell, etc. Compile-time guarantees of runtime type safety are :100: when dealing with money and other critical things. Search for "jane street ocaml" and "standard chartered haskell" for examples of companies using languages with good type systems in financial code.

kristopolous 7y ago

I asked a few friends about the New Jersey call. They (2 of them, both retired and over 70) claimed there's no work to be done and it's actually an incompetently administered administration with human problems who are scapegoating the technology. Also supposedly the New Jersey govt sacked their team and then was trying to contract out the work at $50/hr. Now they are offering $0/hr. And the solution isn't in software, or so they claimed. This assessment was after both signed up to volunteer to do the work and saw it was a human process failing and not a software issue. People tend to point to the parts most mysterious to them when things start to fail - a zSeries frame is in actual reality, a very important big black mystery box that officials with access to microphones are not allowed to touch - perfect. Don't let this discourage you though, their problems are still very real.

zamadatix 7y ago
"Human problems" is even more vague than "software issues". Any details as to what in the process is actually the bottleneck or failing?
- deleted 7y ago
  [deleted]
- chrisfinazzo 7y ago
  No piece of software survives contact with humans.
DoofusOfDeath 7y ago
> Don't let this discourage you though, their problems are still very real. Is that statement directed a programmers who want to help NJ? Because you made a pretty good argument earlier in your post that this isn't a software development problem.
- kristopolous 7y ago
  The opinions of two people hardly can be considered as constituting any true reality. I'd love for them to be wrong, that'd be great.

themodelplumber 7y ago

We should have a celebratory COBOL-thon this weekend. Everyone write a minimal COBOL app. Just for fun. Not sure if the COBOL bridge for Node is allowed. :-) Resources: https://opensource.com/life/15/10/open-source-cobol-development https://opensource.com/life/15/10/open-source-cobol-developm... https://archive.org/search.php?query=COBOL%20programming https://archive.org/search.php?query=COBOL%20programming

chx 7y ago
And what about https://github.com/azac/cobol-on-wheelchair https://github.com/azac/cobol-on-wheelchair ? display "content-type: text/html" newline end-display. Most of your webapp is already done :D
plughs 7y ago
Step 1: Write a JetBrains Cobol plugin

e_commerce 7y ago

Any entity still using COBOL should shut down immediately. Use of this language implies a shocking lack of concern for software from leaders.

hestefisk 7y ago

Can any of you seasoned COBOL programmers in here please point to the best learning resources for this? I would love to learn it but I don’t have any old IBM mainframes lying around.

my_usernam3 7y ago
Pretty sure you can practice locally on any machine. The few people I know working with COBOL use virtual machines on modern computers before pushing to production. Also, I'm sure if you search "COBOL tutorials" on the engine of choice, you'll find tons of stuff.
rbanffy 7y ago
GNU COBOL runs on pretty much anything. You can play with it right now. No need for a mainframe. In fact, a lot of COBOL code running these days is not running on mainframes. Mainframes are not big Unix boxes. Their OSs were evolving for decades before Unix booted for the first time and are very different from anything most people have direct experience with. You can boot up a legal copy of MVS 3.8j (or an illegal one of its modern descendant z/OS) but expect a learning curve. You can also get something similar from Unisys for their Clearpath machines.
- Aloha 7y ago
  The thing that struck me from coming from a unix background was that the entire OS was record aware, all the native tools, everything. Stuff that is just hard in unix is trivial in z/OS
  - deleted 7y ago
    [deleted]
  - Taniwha 7y ago
    Having grown up in the older 'record aware' systems unix bytestreams were a wonderful breath of fresh air (this was back in v6/v7) - I guess perspective is everything

yingw787 7y ago

I wonder if I'm personally addicted to easiness. I stand on the shoulders of giants and I forget just how nice it is to dig my toes into the soil. I have a full set of Donald Knuth's "The Art of Computer Programming" sitting on my shelf, unopened after two years. Maybe it is time to rifle through it and learn how to program like the pioneers did in the old days.

dylan604 7y ago
Just remember, it was uphill both ways when those guys walked to work. They also could only write code by candle light.
Alex63 7y ago
No criticism of TACP intended, but I don't think you would find it very helpful in learning "how to program like the pioneers did in the old days." I don't remember too many of my older colleagues in the 1980s having copies of Knuth. It was something you might encounter among computer scientists, but not day-to-day working programmers. We rarely thought about algorithms in that way when we were building business systems. If we did need an algorithm (maybe to sort some customer records that were stored on tape) we would dig out the IBM or DEC binders and look up the system call that we were supposed to use. I suspect that programmers who have grown up in the era of the PC would be surprised at how much the vendors supplied. The IBM mainframes came with huge libraries of software and documentation. I remember being given a UNIX box for a project at the telco where I worked, and being a little surprised at how little was included compared to the IBM or DEC machines of the day. There certainly were some good programmers around, but a lot of "development" consisted of taking a copy of some existing COBOL program and tweaking a few things to create a new report. Out of two or three years of working in COBOL, I don't think I ever wrote a program completely from scratch. As a creative outlet, it was much more interesting to work in C and try to figure out how the guys at Bell Labs were doing things. Those are the shoulders that many of us stand on today.

neonate 7y ago

https://archive.md/ns6F8 https://archive.md/ns6F8

dang 7y ago

Robert Glass wrote a series of articles in the 80s and 90s defending COBOL. I once wrote him (the old fashioned way, with an enclosed check!) to get back issues of his old printed newsletter because I wanted to hear what he had to say about it. Those don't appear to be online, but here's an article he wrote in 1997 for CACM: https://www.thefreelibrary.com/Cobol+-+a+contradiction+and+an+enigma.-a020378493 https://www.thefreelibrary.com/Cobol+-+a+contradiction+and+a...

IggleSniggle 7y ago
That was honestly a great read. Would love to read the same article but rewritten for today's context. Thanks for sharing it.
- dang 7y ago
  Glass is probably best known now for his book "Facts and Fallacies of Software Engineering", which is a pretty good entry in a pretty lame genre, which is the attempt to draw meaningful conclusions from the research literature on software engineering. The main lesson of the book is how poor the studies are, but it's still worth reading for his own wisdom.

aazaa 7y ago

It's not so clear that COBOL is to blame: > COBOL “remains one of the fastest programming languages,” said John Zeanchock, associate professor of computer and information systems at Robert Morris University. “We get calls from big companies in Pittsburgh, like Bank of New York Mellon and PNC Bank, looking for COBOL programmers. The limitations of COBOL itself are probably not the problem with New Jersey’s system,” Zeanchock said, adding that a single mainframe computer could probably handle the processing needed for an individual state’s UI unemployment insurance system, even if the number of applications increased tenfold. https://slate.com/technology/2020/04/new-jersey-unemployment-cobol-coronavirus.html https://slate.com/technology/2020/04/new-jersey-unemployment... The article goes on to note: > When it comes to our broken social safety net, COBOL isn’t really the bad guy: blame Congress for underfunding the programs, and states for failing to make up the gaps. And later: > “We’ve known for a long time that even a much smaller crisis would lead to daunting challenges,” said Dutta-Gupta. He points out that during the Great Recession, state unemployment agencies were so understaffed that their agency heads spent shifts answering applicant phone calls. Even if states weren’t getting federal funding, they still could have paid for better technology with their own tax revenue. According to reporting by the Tampa Bay Times, former Florida Gov. Rick Scott and current Gov. Ron DeSantis ignored repeated warnings that the state’s website barely functioned. This looks a lot less like a computer problem and more of a process and institution problem made much worse by chronic underfunding and understaffing.

lotsofpulp 7y ago
> This looks a lot less like a computer problem and more of a process and institution problem made much worse by chronic underfunding and understaffing. It’s a political issue. Some states are broke (e.g. NJ), and some are hell bent on not helping others in society so they handicap social welfare systems (e.g. FL). Real solution won’t come from a few COBOL programmers, it will have to be voters voting in people who will address the issues.
- pas 7y ago
  How broke is NJ? What could they do? Why aren't they?

zelly 7y ago

If you want me to work on it for free, a mechanism already exists for this. It's called open source. Put the codebase on Github or wherever and I'll contribute.

rbanffy 7y ago
The odds that their actual problem is COBOL code and not mismanagement are vanishingly small. That said, if it's paid with public funds, it should be open source.
dylan604 7y ago
Or, if you're a resident of NJ, then how about a no-money-exchange deal. I'll do the work, but I won't owe state taxes for the 2020 year. Win-win

Animats 7y ago

COBOL was the first language to take data format seriously, with "records" and a "data division". To some extent, it still is. Look at the gyrations people go through to get Java or Python to talk to an SQL database. The programming language itself has no clue about database layout.

ptx 7y ago
Python takes care of the records pretty well with named tuples (and since it's dynamically typed, not knowing the fields until runtime is expected). It doesn't have anything for the query part through, like C# does with LINQ - are you saying that COCOL does? What does this knowledge of database layout look like in COBOL?
- skissane 7y ago
  > It doesn't have anything for the query part through, like C# does with LINQ - are you saying that COCOL does? What does this knowledge of database layout look like in COBOL? COBOL has built-in support for accessing flat file databases with either sequential or indexed organisation. On many mainframe and minicomputer operating systems, the filesystem provides native support for record-oriented files (with fixed or variable width records) and indexed-key files, and COBOL directly integrates with that. COBOL has syntax for defining nested record structures which was often used to define the data schema for these files. You could store the definitions in a "copybook" (conceptually equivalent to an include file in C/C++) and reuse it in many programs which would manipulate the same files. COBOL itself doesn't directly support "querying", except for the strategies of (1) manually iterating through every record in a sequential file to find matching records or (2) looking up a key-indexed file by its key field. There are commonly implemented extensions to COBOL to access relational databases (SQL), hierarchical databases (e.g. IMS), etc. However, those are not part of the core COBOL language, and comparable facilities are defined for many other languages, so COBOL isn't really unique on that point.
  - ptx 7y ago
    Thanks. It doesn't seem to me that having built-in syntax for this is necessarily a big advantage, since Python can easily and naturally work with such databases using the built-in dbm module in the standard library (and has no need for defining the schema up front): https://docs.python.org/3/library/dbm.html https://docs.python.org/3/library/dbm.html If you do need to define the database schema in code, there are many third-party libraries that allow you to do this cleanly using classes and fields, e.g. Django. Even Java can do this with Hibernate.

hanoz 7y ago

What's the equivalent technology of today to get in on, in order to get some of this kind of money for old rope action in our retirement?

icedchai 7y ago
C and Java are going to be around forever.

api 7y ago

Was there a COBOL search light bat signal? Because there should be.

AzzieElbab 7y ago

What exactly are these Cobol programmers supposed to do? Process punch cards manually?

TheYahiaBakour 7y ago

lmao

RickJWagner 7y ago

This seems like the makings of a movie. Along the lines of "Space Cowboys" or maybe another "Grumpy Old Men".

nonamenoslogan 7y ago

I work in County IT in a medium large county in my state, about 110K residents. We just finished a migration from COBOL on HP3000 to SQL+ColdFusion and some ASPX. COBOL is infinitely faster at computation on PARisc than SQL is on Intel; our HP3000 is a 120MHz with 500mb of ram and our Intel stuff is VM on ESXi. Running a tax roll on COBOL for 45K parcels takes a fifth of the time on the HP despite the massive hardware differences!

sgillen 7y ago
wow, this feels like a case of really poorly optimized software.
PaulWaldman 7y ago
Why was "SQL+ColdFusion and some ASPX" selected as the replacement stack?
- waynesonfire 7y ago
  yeah, wtf...
- nonamenoslogan 7y ago
  Two systems, one for Tax/Assessment which was provided by the state is SQL and ASPX and the other which is used for historical inquiry and document generation which is in-house code in SQL and Coldfusion. The ASPX taxing/assessment system is the slow one in comparison when it comes to calculating. The ColdFusion system is not as hindered but its used for making letters and reports, exporting layers to GIS, and generally replacing COBOL-screens for information retrieval. Is/are there better solutions, yes, but I was giving an example rather than critiquing the County’s choice of software that happened well before I came along.

xvilka 7y ago

And at the same time, Gentoo maintainers are reluctant[1][2][3] to update the shipped version of GnuCOBOL. Similar to Fedora/RHEL[4]. And it's far from dead - GnuCOBOL is actively developed[5] and preparing[6] an upcoming release this year. [1] https://bugs.gentoo.org/641888 https://bugs.gentoo.org/641888 (reported 3 years ago!) [2] https://bugs.gentoo.org/685960 https://bugs.gentoo.org/685960 (reported 1 year ago!) [3] https://github.com/gentoo/gentoo/pull/12067 https://github.com/gentoo/gentoo/pull/12067 [4] https://bugzilla.redhat.com/show_bug.cgi?id=1714241 https://bugzilla.redhat.com/show_bug.cgi?id=1714241 [5] https://sourceforge.net/p/open-cobol/code/commit_browser https://sourceforge.net/p/open-cobol/code/commit_browser [6] https://sourceforge.net/p/open-cobol/discussion/cobol/thread/7dc2941f/?page=4 https://sourceforge.net/p/open-cobol/discussion/cobol/thread...

pas 7y ago
wow, those gentoo bugs are very disappointing, are they typical of gentoo?
tasubotadas 7y ago
Ah. Gentoo. That brings up memories - I've used it as my main OS for ~3yrs. Updating OpenOffice with 4h compilation times used to be fun :). It's great to see that they are alive and kicking.

xyst 7y ago

I would answer the call for 250K, up front.

snicker7 7y ago
In NJ, they are asking for volunteers. And they wonder how it got this bad.
- xyst 7y ago
  It's like an unpaid internship, smh years of "it already works, dont fuck with it" policy and tech illiterate politicians.

joeblau 7y ago

I don't know why New Jersey doesn't just npm install unemployment-benefits-system and be done with it.

Forge36 7y ago
Legal click-through requires proper signoff

bobbydreamer 7y ago

“Cobalt” skills. Really. Learning just COBOL is not enough, you will have to learn ISPF, SDSF, JMR, JCL, Db2, CICS, CA7, ENDEVOR. Think about it 40yr old system still running. Amazing right. Pick any language today, write a program little bit enterprise level, will it run for another 40yrs without any major changes.