A Node.js bridge for COBOL
github.com
github.com
I expect in some bank somewhere, node.js-COBOL integration really happens, but more commonly using web services (REST or SOAP). Take the legacy COBOL application, turn it into a web service, then clients like node.js can call it. Popular COBOL application frameworks – such as CICS and Tuxedo – include support for writing SOAP and REST web services in COBOL, which are generally used to add web service endpoints to existing COBOL applications.
The Cobol guys liked to mock the Java team. They said that Java was slow. They pointed to how our system interacted with theirs. So one day for UAT I got permission to make async calls to their services. BAM! Mainframe was hit hard. The Cobol guys were swearing. They couldn't understand what nearly took down their system. Turns out all it took was a thread pool of 100. We ended up using the async wrappers around time-sensitive sections with only 10 or so threads, if I recall properly.
"JavaScript developer breaks all mainframes on the planet by withholding LEFTPAD.CBL"
'node -e "' + code + '"'
https://github.com/IonicaBizau/node.cobol/blob/master/lib/no...
CALL 'EXEC_NODEJS_FILE' USING "example/server.js".
I think I found another bug too, my only experience with cobol is the 10 minutes spent trying to understand this, so maybe someone can explain? Since in EXEC_NODEJS, NODEJS_CODE is defined as "NODEJS_CODE PIC A(100)", doesn't that limit it to 100 alphabetic characters, so even the example of "console.log('Hello World!')" would not work because of the period, parentheses, and exclamation mark?
That said, COBOL is weakly typed, so you can probably store non-alphabetic characters in a variable typed as alphabetic (at least without the compiler correcting you), but it might fail if you try to do certain operations on them.
No seriously. I'm sure there is a need for a cobol bridge, just surprised to see it pop up.
Note it’s a Node bridge, i.e. call Node from COBOL, not the other way around.
One thing for sure: I will find a way to use this somehow. :)
In seriousness: My dad was a COBOL programmer for about 30 years. It would frustrate him to no end to look upon Javascript programmers and to tell him, "these guys are going to be working on your code now."
I'd never advocate COBOL or anything, but I'm just saying that it took a certain breed of person to do it, and that those people aren't around anymore is a sad thing.
What would be this "breed" of person you saying? Could you elaborate on this? I'm genuinely curious
The application I was working on, which had a C++ front end for a mainframe with three databases involved caused an IMS segment to crash. The guy who saw the message got in touch with our senior user and discovered exactly who was doing something to cause the IMS segment to crash. This was at about 4:30 on a Friday in a corporate government type office where about 4 out of 5 people had already gone home.
Within 30 minutes he had examined the crash dump, pulled out the COBOL program that had caused the issue and found the constant that had been set 20 years ago that had now been validated. He quickly go the user to alter the case so it didn't happen and he and I put in place new higher constants to protect the data from being damaged in future.
It was damn impressive.
But well, there are guys like Raymond Chen at MS who can do this for windows programs and in about 20 years, when node.js often means terrible hacked together code there will be JS gurus who can do the same.
But if the mainframe systems are still in operation, we have to hope those COBOL guys are still around.
Has this been similar to your experience? I'm just curious because it's not a very typical thing, square peg in a round hole sort of situation.
Those same corporations are also not blind to the fact that most of their COBOL workforce will be retiring, en mass, in the coming years, and are quite desperate to hire anyone willing to learn. My employer paid for me to attend a 3 month training program in order to learn how to use and develop on the IBM zSeries mainframe. It was a fantastic experience. As well, those same companies are looking to move as much of their COBOL code off of the mainframe and onto a distributed, server platform. While you can't beat the sheer power of Big Iron chugging along through a batch cycle, the CICS user interface leaves a lot to be desired. It's much more cost and time effective to build a web interface that talks to a Java middle-layer that lives on the mainframe (such that it can directly talk with DB2 or some such), compared to designing, building, and testing a CICS program to do the same thing, yet in a much more ugly fashion.
I'm actually in the process of getting involved with the US Army now (I'm 21) so that I can get some schooling and stuff done later, but I've thought that I might spend my off-time for the next few years trying to self-teach myself NetREXX or something and try to land a job in some MegaCorp. I'm not opposed to writing code all day in a comfy office chair with full benefits etc, especially compared to living in a dorm with couple dudes eating Ramen and trying to conquer Web 4.0 or whatever. Just doesn't appeal to me.
It's reassuring that it's a viable career path, I hadn't thought much about the new generation of mainframe maintenance, but from what my dad has told me about some of the people he's worked with it certainly makes sense that these big corps would be desperate for fresh meat right about now.
Downside of course is COBOL, Java, etc. But it's not like it's going anywhere soon. Nobody really wants to replace millions of lines of COBOL that work, and work well.
Writing a compiler for an ML-ish language that targets COBOL would be kind of amusing. Just because they're stuck with COBOL doesn't mean it has to be hand-written, right?
Disclaimer: I don't work with mainframes but I know people who do. Friend of mine quite likes writing assembly for z/Architecture. I don't know if she's totally sane.
However, rewriting 30+ years of legacy code was very difficult. The place had tried and failed on two occasions so far to do it.
It seemed a bit like the airline reservation software system GDS and how it's still around.
But mainframe sucks. Nobody gets into it cause the like it, they just need a job. I'd like to see a startup that sells mainframe software, cause they'd be be like one of 3 people.
Retooling all of that is hard, and while avoiding that problem they kind of set themselves up to those legacy problems. Java shops kinda have seen the same thing except that while Java grew with the times, COBOL and friends just stagnated. The world kept turning though, and that's brought us to the situation of these 40 year programmers leaving behind forty years of code that basically only THEY can really understand.
Where I worked people were always saying how they'd like mainframe people and would train them up but when actually asked about training, well, things became quieter.
;-)
[1]: https://en.wikipedia.org/wiki/Age_disparity_in_sexual_relati...
I figure anybody complaining is probably just jealous. But I'm close to 50 than 20 myself, so I'm not exactly unbiased. :-)
While standards for beauty may change to some extent across cultures and time, the attraction based on age has been very constant. In addition to the biological health of the species, humans perception of the world tend to change as they age. People of more similar age are more likely to have compatible and relatable life experiences and views (try explaining what the world was like before 9/11 to a teenager. They simply don't understand the huge shift in culture that resulted because they weren't aware of the world at that time and only know the world as it is today)
Ageism and sexism are problems in some areas, but biological attraction when forming relationships is not one of those areas.