Displaying items by tag: PL/1

Originally developed by Denmark-based KMD in 2001 as a mainframe software application, the e-Boks system became more difficult and costly to maintain over time. The original platform also lacked the agility to expand to additional countries at scale and was not agile enough to expeditiously react to business changes. TSRI and KMD were able to modernize the e-Boks application from its original IBM PL/1 legacy code in a monolithic architecture to a modern, multi-tier application in a modern computing environment, running .NET, with no impact on the business and end-user experience. As a result, e-Boks has the potential to save more than 50-60 percent per year in operations and maintenance costs.

Customer: KMD and The Government of Denmark Source & Target Language: PL/1 & JCL to C# Lines of Code: 974,201 (781,893 - PL/1 and 192,308 - JCL) Duration:  6 Months Services: Transformation Blueprint®, Automated Code Transformation, Automated Refactoring, Integration and Testing Support

PL/1 - Life in COBOL's Shadow

When IBM developed the framework for its PL/1 computing language in the 1960s, the committee of business and scientific programmers that developed the parameters for the language could not have foreseen today’s modern technologies of a phone in every pocket and digital access to anyone on the planet via the internet. They also may have hoped for, but likely did not foresee, how a mainframe language and architecture that survived 60 years would still be in use today.

Though PL/1 never reached the level of popularity of its COBOL competitor, it was still used on multiple government, corporate and defense mainframe systems throughout the years. It is, by many accounts, a very stable and reliable language—it even had more features in some areas than COBOL! However, programmers and organizations had little business or technical incentive to adopt the language. Today, having lived for so long in the shadow of COBOL and Fortran, finding programmers with PL/1 experience has become harder each year making it increasingly difficult to maintain any remaining mainframe applications. Those challenges have made PL/1 a desirable candidate to transform into a modern language like C++, C#, or Java.

Modernizing PL/1 - Success is in the Details

When it comes to automated modernization and refactoring, a successful outcome lies in the details. For example, TSRI engineers spend a lot of time prior to transforming any code understanding how a step-wise process could allow a critical system to operate continuously without any disruption or data loss. Going step-wise means that some components of the system such as the login function or other application program interfaces can be modernized, tested, and, if necessary, reverted to the original application without any impact on the rest of the application or the end user. Because an automated modernization creates a like-for-like replica of the functionality in the target language—in this case C# in a Windows environment—the successful migration of each step means that subsequent transformations will be easier because the automated transformation engine continues to learn and adjust.

Following the transformation of PL/1 to the modern computing environment, an automated, iterative refactoring process can find redundant, dead, or unused code and remediate while making the entire codebase more efficient. PL/1 was designed to facilitate programming using human-readable logic so automated refactoring can also reduce code overhead significantly. Furthermore, the transformation from the monolithic environment of early mainframe languages to a multi-tier environment separates the programming from the data and the user interface enabling further functional development while preventing system disruption.

PL/1 is not unique in how the architectures that run this legacy language can be modernized but given the age of the language and lack of business or programmer support, undergoing an automated modernization may be the best way to transform PL/1 applications to modern languages and architectures.

-----

TSRI is Here for You

As a leading provider of software modernization services, TSRI enables technology readiness for the cloud and other modern architecture environments. We bring software applications into the future quickly, accurately, and efficiently with low risk and minimal business disruption, accomplishing in months what would otherwise take years.

See Case Studies

Learn About Our Technology

Get started on your modernization journey today!

Using automation to modernize mainframe applications will bring a codebase to today’s common coding standards and architectures. But in many cases, modernization to an application’s functional equivalent isn’t always enough. Organizations can do more to make their modern code more efficient and readable. By building refactoring phases into their modernization projects, organizations can eliminate the Pandora’s box of dead or non-functional code that many developers don’t want to open, especially if it contains elements that just don’t work.

Using TSRI’s automated refactoring engine, remediation was complete in an hour.

What is Refactoring and How is it Used?

Refactoring, by definition, is an iterative process that automatically identifies and remediates pattern-based issues throughout a modernized application’s codebase. For example, unreferenced variables or unnecessary redundant snippets could exist throughout the application. This scan, known as dead/redundant code refactoring, will find repetitions of any of this unusable code to flag, then remove it from the codebase. One of TSRI’s current projects found 25,000 instances of a similar issue that would have required 15 minutes of manual remediation per instance—not including the inevitable introduction of human error that would require further remediation. The number of development hours would take more than a year for a single developer to complete.

