Although COBOL's invention in 1959 predates my own understanding of its evolution, my programming journey began as a high school student.    I recall crafting a program to print a calendar using punch cards encoded with Fortran, compiled and executed on an IBM 360 machine, resulting in a printed output.   As I entered the programming world in 1984, the landscape of available languages was relatively sparse.    Assembler, a language notorious for its complexity but essential for navigating the limited memory capacities of computers at the time, presented a formidable challenge.    C, while crucial for system software development, often confounded average programmers with its intricate pointer concepts.   For application software, COBOL emerged as the champion, aligning perfectly with the abilities of most programmers.  

In the early days of green screen technology, giants like IBM and Tandem raced to develop system software for COBOL.   IBM emerged with CICS, while Tandem created Pathway.   These platforms liberated COBOL developers from the complexities of front-end interaction.   On the user side, COBOL could access databases (keyed files, DB2, etc.), manipulate data, execute business logic, and re-format it for presentation on the 80x25 green screen.    Each user interaction triggered further business logic processing, all orchestrated by CICS/Pathway behind the scenes.    Pathway managed the entire green screen environment (including SCOBOL code), ran containerized COBOL programs, provided necessary startup configurations, and even handled terminal session memory.   This was crucial because SCOBOL programs often called each other, requiring careful stack management (pushing/popping).   CICS/Pathway itself was a complex beast, consisting of tightly woven, multi-threaded system software that had been around for decades.   

While computers and hardware rapidly evolved, Pathway and COBOL saw little advancement.   Yet, businesses continued to flourish, resulting in a growing reliance on SCOBOL/COBOL code to support their operations.   During the 1980s, Microsoft DOS gained dominance, but its interface wasn't much different from green screens.   It wasn't until 1990, with the introduction of Windows 3.1, that a significant shift in user experience occurred.   The early 1990s witnessed the rise of Visual Basic.   I personally used this language within a team project to successfully replace 6530 terminals. While this introduced a modern interface to desktops, the underlying communication still depended on COBOL running on Tandem systems.   Replacing COBOL itself remained an elusive challenge during that era.   Then Y2K arrived, triggering a frantic scramble to address potential date-related issues.    COBOL programmers became scarce, and replacing COBOL between 1995 and 2000 posed a considerable risk.    Consequently, companies worldwide opted for a simpler solution: scanning and upgrading their existing COBOL code.    The significant investments in time and resources devoted to Y2K compliance prompted these companies to extend their reliance on COBOL to recoup their expenses.  

I'd say that it wasn't until 2004 and beyond that companies began seriously considering COBOL replacement.   I happened to join a team in the midst of such an endeavor, attempting to replace an application on a NonStop system.   The first attempt involved hiring a completely new team to rewrite the application.   Unfortunately, the team underestimated the project's complexity and failed to deliver a viable solution.   The second attempt involved purchasing an existing, modern application that claimed to offer similar functionality.   However, this approach also failed due to discrepancies in functionality, forcing users to work with two separate systems and contend with the instability of the newer one.   The third attempt aimed to integrate the remnants of the failed system from attempt two with new code that aligned with the old system.   This led to the formation of various new departments, each tasked with handling specific functionalities previously managed by the old system.   System architects began purchasing software and hardware to facilitate communication between these siloed functionalities, resulting in a mishmash of solutions that often caused breakdowns and hindered problem-solving efforts.   When issues arose, "war rooms" would convene, bringing together individuals who only understood their own piece of the puzzle, lacking a comprehensive grasp of the overall architecture.   Witnessing this process firsthand, I gained a profound understanding of the inherent difficulties associated with migrating off mainframe systems.  

Multiple factors are driving the urgent need to replace COBOL:

• Educational Void: COBOL has largely vanished from modern curriculums, leaving a significant knowledge gap among emerging developers.   Hands-on experience with mainframe environments like CICS or Pathway is crucial for effective COBOL proficiency, yet educational institutions are unlikely to invest in such costly infrastructure.  

