Displaying items by tag: Java

 

  • Customer: US Department of Defense & Northrup Grumman
  • Source & Target Language: Ada to Java  
  • Lines of Code: 981,337
  • Duration:  9 months
  • Services: Automated Code Transformation, New Language Gateway TransformationAutomated Refactoring, Semi-automated Refactoring, Engineering Support, Application Blueprint®, Transformation Blueprint®

    

Published in Case-Studies
Wednesday, 30 March 2022 14:17

MUMPS to Java HRG MGS TAPS CHCS

TSRI, contracted withHawaii Research Group (HRG),  supported the task of finding the subset of code within CHCS and use its innovative JANUS Studio® toolset to automatically transform the legacy code to modern code. 

  • Customer:  HRG
  • Source & Target Language: MUMPS to Java
  • Lines of Code: 1,000,000
  • Duration:  4 months

 

Published in Case-Studies
Wednesday, 30 March 2022 14:04

COBOL to Java J2SE Telos Corporation

The Defense User Registration System (DURS) of the Defense Technical Information Center (DTIC) consisted of a UNISYS 2200 COBOL application running within the DPS form-based presentation system (DPS 1100). DURS required conversion into a Java/J2SE multi-tiered application to support DTIC modernization requirements.

  • Customer & Integrator: Telos Corporation
  • Source & Target Language: COBOL to Java/J2SE
  • Lines of Code: 80,000
  • Duration: 13 months
  • Services: Developed Web-Enabled User Interface, Code Transformation, Automated Refactoring, Automated Re-Architecting, Database Transformation, Transformation Blueprint®

Published in Case-Studies
Wednesday, 30 March 2022 14:04

Fortran to Java Sandia Labs

A highly classified application, consisting of Fortran 77 and Fortran 95, required modernization to JAVA. SANDIA, a wholly-owned subsidiary of Lockheed Martin, contracted with TSRI for the use of its JANUS Studio® to complete the code transformation in a secure facility. 

  • Customer & Integrator:  Sandia Labs
  • Source & Target Language: Classified and Un-Classified Fortran to Java
  • Lines of Code: 156,200
  • Duration:  5 months
  • Services: Automated Modernization, Knowledge Transfer, Engineering Support

Published in Case-Studies
Wednesday, 30 March 2022 13:57

Assembly to Java - IRS Tax Processing System

TSRI, in partnership with Hewlett-Packard, rapidly adapted its automated JANUS Studio® transformation engine to be ALC-compatible so they could conduct an ALC-to-Java prototype modernization effort for the US IRS. The high levels of automation enabled quick transformation and refactoring iteration, which rapidly and systematically discovered and isolated defects. Allowing TSRI engineers to quickly adjust the automated conversion rules, and quickly regenerate the system at higher output quatlity.

Customer: Hewlett-Packard and The US Internal Revenue Service (IRS)

Source & Target Language: Assembly to Java

Lines of Code: 8,000

Duration:  1 Month

Services: Automated Code Transformation, Automated Refactoring, Integration and Testing Support, Defect Isolation, Transformation Blueprints ®, Application Blueprints ® 

 

 

Published in Case-Studies
Wednesday, 30 March 2022 13:50

Fortran to Java - US Air Force WDAC System

Raytheon Corporation awarded a sole-source contract to TSRI for modernization of the US Air Force’s Weather Data Architecture Capability (WDAC).  This project was completed very quickly and successfully, using TSRI's fully automated toolset, including the automated production of documentation and refactoring to remove dead and redundant code.

Customer: Raytheon & The US Air Force

Source & Target Language: Fortran to Java

Lines of Code: 47,426

Duration: 1 month

Services:  Automated Code Transformation, Automated Refactoring, Integration and Testing Support, Transformation Blueprint®Application "As-Is" Blueprint®

 

 

Published in Case-Studies
Wednesday, 30 March 2022 13:43

COBOL & JCL to Java & Python - Deutsche Bank KM