Using TSRI’s automated refactoring engine, however, remediation was complete in an hour.

Calling refactoring its own post-modernization phase is, in some ways, misleading. Refactoring typically occurs all the way through an automated mainframe transformation. As an example, in a typical COBOL or PL/1 mainframe modernization, TSRI would refactor the code from a monolithic application to a multi-tier application, with Java or C# handling back-end logic, a relational database layer through a Database Access Object (DAO) layer, and the user interface (screens) modernized in a web-based format. Believe it or not, many legacy applications still run on 3270 green-screens or other terminals, like in the graphic below.

Once the automated modernization of the legacy application is complete, the application has become a functionally equivalent, like-for-like system. However, any deprecated code, functions that may have never worked as planned, or routines that were written but never implemented will still exist. A process written in perhaps 1981—or even 1961—may have taken far more code to execute than a simple microservice could handle today.

Situations like this are where refactoring becomes indispensable.

Where to begin?

Before a formal refactoring process can begin, it’s important to understand your goals and objectives, such as performance, quality, cybersecurity, and maintainability. This will typically mean multiple workshops to define which areas of the modernized codebase need attention and the best candidates for refactoring, based upon the defined goals. These refactorings will either be semi-automated (fully automated with some human input) or custom written (based upon feedback from code scanners or subject-matter experts.)

The refactoring workshops can reveal many different candidates for refactoring:

• Maintainability: By removing or remediating bugs, dead or orphaned code, or any other anomalies the codebase can be reduced by as much as one third while pointing developers in the direction of any bugs in need of remediation.
•  
• Readability: Renaming obscure functions or variables for a modern developer to fit within naming conventions that are both understandable and within the context of the code’s functionality.
•  
• Security: Third-party tools such as Fortify and CAST can be utilized to find vulnerabilities, but once found they need to be remediated through creation of refactoring rules.
•  
• Performance: Adding reusable microservices or RESTful endpoints to connect to other applications in the cloud can greatly improve the efficiency of the application, as can functionality that enables multiple services to run in parallel rather than sequentially.

What are the Challenges?

• Challenge 1: One reason refactoring must be an iterative process is that some functionality can change with each pass. Occasionally, those changes will introduce bugs to the application. However, each automated iteration will go though regression testing, then refactored again to remediate those bugs prior to the application returning to a production environment.
•  
• Challenge 2: The legacy architecture itself may pose challenges. On a mainframe, if a COBOL application needs to access data, it will call on the entire database and cycle through until it finds the records it needs. Within a mainframe architecture this can be done quickly. But if a cloud-based application needs to call a single data record out of millions or billions from halfway across the world (on cloud servers), the round trip of checking each record becomes far less efficient—and, in turn, slower. By refactoring the database, the calls can go directly to the relevant records and ignore everything else that exists in the database.
•  
• Challenge 3: Not every modernization and refactoring exercise meets an organization’s quality requirements. For example, the codebase for a platform that runs military defense systems is not just complex, it’s mission critical. Armed forces will set a minimum quality standard that any transformation must meet. Oftentimes these standards can only be achieved through refactoring. A third-party tool like SonarQube in conjunction with an automated toolset like TSRI’s JANUS Studio^® can be utilized to discover and point to solutions for refactoring to reach and exceed the required quality gate.
•  

In conclusion, while an automated modernization will quickly and accurately transform legacy mainframe applications to a modern, functionally equivalent, cloud-based or hybrid architecture, refactoring will make the application durable and reliable into the future.

--

TSRI is Here for You

As a leading provider of software modernization services, TSRI enables technology readiness for the cloud and other modern architecture environments. We bring software applications into the future quickly, accurately, and efficiently with low risk and minimal business disruption, accomplishing in months what would otherwise take years.

See Case Studies
Learn About Our Technology
Get started on your modernization journey today!

EDS awarded a sole-source contract to The Software Revolution, Inc. (TSRI) for a Proof-of-Principle project to demonstrate an automated transformation, documentation, and refactoring capability for the PL/1 source language.

Customer:  Electronic Data Systems Source & Target Language: PL/1 to Java Lines of Code: 50,000 Duration:  2 Months Services: Code Transformation, System Integration and Test Support, Automated Refactoring, and Export of the Transformed & Refactored Code to the EDS Code Generator in XMI Format