• Impending Workforce Exodus: The imminent retirement of seasoned COBOL developers, many with over 30 years of expertise, threatens to create a critical knowledge vacuum.   This poses a daunting challenge for less experienced COBOL programmers tasked with maintaining and evolving massive codebases.  

• Codebase Magnitude: The sheer volume of COBOL code currently in production, estimated to exceed a staggering 800 billion lines, underscores the gravity of this legacy modernization challenge.       Read more...

Migration alternatives, what others have done

In scanning the Internet, I found that some "early adopters" of COBOL replacement gravitated towards screen scrapers.   This approach involves scanning green screens and replacing them with modern-looking GUI frontends.   However, it's merely a cosmetic change, as the underlying COBOL code remains intact.   Others attempted to translate COBOL into C, C++, or Java, but this often resulted in unmaintainable code riddled with convoluted "goto" logic.   Still others experimented with emulating Mainframe environments on Unix platforms, enabling the recompilation and execution of original COBOL source code.   While functional, this approach still retains the outdated 80x25 character display format.   Visual COBOL presents another option, allowing for continued COBOL development with modified syntax to support object-oriented paradigms and compilation into Java or .NET objects using Micro Focus tools.   The intention was to leverage existing COBOL programmers, but this strategy overlooks the impending retirement of many COBOL professionals.  

The ultimate solution

To successfully replace COBOL, you must first address the CICS/Pathway environment!   Understanding CICS/Pathway's functionality is crucial.   At its core, it containerizes COBOL code, enables the startup of multiple container copies, and leverages round-robin load balancing for enhanced performance.   On the frontend, CICS/Pathway handles all green screen GUI rendering and interactions.   COBOL programmers simply describe screen fields within MAP (SCOBOL) files, compile them, and allow CICS/Pathway to manage GUI interactions seamlessly.  

Pathway also offers some secret ingredients.   It allows programmers to add new containers (COBOL code) on the fly, eliminating the need for system shutdowns to implement new business logic.   You can stop dependent containers, implement new ones, and restart them seamlessly, all without interrupting service.   Pathway provides auto-restart capabilities for COBOL containers, ensuring resilience.   Additionally, new screens can be added on the fly, and Pathway intelligently interfaces with them by their unique names when requested.  

And finally, Pathway provides session management.   As a COBOL programmer, you communicate from screen to screen via the Linkage section and maintain context screen data using the Working Storage section.   This was a vital feature as businesses grew and required interactions across multiple screens.   All Linkage and Working Storage memory is allocated "at the per-user session level," and Pathway flawlessly handles this for thousands of users.  

What off the shelf software out there that can replace CICS or Pathway?

I'm thrilled to announce that we've achieved a major breakthrough: Pathway 2.0/CICS 2.0, reimagined for the cloud!    JtmCode has developed a comprehensive set of system software designed to seamlessly replace Pathway or CICS.   Instead of containerized COBOL, you'll harness the power of containerized Java.   Add new containers dynamically, scale as needed, and JtmCode handles round-robin load balancing effortlessly.   Forget complex GUI coding—simply describe screen fields in an intuitive, English-like language, compile, and let JtmCode manage all user interactions with your Java containers.   Your business logic resides in POJO (Plain Old Java Objects), a straightforward approach approachable for the vast majority of Java programmers.  

Unleash a cascade of advantages with JtmCode:

• Modern, expansive GUIs: Transcend the constraints of 80x25 character displays and embrace the full potential of modern browser technology for immersive user experiences.
• Effortless infrastructure management: Focus exclusively on crafting Java business logic while JtmCode seamlessly handles the underlying infrastructure.
• Streamlined frontend development: Eliminate the need for separate HTML/CSS/JS expertise. Similar to COBOL's approach, a single Java programmer can now construct entire screen functions, reducing complexity and costs.
• Exceptional frontend stability: Enjoy rock-solid GUI components that deliver unwavering reliability, minimizing maintenance overhead.
• Pathway-like functionality: Seamlessly transition from Pathway environments with a functionally equivalent experience, ensuring a smooth migration path.
• Accelerated time-to-market: Witness a dramatic reduction in development cycles, enabling you to captivate customers with innovative applications at lightning speed.