When do the mainframe and COBOL die

COBOL is considered out of date by many. The programming language can only be used for the mainframe and only to a limited extent there because it cannot be integrated into modern IT systems. COBOL-works refutes a large part of these prejudices and shows why it is still immensely important today to continue to build on COBOL.

Word has not yet got around that today's COBOL standards can keep up with other languages ​​and that modern compilers are compatible with all common databases and interfaces.

  • Nobody needs COBOL these days.

    Many companies - primarily from the public sector, banks and insurance companies, from the tourism and telecommunications sector as well as many industrial companies - have always processed their business data with programs that are essentially based on COBOL and run on mainframe and LUW systems. In addition, there are thousands of software and system houses (ISVs) who develop their applications or parts of them in COBOL. There they are called together with newer applications, which are mostly written in Java, C ++ or C #. The fact that COBOL is still so widespread today may be due to the sheer risk that new developments pose. But above all, the widespread use is due to the advantages of COBOL, which even modern Java cannot match. Experienced developers consider COBOL to be extremely clear and flexible. Especially when stringent data is to be processed, COBOL still has a clear advantage over C or Java today.

  • COBOL is a language for mainframes. With the mainframes, COBOL will soon die too.

    This statement is not correct. With the high performance of modern mid-size systems (LUW), many IT departments are saying goodbye to their mainframes and are switching to smaller, open systems. They are cheaper to maintain. Few people know that they can continue to rely on the tried and tested logic of their COBOL applications there. With the smaller computers, you save twice as much, because the reprogramming of the applications, which is often considered necessary, can be dispensed with thanks to modern modernization and rehosting tools. Companies like COBOL-works have specialized in modernizing tried and tested programs. In addition, in times of attacks on cloud systems and eavesdropping activities by the NSA or other secret services, a rising rather than falling demand for mainframe or non-stop systems can be assumed.
    COBOL is by no means a pure mainframe language, but is understood today with all common platforms, be it Unix, Linux or Windows in 32 or 64 bit. The COBOL-IT compiler, for example, is available for 6 different platforms and for all forms of data management (ISAM, RDBMS, network / hierarchical as well as NoSQL data management) and for all character sets such as ASCII, ANSI, EBCDIC and Unicode.

  • With COBOL developers dying out, IT departments are forced to switch horses.

    A disadvantage of COBOL that cannot be completely dismissed at first glance is the increasing age of those who have learned to develop in this language. Of the 357 IT professionals who were asked about the use of COBOL in their companies as part of a survey * by Computerworld magazine in May 2012, 46% said they felt a decrease in the availability of COBOL programmers. 50% said their COBOL developers were 45 years of age or older, and just under a fifth said the average age was 55. Only a few companies train new COBOL developers. COBOL is simply not considered sexy enough by many. Service providers such as COBOL-works GmbH, which continues to employ and train COBOL developers and have opened up a growing market for themselves, show that this does not have to be the case. The Computerworld study found that four fifths of all respondents have outsourced the maintenance of their COBOL applications. Because while the absolute share of COBOL installations according to the US opinion research institute Gardner has slightly decreased worldwide with an estimated -5% in the past few years, thousands upon thousands of COBOL programs still process tasks so reliably that it often makes sense to to get them. Because nowadays COBOL logic can be encapsulated, relocated to other systems and operated there in combination with C # or Java applications. The real challenge is not in the COBOL language - it can be learned in a few months - but in the fact that the applications run, need to be administered, maintained and developed in complex environments. These complex environments must be mastered - regardless of the language!

  • COBOL cannot be integrated into modern environments.

    Wrong: With Eclipse- or Visual-Studio-based development environments, there are now mature development and migration tools that can transfer planned and step-by-step core processes of development as well as production, operation e.g. to Java or .NET. COBOL code can be translated as part of a higher-level project and later either switched off step by step or encapsulated and integrated into other code. This means that a modern interface can also be created for well-tried applications and, thanks to numerous interfaces, can be connected to modern environments. Applications for the web and modern end devices can also be used in this way.

  • The compilers are simply too expensive for the purposes for which we still need COBOL.

    The traditional use of COBOL in large IT infrastructures in the past meant that COBOL compilers and the products associated with them were actually in higher price ranges. With the open source based compilers from COBOL-IT, companies do not have to get an expensive all-round package that they don't need. In contrast to many other compilers, COBOL-IT is sold as part of a so-called subscription. That means: companies acquire the rights of use and the associated support only for the modules (compiler, precompiler, IDE etc.) that they need and only for as long as they are in use. This drastically reduces acquisition costs, and companies can react flexibly to changes in their IT landscape.

  • We don't even know how much COBOL code we have. Hopefully nobody has to answer it.

    In fact, many companies have been using COBOL programs quietly for decades. Modernizations are therefore often delayed until companies are forced to replace large parts of their infrastructure. Be it because the economic constraint is too great, because support for other software tools or modules is discontinued, or because compatibility with modern OS and development platforms is required. Since these decisions are serious, independent solution providers should be brought on board who are familiar with the tasks involved and who can support other companies in their decision-making.

  • The standards are out of date.

    Wrong: Even after more than 50 years, the COBOL standard is still being adapted. The latest COBOL standard was adopted in 2002. In addition to numerous specifications, international character sets (UTF-8), object-oriented programming and conditional compilation were included in the standard. A version planned for 2010 is still waiting to be completed. All common compilers are compatible with ANSI85. Most of the declarations from COBOL 2002 are also supported.

  • COBOL does not understand object orientation.

    Wrong: The COBOL standard ISO 2002 COBOL understands object orientation very well.

  • It is cheaper to rewrite applications than to keep maintaining COBOL code.

    One might think so. But experience shows that the opposite is the case. In practice, reprogramming in Java or C # is associated with a considerable technical and therefore financial risk. Many logics can be implemented much less elegantly in the more recent languages. The decision for or against a future with COBOL should therefore be made in conjunction with migration experts. As a rule, the result is not a hop-or-top decision, but a migration project that is precisely timed in terms of time and content and preceded by a comprehensive analysis of the IT infrastructure. At the end of the project there is an application consisting of COBOL and the "new" languages.