Deutsche Bank's relatively reliable mainframe infrastructure utilized COBOL and JCL languages running DB2 and VSAM flat-file databases for a variety of their key financial applications. The company’s leadership knew they would need to be cloud-enabled with a modern architecture to stay relevant for its customers and ongoing market needs. Following a successful proof of concept against other well-known industry soluitons, TSRI emerged as the best solution (highest quality output and most advanced architecture) for the full modernization effort of Deutsche Bank’s internal KreditManager application. An application which gives the company’s employees all of the tools they need to handle all of the company’s loan, credit and mortgage applications.

Customer: Deutsche Bank

Source & Target Language: COBOL & JCL to Java & Python

Lines of Code: 397,222 (383,358 - COBOL, 13,864 - JCL)

Duration:  12 Months

Services: Automated Code Transformation, Automated Refactoring, Integration and Testing Support, SonarQube Quality Refactoring, Code-Specific Adaptation, Database Migration, Transformation Blueprint®, Application "As-Is" Blueprint®

 

 

Published in Case-Studies

The U.S. Air Force uses the Integrated Logistics System – Supply (ILS-S), of which the Standard Base Supply System (SBSS) is a major part, as a mainstay of their supply chain. The SBSS program includes over 1.5 million lines of COBOL, as well as smaller numbers of C and Assembly, all of which are to be transformed into Java. 

  • Customer & Integrator: US Air Force
  • Source & Target Language: COBOL to Java
  • Lines of Code: 1.5 million
  • Duration:  11 months
  •  
Published in Abridged Case Studies

No change in business logic.
Reduction in overhead costs. 
Continuous development during and after migration.

These are a few modernization concepts that Scott Pickett, TSRI’s Vice President of Product Operations and Service Delivery, discussed on his recent appearance on Amazon Web Services’ APN TV channel. 

“TSRI allows for an ability to do automated transformation of not only your language, but your application to the cloud environment, allowing you to bring in skilled, modern technology to your legacy implementations, being able to drive down the cost point associated with ongoing operational costs, and being able to deliver new applications, new functionality, new screens, and new capabilities in that modern language,” he said in his talk. 

So what does that mean, exactly? 

In TSRI’s modernization of a major European bank to the cloud, that meant they modernized approximately 80,000 lines of code at 99.7% automation. In other words, only 384 of those lines of code were hand-written. That's big for a project of this size—but it's huge when you're talking about applications with hundreds of thousands or even millions of lines of code!

For any organization, whether in commercial enterprise organizations like the banking client mentioned above, or in government agencies, modernization reduces risk. 

 

“You're able to bring a new skill set, new experts that know Java and know CI and CD tools and apply them to your legacy application that's been modernized,” Scott said. “It literally also allows for the ability to drop tens of thousands, and even hundreds of thousands of dollars, off your monthly costs.” 

 

 

As Scott also noted in his presentation, “we can not only transform code quickly…because there are very, very few manual changes, but it also means that you can migrate to the cloud and then be able to not have any business logic change associated with that migration.” 

Maintaining business logic is a big deal when it comes to systems that measure their age in decades rather than years and the original programmers have long since moved on. 

One other interesting point Scott brought up is how TSRI’s tools have enabled customers to maintain agility and competitive advantage by providing its clients with the modern, cloud-based applications they need—all while reaching back to its legacy DB2 database that supports the applications that have yet to be modernized. 

Throughout the talk, Scott also pointed to how TSRI has adopted a step-wise model, which modernizes small applications or pieces of an application, tests for validity, then pushes into production before the next applications are transformed. Such a methodology allows the client to continue to develop in the legacy language, maintain a common data set, and minimizes business disruption to almost zero. 

 

 

“There’s no big delay. You can continue developing the legacy and we can migrate those legacy applications while the transformations are happening and migrate them into your modern environment,” he said. 

 

Scott also explains the steps of an automated migration in layman’s terms and how a TSRI transformation integrates cleanly into cloud services like AWS using containerization and microservices. 

We of course don’t want to spoil the presentation by giving everything away, so head over to APN TV and watch for yourself to learn about how automated modernization to the cloud will save your organization time, money, and the headaches from continuing to maintain legacy systems. 

 

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!

 
 
Published in AWS

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!

Published in Education
Page 1 of 3