Bankdata is one of the largest specialist IT services providers of Denmark that provides core services (both front-end and back-end) to banks. Bankdata leverages several Open Mainframe Project technologies to power these services.
When asked about the importance of the mainframe in the modern world, Rune Christensen, Lead Software Developer at Bankdata, says, “The mainframe is definitely powering the modern economy. At the moment, by far, most of our software runs on a mainframe with the CICS transaction-based services, both REST and SOAP services.”
Christensen specifically talks about Open Mainframe’s COBOL Programming Course, COBOL Check and Zowe and Bankdata contributes to these projects.
Watch this episode of Mainframe Matters or read snippets of the interview with Rune Christensen below to learn more about how Open Mainframe Project can help all those who are using COBOL in their infrastructure.
About Bankdata:
Bankdata is a software developing company that is owned by a number of banks, and we provide back-end services and front-end services for these banks. It is one of Denmark’s largest IT companies with approx. 900 employees and a turnover of 1.7 billion. kroner. Bankdata has an office in the IT city in Aarhus as well as Silkeborg and Fredericia. Bankdata’s solutions are used every day by 1.6 million Danes and a small 200,000 traders.
Bankdata offers the entire tool case for these banks, including mobile applications for U&I. We support that and develop that. We develop the applications that their bank employees use on a day-to-day basis. So everything from account transfers to buying and selling of stocks and so on.
Bankdata uses COBOL for the back-end services that our front-end calls. So if you’re doing a money transfer between two accounts, well, that includes a call to a back-end service. And that back-end service is in COBOL, running on a KICKS.
Challenges:
One of the greatest challenges we see in using COBOL is actually hiring new developers and getting them to use it. The interfaces for programming hasn’t evolved as fast for COBOL as it has for, for example, Java. So for a long time, we’ve been relying on a IDE that is in ISPF on the mainframe instead of, for example, Visual Studio Code.
Another challenge is that a lot of students haven’t heard about mainframe and haven’t heard about… Actually, haven’t heard about transaction processing when they’re getting their education. They have a lot of great theoretical knowledge, but the practical knowledge with transaction-based processing and how you have to manage that is something we really need.
Solution:
We are using the Open Mainframe Project’s COBOL Programming Course. For all our new employees, developers, we are recommending this simple and easy course that has hands-on training. There are a number of other projects out there, but the Open Mainframe Project’s COBOL Programming Course ties well into Visual Studio Code, which we are trying to move our software, our COBOL developers towards. So those two things fit very well together.
We are also heavily invested in the COBOL Check application, which is a unit testing for COBOL. And I believe we’re on version 2.1, 0.2.1 right now. And at some point we should be able to integrate the unit testing into the COBOL Course. So us, using Visual Studio Code together with the COBOL Course and the move we are doing right now, of trying to get our developers into using Visual Studio Code with COBOL is part of our movement, our journey towards enabling our developers, towards enabling new developers, new employees to learn COBOL faster and be able to produce code faster than before because we are avoiding the steep learning curve of the mainframe. Here is Visual Studio Code. You’re using Git, as you know from everywhere else. Yeah, get on cracking. Get on coding.
We’re involved in the project called COBOL Check. We’ve been contributing a lot the last year to that project and has been the main drive for moving the project from a non-released version to the release that we have now, which actually is a fully functional unit testing tool. It doesn’t have all the polish that other tools have yet, but you can definitely use it to test your COBOL and use it to verify that your code works.
One of the interests, we’ve been getting for this tool is a website called Exercism, and they’re providing exercises in different languages. They just added COBOL because we’ve created the COBOL Check framework. So you can actually go to Exercism.org, and try out COBOL and run your unit tests using COBOL Check from the Open Mainframe Project. At Bankdata, we’ve integrated COBOL Check in our Visual Studio Code installation.
Actually, COBOL Check comes with its own extension for Visual Studio Code with highlighting for the syntax in COBOL Check and a nice displaying of the results from our unit tests. So we are heavily pushing unit tests to our COBOL developers to enable them to shift left and test earlier and more often. This ties into the pipeline we’ve made from our Git repositories. So when a developer has pushed COBOL source to a Git repository, they also push the unit test to that repository. And when that source is pushed to the mainframe, the part of the pipeline runs those unit tests and makes sure that they all pass.
I believe COBOL Check can help anybody doing COBOL source, COBOL code, not necessarily for the mainframe but for any COBOL application because there is no other unit testing tool out there that enables you to do the shift, lift that we are experiencing a lot of industries moving towards. We want to test often. We want to test early, and we want it to be cheap and fast. There are a lot of other testing tools for COBOL, and they’re great. No questions about it, but they’re testing their entire program.
What we are testing in COBOL Check is the paragraph or the section. We are testing two lines of code or even one line of code at one time. So if you have a complex evaluate structure, you don’t have to run your entire program. You can actually just build a test and just test that section for that evaluate structure.
Another thing, this pipeline is primarily built on top of Zowe. So moving source code to the mainframe, running the compile on the mainframe, making sure load modules are in the right place, that’s all done through Zowe. When the pipeline runs on our mainframe… No. When the pipeline has deployed to our staging development on the mainframe, we are not done yet because to push to production, we, of course, have another pipeline. And in that pipeline, we’re actually able to use IBM’s debugger to calculate code coverage from the unit tests. We are delivering those data back to the developers and back to our leaders and directors in Grafana dashboards, so they can follow the progress of their unit tests.
Future plans:
COBOL Check is in a very good position as it is right now. What we are missing, though, is polish. We need help getting to a level where we can say that we can release this in a version 0. by 1.0 instead of having a version that is actually still in beta. We would very much like to be able to run tests on a mainframe before accepting pull requests, but we haven’t been able to do that at the moment. We would like improved integration with Visual Studio Code and also with other tools, if possible. There’s no reason that we should limit ourselves to that IDE. So there are still a lot to be done and a lot of improvements that can be done.
