Introducing the Natural Language Analysis Assistant

Gary Evans

Overview

Many organizations are reliant on, and gain competitive advantage from, applications that have been developed over a long period of time. These applications undergo significant change over that time, which produces an increasing degree of complexity. In many cases, the original developers of those applications are no longer working within these organizations. This results in new developers struggling to understand the code base so they can maintain these critical applications safely and efficiently. 

Rocket Software’s Enterprise and COBOL Analyzer have lengthy experience providing developers with knowledge at the point of change for such complex code bases, enabling newer developers to perform maintenance tasks. Many of those analysis capabilities have been integrated into the Eclipse and Visual Studio IDEs with Rocket® Enterprise Developer and Visual COBOL. But the advent of AI and Natural Language Interfaces have brought a new outlook on how developers wish to interact via their development tools.

In the 10.0 release of Enterprise Developer and Visual COBOL, Rocket Software has introduced the Natural Language Analysis Assistant. This feature will help developers understand the full application they are working on using modern, standard development tools, familiar to both COBOL and non-COBOL developers.

Developers will be able to make changes to the files or programs, confident that these changes will not have a negative impact on the rest of the application. 

The Analysis Assistant offers a chat window where the developer can ask questions in ‘human’ language (just English for now) about their COBOL or PL/I applications against a code base held in an Enterprise Analyzer or COBOL Analyzer repository.

analysis assistant chat window

 

Survey

To help ensure that our future roadmap includes your feedback and considerations, please take our survey.

Take the survey

 

Behind the Scenes

So how does this work?

Three components of a high-level architectural overview:

  1. The IDE 

    This is where the developer asks a question in the chat window and the results are displayed.

  2. The Natural Language Engine

    The Natural Language Engine does all the hard work. It takes the developer’s English language question, turns it into an EA query(s), passes the query(s) to EA, and then generates a natural language response from the result, which is passes back to the IDE.

  3. The Remote Enterprise Analyzer Server

    All the information about the potentially huge application lives here.

    The EA Server runs the query it receives from the engine and passes back the results. 

analysis assistant architecture

 

More on The Natural Language Engine

Now let’s dive a bit deeper into The Natural Language Engine:

The functionality has been developed using Apache OpenNLP, which is a natural language processing library written in Java. It runs locally and has a fairly small footprint, with no requirement for advanced processors such as a GPU or CUDA, which are typical with AI. It is worth noting that The Natural Language Engine is also not backed by a Large Language Model (LLM).

The engine includes two models that have been trained in advance. They handle two separate and distinct tasks.

  1. Categorisation

    The Categorisation phase is where the query is classified. It works out what the user is actually asking for.

    For example, is the user asking for a count of something in the program or for a program flow or for references?

  2. Named Entity Recognition (NER)

    The NER model is used to locate points of interest in the query string that may refer to names. For example, program names, section names, or paragraph names.

  3. Linguistic Processing

    Finally, there is some additional linguistic processing to gather extra context for the query. This could include clarifying the linguistic subtleties of “does A call B” or “is A called by B” and ensuring that this is represented correctly in the query.

Once all the information has been gathered, potentially multiple queries are sent to EA.

Once the final response has been received from EA, the Natural Language Engine will generate a natural language response to send back to the IDE.

For a demonstration of the Natural Language Assistant, watch this video.

Natural Language and Artificial Intelligence for Developers of Mainframe SubSystem (MSS) applications

It is hard to find an article in the IT press and social media today that does not include some reference to Artificial Intelligence, particularly with assisting developers in the writing of application code. 

There has been increased adoption of such tools for languages like Java and C# etc, in the world of COBOL and PLI. But the predominant languages for MSS applications, AI or Natural Language have yet to become mainstream. This is especially true for the applications that interact with the Mainframe Subsystems of CICS, IMS and JES.

Many of the vendors that are looking to bring AI to this scenario are extending existing ‘automated refactoring solutions’ to include AI, which results in a complete rewrite and rearchitecture of the application using other languages. But this approach does not have a proven track record. Though it may provide assistance to some developers, it is not necessarily the developers that maintained the application in the first place.  

At Rocket Software we are looking at how AI and Natural Language can assist developers of MSS applications with their day-to-day challenges, without the risk of converting the code base to another language.

So, what are those day-to-day challenges?

  • Monolithic programs that are difficult to maintain and especially test.
  • Lack of application SME knowledge
  • Skills issues pertaining to the Mainframe Subsystems
  • Lack of ‘shift left’ and automated testing
  • Extensive lead time and cost of provisioning testing environments

It is important to note that none of these challenges relate to the languages in which the applications are written. 

We already started to explore the first two challenges on the list by discussing the Natural Language Analysis Assistant earlier this blog post. Ongoing investment and innovation in this area will extend its usage by harnessing further capabilities, already available in Enterprise and COBOL Analyzer but making it easier to use. 

If we consider the general requirement of refactoring monolithic code, then imagine writing in the chat window Create a new program called BBANKLCP from section AA-Loan-Calculation from program BBANK70P, which then utilizes the existing code slicing and refactoring capabilities to create that new program and amend the original code to use it. This would help break down the monolith, easing maintenance and making this code easier to test, including simplifying the introduction of unit tests.

Regarding unit tests, to help introduce ‘shift left’ testing, the next request could be Write a unit test for program BBANKCLP. This could automatically create all of the Unit Test Framework components, including (where necessary) any mocking/stubbing components required.

Going a step further and considering reducing test preparation lead times, we could write a request Create me an Enterprise Server test instance to run program BBANKCLP. This would provision a test instance with just enough configuration to support the test, whether it be CICS or Batch.

The COBOL language is not one of the main challenges we would consider addressing. But providing code completion or generation to subsystem code within the COBOL program would be advantageous for developers new to working with MSS. This is why requests such as Create code that provides input and output to CICS screen MBANK10, could generate CICS SEND and RECEIVE commands. Similar requests could also be available for access to data files, SQL, and IMS data. This would equally apply to code to call other programs in a CICS context or invoke a webservice.

The final issue, lack of application SME knowledge, is where assistance for code understanding and documentation becomes essential. Requests such as Explain paragraph AA-COMPLEX-CODE, How is data item WS-UNCLEAR-FIELD-NAME is being used, or What is the origin of data item WS-WHAT-SETS-THIS-FIELD would all help with that understanding. And to further help the next developer maintain this program, a request to Add these comments to the code all would be beneficial.

These are just some of the ideas that we are exploring, based on the issues we’ve discussed with our customers. And there are more to come. 

To assist with ensuring our future roadmap considers your needs, please take part in our survey.

Take the survey

 

Try it out 

If you are an existing customer of Enterprise, COBOL Analyzer, Enterprise Developer, or Visual COBOL, you can already access the 10.0 version. 

If not, please get in touch with your Account Executive or ask for a trial license in this link: /products/enterprise-suite/request-contact  

Feel free to contact Gary directly with any questions or feedback and I’ll be happy to discuss your challenges and our solutions.