Modernizing SCOBOL Programs Part 1: The Challenge
Updated: Mar 26
Part 1: The Challenge
Why Modernize?
The pace of application modernization initiatives on NonStop has accelerated in the past several years, as more users and organizations have started to consider the importance of NonStop’s strategic values. The objectives of application modernization are to reduce risk, reduce costs, and to increase agility. These objectives align with the priorities of all organizations’ IT management.
Migrating Existing Legacy Programs
Most discussions on application modernization focus on how to develop new applications on NonStop using new technology, such as Java, SOAP, open source frameworks such as SASH. Yet, one of the most common problems faced by IT management is not about the development of new programs, but rather with the challenge of how to migrate existing legacy programs containing complex business logic to a new programming platform.
This blog series focuses on this last topic and uses SCOBOL as an example. We show how it is possible to extract business logic from a legacy SCOBOL program and incorporate it in a modern version of the program using a software engineering tool called Blu Age.
The Challenge – Embedded Business Logic
SCOBOL was originally designed for handling the UI, and the recommended best practice was to avoid business logic in SCOBOL programs. In reality, developers commonly exploit SCOBOL’s capabilities by putting business logic in their programs. These business logic routines may range from something simple like checking input fields for certain values, to extensive logic that cross-references multiple screen fields. With all this embedded logic, the SCOBOL programs become very function-rich and work beautifully in the native Pathway environment. However, when the time comes to migrate the program to a new environment such as a web browser, embedded logic becomes an obstacle in the migration effort. In the browser and application server environment, you will need to understand where the business logic is in the existing program, and how to replicate this business logic in the new program.
Dealing with programs with business logic
Let’s say that you have SCOBOL programs with business logic that you want to transform into to a web graphical user interface (GUI) application. Here are some of your available options in handling the embedded business logic:
Rewriting
Let’s say that you have SCOBOL programs with business logic that you want to transform into to a web graphical user interface (GUI) application.Here are some of the challenges:
There is usually no adequate documentation of the existing code. The only thing available is the source code.
That means someone needs to understand how to read SCOBOL code, and someone else with expertise in the new programming environment to assist in the migration.
SCOBOL programming expertise doesn’t necessarily translate to a clear understanding of the business logic in someone else’s code. In most organizations, chances are that the original coder is no longer available. In some cases, this could be further complicated by the fact that the program had been modified by multiple developers over the years.
Finally, you must verify that all the functions are rewritten correctly.
Caution: Rewriting by hand sounds easier than it really is.
Language Translator
Using an automated language translator is another approach to modernizing legacy programs with business logic. A language translator is a program that can read in a SCOBOL program source and output a program in a target computer language like Java or C#, along with all the other technology pieces needed to provide equivalent functionality to the SCOBOL program.
The HP Pathway/iTS product is an example of this kind of translator product. It reads in the SCOBOL source, and generates equivalent Java applet code that will run in the web browser and communicate with the Pathway TCP. There are other commercially available COBOL translator products and services in the market that work similarly on different COBOL variants on different platforms.
While this sounds good in theory, the result usually falls far short from ideal.
This translator would face all the challenges of human “rewriter” without the human’s intelligence. A translator is a black box to its users, and “tuning” by vendor experts is required to produce a successful translation. SCOBOL programming style changes (e.g. two different programmers’ coding styles) may befuddle the translator, requiring expert vendor intervention to keep things moving.
Most translators can deliver only somewhere between 50%-70% success rate at best, and the result varies depending on the complexity of the original program. The rest requires additional manual tweaking by an expert of the tool and could take a fair amount of time.
Experience with program translators shows they can be brittle. Even if the translated program is functional, most likely the generated source code cannot be maintained manually by a developer.
Translated code usually does not perform well, as the vendor of the translator tool focuses more on delivering an output that functions correctly, without regard to performance
Caution: Translators sound great but have severe practical limitations.
So, what would be a better approach? Read about it in our next blog:
Feedback please
Do you find this tutorial blog helpful? Let us know what you think, and how we can make it even better. Don’t forget, you can subscribe to our blogs to get automatic email notification when a new blog is available.
Phil Ly is the president of TIC Software, a leading provider of software and services for the NonStop community focused on NonStop application modernization. Under Phil's guidance, TIC Software has a proven track record of helping clients seamlessly integrate NonStop with next-generation technologies. A recognized technical leader, Phil is passionate about empowering organizations to unlock the full potential and longevity of their NonStop platform through innovative solutions.
Comments