devopsy.kinsta.cloud

Tag: COBOL

  • Choosing the Right Programming Language

    Choosing the Right Programming Language

    In software engineering, selecting a programming language is a pivotal decision for any organization. The appropriate language contributes to a streamlined development workflow and yields a resilient software solution that facilitates swift and efficient debugging, documentation, enhancement and maintenance. On the other hand, selecting an unsuitable language can set a project on a course for failure from the onset. Given the multitude of available options and the magnitude of this decision, how can programmers ensure they make the most judicious language choice?

    A comprehensive and effective decision-making process begins with a thorough understanding of the current landscape, historical context and the evolutionary trajectory of programming languages. It is also imperative to critically appreciate the benchmarks employed by computer scientists and the industry’s best practices in language selection. Programmers who invest time to enhance their expertise in these domains will mitigate the risk of selecting a language deficient in essential features or one poised for obsolescence, thereby safeguarding the resulting product’s longevity, relevance and success.

    The evolution of programming languages

    Charles Babbage is credited with creating the first computer between 1833 and 1871. He spent nearly 40 years perfecting his invention, which ultimately could perform simple calculations. While Babbage is recognized for building the initial computer, in 1883, Ada Lovelace played a pivotal role by devising the programming language for Babbage’s invention. Today, 140 years later, more than 500 distinct programming languages facilitate human-computer interaction. The continuous adaptation and innovation of programming languages have paralleled the dynamic evolution of technology.

    Contemporary programming languages, such as Swift, Kotlin and Go, exhibit more user-friendly syntax and enhanced ease of use than their predecessors, including SQL, MATLAB and C. Recent languages often integrate features that were unavailable just a few years ago. As such, programmers have the ability to select from a diverse array of languages, identifying the most suitable for their project that facilitates the efficient completion of tasks. For example, Swift is used in Mac and iOS platforms, C# is tailored for the .NET Framework and JavaScript, renowned for constructing the internet, is a testament to the varied roles these languages play in diverse technological domains.

    Selecting the right programming language

    With vast options of programming languages available, one of the greatest challenges is determining which is best suited for a particular project. Comparing the various features and syntaxes of languages can be complicated. Based on recent industry trends, Table 1 details the key programming languages in popular areas/domains.

    Area/Domain

    Programming Languages

    Web development

    JavaScript, Java, HTML5, Ruby, TypeScript

    Mobile development

    Kotlin, Swift, Objective-C, ++, C#

    Data science

    Python, R, SQL, Scala, Julia, MATLAB

    Artificial intelligence and machine learning

    Python, R, Java, Lisp, Prolog, JavaScript

    Cloud computing

    Java, Python, JavaScript, Golang, .Net Core

    Cybersecurity

    Perl, C++, SQL, Ruby, Rust, Assembly

    Table 1: Key programming languages by domain

    Scientifically benchmarking programming languages

    One of the most efficient and effective ways to differentiate programming languages is through benchmarking, a process through which computer scientists analyze and compare programming languages. For instance, they may compare the performance of different programming languages directly against each other. They may also assess performance differences between different compilers or runtimes of the same language with the same source code. In addition, they may assess real server environments such as hosted cloud VMs or Docker/Podman and their effects on the performance of various programming languages.

    Numerous renowned computer scientists have begun benchmarking programming languages, making it easier to tell them apart and select the best language for a particular task. The Computer Language Benchmarks Game is a popular free software project that compares how popular programming languages implement simple algorithms. Programmers can view results and better comprehend each language, its speed and optimal use cases. Additionally, several reputable websites, such as Programming Language and compiler-Benchmarks and Kostya-benchmark, provide computer scientists with side-by-side comparisons of different programming languages, taking into account various performance issues.

    Ranking of programming languages by popularity (2023)

    When selecting a programming language, some of the factors for programmers to consider include the targeted platform, production time, language elasticity, community/support, the programmer’s experience with the language, and the language’s current popularity. Popularity is an important factor because even though more than 500 programming languages are available, most of the industry relies on just 10, making those the most likely to remain in use. Table 2 highlights the 10 most popular programming languages based on the PYPL Index, which assesses how frequently language tutorials are searched for on Google and Stack Overflow’s Developer Survey 2023.

    Ranking

    PYPL Ranking

    September 2023

    Stack Overflow’s

    Developer Survey 2023

    #1

    Python

    JavaScript

    #2

    Java

    HTML/CSS

    #3

    JavaScript

    Python

    #4

    C#

    SQL

    #5

    C/C++

    TypeScript

    #6

    PHP

    Bash/Shell

    #7

    R

    Java

    #8

    TypeScript

    C#

    #9

    Swift

    C++

    #10

    Objective-C

    C

    Table 2: 2023 10 most popular programming languages

    When making the final programming language selection, it is essential to remember that no programming language will be perfect for any particular project. As such, programmers need to allow for some flexibility in the selection process. Determine what is most important, such as speed, performance or fewer lines of code, and then sacrifice other areas to ensure a solution that best fits the identified priorities.

    The future of programming languages

    Today’s programming world is centered around artificial intelligence (AI) and machine learning (ML). As such, languages like Python, currently a driving force behind AI, will likely grow in popularity. Moving forward, programmers can expect an increase in the popularity of JavaScript, which dominates web browsers; Java, which is prevalent in the business world; Kotlin, which is widely used in apps and C++, which is used frequently in system-level programming and game development.

    As technology evolves, programming languages—both existing and yet-to-be-developed—will play a pivotal role in shaping the future of a digital landscape. Their role in incorporating new tech features, expanding ML, augmenting AI and furthering the internet-of-things (IoT) will become increasingly critical.

    As new languages appear and evolve, old languages will fade away. To that end, Analytics Insight recently published a list of 10 programming languages, including currently well-used languages like Visual Basic and COBOL, which it expects to dramatically decrease in popularity and use by 2030. For this reason, it is essential for developers and decision-makers to stay up to date on the ever-evolving world of programming languages. As existing languages are retired and new ones enter the marketplace, it is imperative that professionals learn promising new languages and continually upskill. Those who commit to ongoing training and education will simplify the programming language selection process, increase their chances of running a successful project, and solidify their position in an increasingly competitive marketplace. Those who don’t risk going extinct alongside once-popular programming languages.

  • BMC Adds More Tools to Modernize Mainframe Applications

    BMC Adds More Tools to Modernize Mainframe Applications

    BMC this week added a BMC AMI DevX Code Insights tool that makes use of machine learning algorithms to break apart monolithic COBOL mainframe applications into subprograms that are easier to update and refactor.

    In addition, BMC is now making available BMC AMI zAdviser Enterprise, a commercial instance of a previously announced free tool that uses machine learning algorithms to collect telemetry data from mainframe applications. The commercial version of the tool adds a dashboard built and maintained by BMC that makes it simpler to consume that data.

    John McKenny, senior vice president and general manager of Intelligent Z Optimization and Transformation at BMC, said BMC AMI DevX Code Insights visually maps a mainframe application to analyze data flow and debug applications made up of millions of lines of code in real-time that would otherwise be too complex to unravel. Armed with the insights gained, IT teams can then isolate business logic, refactor subprograms, add application programming interfaces (APIs) or remove dead code as they see fit, he added.

    BMC AMI DevX Code Insights also makes it simpler for organizations to onboard new developers to a project at a time when many of the original developers of COBOL applications are retiring, said McKenny.

    In the coming year, BMC is also committed to adding generative artificial intelligence (AI) tools to its portfolio for reengineering mainframe applications, added McKenny. Those tools, for example, will make it simpler to create documentation for legacy applications, he noted.

    It’s not clear how quickly organizations that have mainframes are looking to re-engineer applications, but as more of them adopt DevOps best practices, they are being updated more frequently. The less monolithic the application, the simpler that task becomes. The issue is that mainframes tend to run large applications that access large amounts of data, so many IT teams are naturally fearful of breaking them if they are reengineered, noted McKenny.

    While there is no doubt that the process of reengineering applications will become more automated in the years ahead, software engineers will still be needed to manage the overall process, said McKenny. The role of the software engineer will undoubtedly evolve, but it’s not likely software development and deployment will be wholly automated any time soon, he noted.

    In the meantime, IT organizations that manage mainframes continue to embrace DevOps best practices to varying degrees. There may be some applications that they continue to build and deploy using waterfall methodologies, but as mainframe applications become integrated into digital business workflows, the need to update them faster becomes more apparent.

    The challenge, as always, is not only providing IT teams with the tools to make that transition but also navigating the cultural issues that inevitably arise any time a change of this magnitude is made to the software development life cycle (SDLC). Regardless of the approach, the building and maintenance of mainframe applications are evolving. The only issue that remains to be resolved is finding ways to reduce the level of friction that transition creates as quickly as possible.

  • VS Code for Mainframe: The Enterprise Developer Tipping Point

    VS Code for Mainframe: The Enterprise Developer Tipping Point

    Optics matter. At a recent industry conference, a university lecturer reconfirmed what many in attendance already knew, “3270 [green screens] scare off the young generation of developers.” No matter how state-of-the-art the platform or mission-critical the applications, perceptions are formed largely based on optics, and green screens are not a good look.

    Beyond optics, though, a new option offers the promise of a more normalized developer experience (DevX) and DevOps productivity across platforms, along with the staffing flexibility it brings. In short, Visual Studio Code (VS Code) is a big step toward breaking down the mainframe silo.

    VS Code’s extensible, ‘any language, any platform’ design makes it the perfect tool for mainframe developers and with the free and open Code4z extension pack, VS Code is mainframe-ready. Developers are now using VS Code for mainframe AppDev just like their peers, taking advantage of the extraordinary ecosystem and the other many benefits that have made it a runaway success.

    Per my previous article, Git for Mainframe: Back to the Future, combining VS Code with Git (i.e., editor and source interfaces) makes the experience complete.

    So how does Code4z make VS Code mainframe-ready?  Let’s explore the answers from a functional perspective.

    Editing & Debugging

    Mainframe is closely associated with core languages like COBOL, Assembler and JCL, which are often ignored in the world of modern tooling. With VS Code’s extensible framework, however, incorporating these languages is simple and seamless.

    The Language Server Protocol (LSP), which was developed for VS Code, is now an open standard also used by the next generation of browser-based editors, providing a degree of future-proofing. LSP extensions provide a rich editing experience with a wide range of popular features including IntelliSense, which offers capabilities like syntax checking, verb formatting suggestions and variable name completion.

    Code4z offers LSP extensions for COBOL and High Level Assembler (HLASM) while additional extensions are available for languages like JCL, REXX, Db2, and Easytrieve. The extensibility of this technology has already been used to extend syntax awareness to specific language dialects.

    Similar to LSP, the Debug Adapter Protocol (DAP) provides a native interface and layer of abstraction for debug services. Code4z’s debugger extension facilitates the debugging of CICS and batch COBOL programs, an integral part of the end-to-end experience.

    Access & Security

    Mainframe applications, the lifeblood of many businesses, require rock-solid security throughout the entire SDLC. Code4z leverages Zowe, the award-winning open source framework that extends mainframe security and access controls to tools like VS Code. The Zowe Explorer extension, built on the Zowe CLI, provides access to data sets, jobs and USS files and developers also use it to issue TSO and MVS commands and to submit JCL. Zowe Explorer is packaged with Code4z as is a data editor for mainframe data sets including VSAM. This extension is built on Zowe Explorer, again leveraging the extraordinary extensibility.  A Zowe Explorer for CICS is also available.

    Similarly, developers can access a rich and growing set of conformant Zowe CLI extensions via the terminal and scripting.

    Access to SCMs tools is also supported. In addition to VS Code’s native Git integration, there are extensions for Endevor, ChangeMan ZMF, and related tools.

    DevOps Automation

    Since my introductory article a few years ago, Z is for Zowe – the Open Path to Mainframe DevOps, Zowe has enjoyed wide adoption with 69% of surveyed sites either currently using or planning to use it within the year.

    With mainframe teams now using Zowe to adopt modern shift-left practices, scripts for scanning, building, deploying and testing can be run manually by developers from VS Code, in addition to automatic triggers from code commits. This flexibility further empowers developers to own their code throughout the SDLC and beyond.

    With VS Code, mainframe developers can be equipped with more self-service capabilities like Db2 schema provisioning to accelerate the testing process. With capabilities like these, developers can remain in the VS Code experience focused on editing rather than being distracted by low-value infrastructure activities, like requesting and waiting for DBA action.

    Playing the Long Game

    While VS Code is the dominant tool today—almost 3 times as popular as its closest competitor according to Stack Overflow with the lead growing—what is the long-term opportunity?

    Demand for a modern, enterprise-aligned experience spans many domains, from increasing productivity to backfilling retiring staff. Elevating team morale and future-proofing vital mainframe assets ensure this adoption trend will only increase.

    But tools change. Browser-based editors and in-the-cloud collaboration are gaining greater acceptance and the AI-assist excitement is palpable. Bringing mainframe developers onto an enterprise platform ensures mainframe teams will be able to benefit from the same advances as distributed peers. Enabling VS Code and its cloud equivalents demonstrates a commitment to the long-term success of these applications and by reducing the idea-to-production cycle, product owners become champions.

    While not all mainframe developers will embrace VS Code, especially those close to retirement, the vast majority will, as we have experienced within our Broadcom engineering organization. The bottom line is that VS Code makes them even more productive, as illustrated in Confessions of a Career ISPF Programmer.

    Many of today’s developers are proficient with multiple languages (i.e., polyglot) so picking up an additional language like COBOL becomes less daunting if everything else—editor, repo, DevOps processes, etc.—is familiar.

    Getting Started

    For a closer look at the many free and open Code4z extensions, check out the Developer Cockpit, which simulates a COBOL/Db2/CICS developer configuration. And read From VS Code to Mainframe Developer Cockpit for more detailed use cases.

    Most importantly, try it! Code4z is available on the VS Code Marketplace.

    And stay tuned for additional Code4z extensions in the pipeline. There’s never been a more exciting time to be a mainframe developer!

  • Convert COBOL Easily? Yes, Please!

    Convert COBOL Easily? Yes, Please!

    I was reading Mike Vizard’s article about IBM previewing an AI tool to convert COBOL to Java and mentally cheered this move. No, seriously—massively cheered this move.

    There are a lot of uses of large language models (LLM) right now, and many of them are not all that exciting, in my opinion. This one, though? This is huge. In the course of my career, I have been involved in three projects to convert COBOL and one to convert FORTRAN, with some projects that required interfacing with RPG III systems. In all of these cases, the costs were prohibitive. Two of the three COBOL projects never made it past estimates because the cost of resources who know both COBOL and Java were prohibitive, as is the complexity of most mainframe applications as they were modified over the years. The Fortran project never got past resourcing, and the RPG III interfaces were just that. We had to pull the data as it was presented by RPG III systems and only act on our copy, with a separate process used to update the core systems. Why? Because modifying the RPG was impractical, but we could be agile. It was … painful, to put it mildly.

    What all of these projects shared was the lack of a skilled workforce. And what IBM is offering is an LLM that acts as that workforce. If you get the application into Java, there is a large pool of developers that can then troubleshoot it. While the environment issues will still exist and people skilled in tools like JCL are increasingly hard to find, that part can be rebuilt in the new environment. (One question I have about IBM’s project is, “Can it convert to Java for a Linux LPAR/VM?” I suspect that this iteration converts within z/OS, but it would be cool to see increased options in the future.)

    Honestly, this trend will only increase. While IBM’s use of LLM is aimed at moving COBOL to Java, there are an incredible number of lines of Java out there to train on, so soon enough, there will be other conversions in and out of Java. And that’s all good news. We recreate the wheel a lot. The longer-term implication of AI-assisted conversion is that we won’t have to. Think about it: We could feed in a mathematical routine in Fortran and get the language of our choice out the other side.

    Way back in the day, a collection of compilers named TopSpeed let you develop in any of several languages, even mixing and matching to create applications that used each language (and developer) for their strengths. This is the TopSpeed dream writ large. (Disclaimer: I was a huge TopSpeed fan. Bought their intro kit and wrote systems mixing C/Pascal/ASM without having to mess with things like parameter sequences. Yeah, I was cool.)

    We have had too few developers for a very long time. Now, we are about to have a world where developers can focus on truly unique functionality, and the rest is generated based on the mass of implementations we already have. Think in terms of sorting algorithms—99% of the sorting problems out there were mastered decades ago, and yet we frequently see people re-implementing, even today. Now we can tell a system, “Generate a tree sort,” and just make calls. Every time we implement a new language, this type of thing has to be re-implemented, and often it is re-implemented because we don’t know about the available solutions. In the future, we will have solutions at our fingertips.

    And as with the other benefits of automation, we’ll do less busy work and add more business value. While there will be some pain, I think in the long term that is a huge benefit. And you’ll still be there, making things go zoom.

  • IBM Previews Generative AI Tool for Converting COBOL to Java

    IBM Previews Generative AI Tool for Converting COBOL to Java

    IBM this week announced it will preview a generative artificial intelligence (AI) tool for converting COBOL code running on mainframes into Java. The preview will be available next month during IBM’s TechXchange learning event, IBM said.

    Kyle Charlet, CTO for Z software at IBM, said watsonx Code Assistant for Z makes use of large language models (LLMs) that IBM has trained to both convert and optimize Java code for z/OS running on IBM mainframes.

    Rather than converting COBOL into Java code line for line, the watsonx Code Assistant for Z improves the syntax of Java code generated using object-oriented techniques, he noted.

    IBM’s watsonx.ai code model, which will have knowledge of 115 coding languages, is based on 20 billion parameters that will eventually be applied to other programming languages such as PL/1, added Charlet.

    That model is the same core LLM that IBM used to create Red Hat Ansible Lightspeed, a tool to generate code for an IT automation framework that is scheduled for release later this year. In the future, IBM will also most likely employ generative AI to convert REXX code into Ansible code, said Charlet.

    IBM expects the final offering will combine generative AI tools with its existing Application Discovery and Delivery Intelligence (ADDI) inventory and analysis tool to streamline the modernization of legacy mainframe applications.

    The goal, however, is not to move COBOL applications off the mainframe. Java applications created using watsonx Code Assistant for Z will still call the same data sources, such as an IMS database or CICS transaction processing system, as the original COBOL application.

    That approach will make mainframes more accessible to a wider pool of developers that know Java, which should increase the overall pace of innovation for application development, noted Charlet.

    There are billions of lines of COBOL code currently running on mainframes that, in one way or another, need to be modernized as the pool of developers that know COBOL continues to shrink. Generative AI will make it easier to quickly assess, update, validate and test code, which should accelerate code conversion efforts that otherwise would take years to complete, said Charlet.

    It’s not clear how quickly organizations might move to modernize COBOL applications, but as the time and effort to do so decreases, so should the cost of modernizing legacy code. Most organizations still running z/OS on mainframes are committed to the platform, but if they can transition to Java, the overall cost of building and maintaining mainframe applications should decline.

    In the meantime, it’s not likely that AI will replace developers. IBM recommends that developers further optimize the Java code generated by watsonx Code Assistant for Z.

    Most developers are already using some form of AI to accelerate application development. The next wave of AI will see more widespread use of LLMs that are optimized for specific tasks and that generate more reliable results. After all, the quality of any output from an AI model is always directly related to the quality of the data used to train it. The narrower the set of vetted data, the more trustworthy the AI becomes—the opportunity for erroneous data to create AI hallucinations is a whole lot less than any general-purpose AI model could achieve with customization.

  • IBM LLM AI: COBOL to Java ASAP ¦ ARM IPO is GO!

    IBM LLM AI: COBOL to Java ASAP ¦ ARM IPO is GO!

    Welcome to The Long View—where we peruse the news of the week and strip it to the essentials. Let’s work out what really matters.

    This week: Translating legacy COBOL code to a slightly more modern language, and Arm will go public (again) next month. (more…)

  • Languages and DevOps: Mainframe

    Languages and DevOps: Mainframe

    In true DevOps fashion, I nearly forgot to cover the mainframe after saying it warranted its own blog!

    There is a lot going on right now in the mainframe space, so the question of mainframe language choices has several different answers. We’ve got Linux running on the mainframe, we’ve got cross-compiled open source capable of running on the mainframe natively, we’ve got mainframe-based containers and we even have traditional mainframe tools being ported to other platforms (hello, COBOL on Linux!) so that development can happen on smaller platforms but target the mainframe.

    Taken in the order they came available, we have traditional mainframe development, in languages like COBOL and RPG, right on the mainframe in standard LPARs. This has gotten easier over the years, but is still basically the same development environment that was used in the 1980s, with prettier UIs.

    Then we have Linux LPARs available that allow for development right on the mainframe. There are issues and differences from other Linux development environments, but not as many as you’d think. This approach gives a broad selection of development tools on a Linux platform, making it an appealing choice.

    Next came containers, which can then run Linux in a container with the container offering the interfaces that Linux expects to find. This approach has the benefit of being more like development on other Linux platforms, but interaction with core services can still be platform-specific at times. This approach offers the breadth of open-source languages that came naturally with containers plus the few that have been ported over to z/OS.

    Then came speed porting. The biggest weakness of the above options was that it took too long for vulnerabilities to be addressed and new functionality to be moved over to the mainframe. The fact is that porting a language took time, and wasn’t as rapid as the response for the core Linux kernel. There has been a movement to improve the dev tools that create the ports, and now response time to CVEs or improvements in the kernel is much better. A side effect of this movement has been increased availability of languages and tools that are used by DevOps to get things done.

    Finally, we have recently received support for traditional languages on other Linux platforms. Most notably, given the number of lines of code out there, COBOL is now officially supported on Linux, meaning you can develop on the desktop without a ton of overhead, and then deploy to the mainframe. This has the effect of enabling DevOps processes and mentality for more traditional languages. This is still new, and the differences between developing on one platform and deploying on another will have to be worked out, but it is a step in the right direction.

    So what should you use?

    Mainframes are generally a more controlled environment than most DevOps teams are used to. The work required to support and update a given language, keeping it and its libraries up-to-date is more complex than just a generic Linux system, and that gives rise to very focused shops in the mainframe space. Generally speaking, you will be told what to use, or more to the point, which languages are supported. If you get input into the process, recommend Python, as it has the biggest pool of developers and libraries out there at the moment. But chances are, the mainframe team already has a language in place that they want DevOps teams to focus on, and in that case, use what’s available.

    No matter which language you end up using, API-wrapping mainframe functionality is a time honored tradition at this point, make the mainframe do the heavy lifting and return just what your application needs. Think of it as a big, smart database that can pre-process results for you at high speed, in high volumes.

    And keep rolling.

    Mainframes have been around forever. They’ve been pronounced dead dozens of times, and yet the security, stability and locality of a mainframe keeps them in the mix. Data gravity helps too – the data is there, the routines to do processing on the data are there, handing that data off to another platform for presentation isn’t that big a deal, and the mainframe just keeps ticking along. Because (at this point) generations of developers have made it tick. Keep that tradition alive if you’re in a mainframe shop; they are literally the core of systems in the places they are in heavy use.

  • COBOL Is Taking Heat, but These Other Legacy Languages Could Burn You

    COBOL Is Taking Heat, but These Other Legacy Languages Could Burn You

    COBOL is under fire, and as states such as New Jersey make headlines following vital system crashes that its citizens depend on—such as unemployment benefits—organizations are pointing fingers at the programming language as the source of their technological woes. However, while COBOL is a 50+-year-old programming language, there are still many use cases for it today. In fact, systems programmed in COBOL can modernize and continue to thrive in today’s business environment, even without transitioning to a new language or platform.

    While COBOL itself isn’t the problem child that most IT leaders and government entities say it is, there are a variety of other legacy languages—such as CA Gen, CA Telon and Natural—that pose a far greater threat to an organization’s overall functioning and long-term success. That said, there is still hope for organizations utilizing systems coded in legacy languages.

    Get on the CASE

    Two of the top languages that enterprises should be alert to—CA Gen and CA Telon—are Computer Aided Software Engineering (CASE) application development environments that were developed in the late 1970s and early 1980s and offer code generation, enabling the power of abstraction on the mainframe, essentially serving as an early stage ancestor of the “low-code” concept. This approach offered significantly more agility to developers at the time, but these programming languages have since fallen from the spotlight and, similar to COBOL’s limited pool of talent, have an even smaller pool of skilled developers that can assist with updating and maintaining these systems. This challenge traps many organizations in long-term contracts that they can’t seem to escape from.

    A major selling point of the CA Telon and CA Gen product lines was that its services were often offered within bundles—granting users with access to other mainframe utilities and services within a single licensing contract—but as time goes on and new technologies emerge, the advantages of this approach have fallen by the wayside. However, many organizations are trapped within expensive licensing fees and complicated bundling programs that make it difficult to sever ties with the legacy platform entirely.

    CA Gen and CA Telon act as generators of COBOL code, meaning that developers utilize tools in a language like CA-Gen but when it runs on the mainframe the system is running on COBOL. The COBOL within the mainframe then references CA-Gen and CA-Telon libraries, which makes it easy for developers to reference specific functions but ultimately produces code that is unable to be read by a human person. This creates significant complications for doing anything outside of the CASE environment—even tasks as simple as routine updates—but especially for digital transformation initiatives.

    While few organizations are purchasing CASE development solutions as new products, those that utilize these tools are constantly renegotiating the terms of their agreements to keep costs down, enable easy updates to their own unique systems and meet the emerging demands of today’s market. If they can successfully pull it off, they have another challenge: finding the talent who understands these obscure languages to implement necessary system changes. That said, the best solution for these organizations is to break away from these languages entirely—and this can be achieved relatively easily with automation through carefully selected modernization solutions.

    Why Natural Isn’t a Natural Choice

    In addition to CA-Gen and CA-Telon, one legacy language that all organizations should be alert to is Natural. Similar to the look and feel of COBOL but more abstract and powerful, Natural is a fourth-generation language (4GL) that was originally designed to enable agility and efficiency—but today, there are fewer than 100 companies utilizing this language. As a result, there is a scarce number of developers who can address and assist with any issues that arise within systems utilizing Natural. What’s more, most of these organizations don’t know they have a way out. This puts organizations at risk any time that a change to their operational systems is made, as the limited availability of specialized developers can make it especially difficult to achieve these updates.

    In most cases, Natural is utilized in tandem with the Adabas database, which can exacerbate the maintenance and extensibility issues that come from a shrinking talent pool—and when it comes to modernizing these environments, they’re often peppered with other programming languages such as COBOL and assembler, adding complexity to the job.

    Beyond COBOL: Choosing the Right Modernization Strategy

    For organizations looking to break away from obscure languages and mainframes, the best option for both their immediate and long-term goals is to pursue some form of modernization—and in most cases, the best result is to translate these languages into cloud-ready languages such as Java or C# via an automated refactoring initiative. Automated refactoring can also be utilized to consolidate these applications to a single language such as COBOL while remaining on the mainframe—although moving from an abstract language to a more procedural alternative can present challenges.

    By pursuing an automated refactoring strategy, organizations can move mountains of information, records and personalized code away from their mainframe and translate their system into a modern architecture. This allows organizations to untangle the “black box” of personalized code that exists within their systems and replace them with languages such as Java, C# or even COBOL, which unshackle companies from high licensing costs and have a much broader talent pool of developers. The resulting modernized system is easier to maintain, escapes high licensing costs and moves the business closer to cloud readiness, opening the door to modern development practices and tools. What’s more, in addition to saving significant funds by eliminating the costs associated with maintaining these legacy systems, an automated refactoring solution can help an organization to save years on its overall modernization process.

    While languages such as CA Gen, CA Telon and Natural are less common in the industry, these archaic languages can present significant challenges for businesses as they work to meet the demands of customers and partners. In the world of information technology, the only constant is disruption—and organizations need to get started on their modernization journey before it’s too late.

  • Why It’s Time to Migrate Away From COBOL

    Why It’s Time to Migrate Away From COBOL

    Every few years an alarm goes up about the shortage of COBOL programmers, and then it dies down. While it’s hard to tell whether this cycle occurs because programmers are found or because other solutions are identified, the latest resurgence of interest is at least in part due to the pandemic and state governments’ use of software for social services that couldn’t stand the increased caseload of tens of millions of unemployment claims.

    As we continue to sit in the midst of the pandemic, organizations are thinking about the many ways businesses will have to change. For instance, will cash still be used in five years or will the business need to support some kind of cryptocurrency? It’s time to ask those big questions now—and determine whether it’s possible to make changes without touching COBOL code.

    For most organizations, I believe that in answering these questions they’ll find that it’s time to start migrating away from COBOL.

    The Rise (and Fall) of COBOL

    COBOL is one of the earliest programming languages. It was invented in 1960 and rose to prominence as a language that required minimal programming skills. Part of COBOL’s initial attraction was that it was a domain-specific language designed for business—not only was it easy for programmers to learn, it also could be understood by executives; hence, the acronym for “Common Business-Oriented Language.”

    COBOL was also one of the few programming languages that understood the requirements of business computing—most simply, the fact that an amount like 10 cents can’t be represented accurately in binary was a huge challenge. If you’re a bank, small rounding errors on each transaction add up. Libraries for business arithmetic could be written in other languages, but they’re scarce and hard to find.

    While COBOL never disappeared, its influence faded in the 1980s but many large institutions failed to transition away from it. Today, there are billions of lines of code in governments, banks, enterprises and elsewhere performing essential business functions with few programmers able to maintain them.

    Part of the reason why COBOL fell out of fashion was its inability to adopt things such as modularity or breaking down problems into smaller, functional pieces. When COBOL was invented, old business software was monolithic—and monolithic in a very deep sense. Internally, the software wasn’t partitioned into separate components that could be updated without affecting each other. It also tended to model forms that humans would fill out and couldn’t be submitted until the form was complete. Putting a web interface in front of those monoliths leads to a predictable result: long, complex forms that can take hours to fill out and are close to unusable on the modern web.

    While the COBOL language itself has evolved over the years (with revisions released in 1961, 1974 and 1985 and object-oriented COBOL released in 2002), you still have to ask: what will it take to bring a COBOL program written in the 1970s or 1980s up to date? Is redesigning a program to take advantage of COBOL 2014 any easier than porting it to Java or Python or Go or Rust? Furthermore, COBOL looks unfamiliar and forbidding to most modern programmers, which likely caused it to lose popularity in the first place.

    Finding an Alternative

    So, where are we now, with our billions of lines of COBOL running the world’s governments and finances? We certainly need more people who know and understand COBOL programs. There’s a lot of old code that needs to be maintained, pure and simple.

    But it goes deeper than that. COBOL is just another programming language; if we’re going to maintain (or replace) that software, we need programmers who understand the engineering decisions that made the software what it is. Programmers used a lot of tricks to work around the limitations of 1960s computers. Those tricks just don’t make sense to modern programmers; they solve problems we no longer have. We also need engineers and managers who are willing to look at our current situation—for example, the huge surge in unemployment applications—and think beyond the short-term solution. What does it take to reinvent current systems rather than replacing them? How can these systems become more human-centric? Can they be redesigned to match the way we live and work now? Putting a web front-end on a monolithic business process from the 1950s is the road to failure.

    The new generation of programmers must understand financial programming and how to design business systems. There’s little value in migrating from COBOL if you don’t get something better in return. What you should get in return is the flexibility to add new features and new user interfaces, the ability to adapt to changes in competitive conditions and implement changes in the regulatory environment, and so on. We don’t yet know what those new features will be (perhaps cryptocurrency or virtual reality user interfaces), but we do know that businesses will need the flexibility to add them.

    Simply put: Scrambling for COBOL programmers whenever there’s a crisis is not a viable business decision. Transitioning from COBOL is a change businesses will have to make eventually. This transition should be made when businesses have time to think it through, time to hire the right people and time to do a good job—rather than waiting for the next crisis.

    In the meantime, while businesses are baking in the time to think through their transition strategically, it’s important to note that this isn’t an all or nothing decision—i.e. let’s scrap our legacy software and replace it by Jan. 1, 2021. This is not Y2K. Using a microservices approach offers numerous advantage. For one, businesses can split their existing infrastructure into different independent services. They can start with pieces such as authentication, then move on to things such as billing and other services. Whatever businesses decide, they need an approach that’s modular so that it’s easy to add new features as needed. That requires careful thinking about design—and that thinking is more important than the programming language itself.

  • DRY Comes to COBOL in IBM Z Development

    DRY Comes to COBOL in IBM Z Development

    Don’t Repeat Yourself (DRY) is a fundamental tenet of modern computer programming. Just about every CS student is taught that duplicating code in an application is an accident waiting to happen. The hazard is that you might alter a piece of code in one place, only to leave another identical instance of that code unchanged. Then when you run the code all sorts of strange things happen. In some cases, the changed behavior is in force. In other cases, it’s not. Maintenance becomes a nightmare.

    These days adhering to the principle of DRY is not that difficult. Object-oriented languages such as Java, C# and Objective-C make it easy to encapsulate a set of functions into a class that can be reused throughout an application. Also, technologies such as RPC, XML-RPC and gRPC make it possible to expose distinct functions to the network in a sharable manner. When a single piece of code can be easily shared at runtime, the risk of writing redundant code goes down. Why reinvent the wheel when you can just use one that is pre-existing and well known?

    However, this has not always been the case. In the early days of programming, lines of code executed sequentially. You started at line 1 and ended at line 200. There were no side trips in the middle.

    Language designers were aware of this shortcoming and made it so programs could jump around the lines of code. You could start at line 1 and run to line 20, then jump to line 190 and run to line 220, coming back to line 21 and then jump again to exit out at line 240. It was definitely hopscotching, but it worked.

    Procedural programming arrived soon after and with it came the early forays into segmenting code into a discrete unit of execution, the function. Functions introduced the concept of code sharing within an application. Still, a framework of sharing a single unit of code among an entire system, let alone many systems, on the network took a while to develop. As a result, in the early days of programming code redundancy was rampant.

    The thing to remember is that the proliferation of redundant code was not so much a reflection of professional incompetence. Rather, it was due to the absence of a programming framework by which to avoid code redundancy.

    But, that was then and this is now. Today, DRY is a standard operational mantra. This is good. On the other hand, there’s still a lot of redundant code out there, particularly in shops that have a lot of legacy COBOL. Remember, COBOL just celebrated its 60th birthday. It’s been around for a while.

    Fortunately, the world of redundant code in the COBOL is about to become a whole lot smaller with the introduction of Duplicate Code Detection Technology Preview that’s built into IBM Developer for z/OS.

    Understanding Duplicate Code Detection Technology Preview

    The Duplicate Code Detection Technology Preview (DCD) is a feature supported by IBM Developer for z/OS (IDz) that automatically discovers duplicate code within a given codebase. It’s an optional feature, available as of version 14.2.2, that needs to be added during IDz installation. DCD is an enterprise-level tool that’s intended to be used with very large amounts of COBOL source code, at the level of a million lines of code or more (See Figure 1).

    Duplicate Code Detection Technology Preview for IBM Developer for z/OS
    Figure 1: Duplicate Code Detection Technology Preview for IBM Developer for z/OS exposes duplicate code for elimination or refactoring.

    Once duplicates are identified, developers can use DCD to justify whether the given redundancy is appropriate or if it’s a duplication that needs to be removed. Thus, DCD can be used as a tool to assess code quality and as a tool to refactor the codebase.

    See Duplicate Code Detection Technology Preview in Action

    At IBM’s upcoming webinar, “Duplicate Code Detection — Simpler & Faster Thru’ Out the Lifecycle Webcast,” on May 20, 2020, from 9 a.m. to 10 a.m. (ET) you’ll get an in-depth look at Duplicate Code Detection Technology Preview for IBM Developer for z/OS. Architects Herve Le Bars and Jean-Yves Rigolet will be on hand to go over the details for using DCD to eliminate duplicate code and improve code quality.

    The webinar is free and it’s filled with important information that’s sure to enhance the productivity of developers using IBM Developer for z/OS. You can register for the DCD webinar here.

    How Duplicate Code Detection Technology Works

    Duplicate Code Detection Technology is an optional feature that can be fully integrated into IBM Developer for z/OS. Developers can use DCD as a standalone application to search for duplicates in his or her workspace. Also, developers have the added benefit of sharing duplicate code detection results among a team. In order to have a collaborative experience with Duplicate Code Detection, three additional components need to be installed on the server-side. These components are:

    •     IBM Websphere Liberty Server
    •     Duplicate Code Detection Feeding Agent
    •     Source Code Management System

    Let’s take a look at how it all fits together.

    As mentioned above, developers can use DCD with IBM Developer for z/OS to examine the individual developer’s workspace for code duplication. In this case, DCD is essentially a stand-alone tool (See Figure 2, callout 1).

    Duplicate Code Detection
    Figure 2: Duplicate Code Detection works standalone and as a collaborative tool.

    While it is beneficial to have an individual developer detecting duplicate code in his/her workspace, it’s limited in scope. There is only so much work a single developer can do. Where things get really powerful is when the result of searches for code duplication can be shared among the team. This is where using DCD in a client-server architecture comes into play.

    Central to the DCD client-server architecture is the DCD Server which is an IBM Websphere Liberty Server and the DCD Web Application.

    The DCD Server is used to share the results of duplicate code detection across members of the development team. Developers interact with the DCD Server using the DCD component running within IBM Developer for z/OS (See Figure 2, callout 1, above).

    On the server-side, there is an independent client, the Duplicate Code Detection Feeding Agent that acts as a bridge between the source code stored under a source control management system and the DCD Server.

    The feeding agent asks the SCM for the changed COBOL files in the source code management system (See Figure 2, callout 2). Then the DCD Feeding Agent sends the changes to the DCD server (See Figure 2, callout 3).

    The DCD server keeps track of duplicate code (See Figure 2, callout 4). As mentioned above, team members access the DCD server using IBM Developer of z/OS to visualize the duplicate code information. The DCD feeding agent works incrementally: Only changed COBOL files are transferred for examination, thus reducing operational overhead.

    You can read the details for installing and configuring Duplicate Code Detection by downloading the DCD Installation Guide.

    The Benefits of Using Duplicate Code Detection Technology

    There are many benefits to using Duplicate Code Detection Technology. Automated duplication detection simplifies refactoring. Duplicate Code Detection Technology identifies redundancies that occur throughout millions of lines of code automatically while leaving it up to the developer to judge if the code duplication is justified or not. If duplicates do need to be removed, DCD allows developers to make the changes at once, thus saving time while improving productivity. Remember, Duplicate Code Detections works at lightning-fast speeds. It takes on average 100 milliseconds to search 100,000 lines of code.

    Also, when distributed collaboration is enabled using the DCD Server, searches can be shared with team members and stored for later use, thus improving collaboration efforts among teams and team members.

    Duplicate Code Detection enhances search efficiency by examining code stored directly in source control management repositories. DCD improves code readability while reducing complexity. In addition, it supports versioning using standard source control management frameworks, such as GitHub.

    Putting It All Together

    The principle of DRY is commonplace these days. While it’s been a principle that’s easier to implement in younger companies, those businesses with codebases that go back decades have found adopting DRY to be difficult. Refactoring can be risky. Many companies think that unless there’s a compelling reason to refactor the old code, most times it’s better to leave well enough alone, particularly if that code is written in COBOL.

    But as the dramatic need for COBOL programming talent at the New Jersey Department of Labor recently revealed, COBOL matters. And, when that COBOL code is refactored, which is sure to happen, applying DRY in the refactoring effort will be a driving principle. Hence, the opportunity exists for DCD to play a key role. It’s a compelling technology. Given the power that DCD brings to the COBOL programming experience, implementing the DRY principle against both current and legacy code requires no more labor than the work that goes with spell checking a large document.

    Duplicate code has been the bane of developers since the first Hello World was written over half a century ago. Over time the situation has improved, but for many companies it’s still a problem, particularly companies with a large legacy of COBOL programs. Companies that make Duplicate Code Detection Technology part of their COBOL programming toolbox will not only have the benefit of creating code that is more elegant, more readable and of higher quality, they will be well on their way to placing the DRY principle at the forefront of their software development activities.