Take back control of your Cobol assets / migrate

 


ellipsys
 
 Take back control of your Cobol assets / migrate  
 
Cobol, the symbol of "IT debt"
 
 
The "Cobol" teams are being reduced
The oldest part of information systems ("legacy system") is in the hands of a population of specialists whose number continues to shrink. This is the case of Cobol specialists. And these teams are often overwhelmed with requests.
 
The decommissioning of Cobol is constantly postponed
Rather than removing or transforming the oldest technical layers, typically the Cobol layer, companies have piled them on so as not to take any risks. It is also true that the Cobol has acquitted itself well of its mission so far!
Thus in many companies, the problem has been circumvented at the start of the most recent technologies, to adapt and manage the old data formats ("ascending compatibility"). This for a very long time now.
 
But this state of affairs is not irremediable.
We will have to start by "opening up" the system, and bringing it to everyone's attention, ie making it understandable by all the data teams. Then you will have to seriously consider migrating, because it's never too late to do well 😊. This is our proposal.e
 
 
 
A dynamic mapping of streams processed by Cobol (and other languages)
 
data lineage
 
Our bias is to do dynamic "reverse engineering" of the Cobol code with {openAudit}, and to present the flows graphically, in the form of "maps" based on the "data lineage". These dynamic maps can be ultra granular, or more comprehensive.

Enhanced with a search engine, this "data lineage" makes it possible to define for each piece of data, its origin, its future, and it provides access to the underlying management rules. The specificities of Cobol are covered:
  • Programs (.cbl),
  • Structure files (.cpy),
  • And Settings files (.jcl).
 
 
Automate Cobol migration
 
ellipsys
 
Once the heritage has been mastered, the main difficulty will remain its rewriting in a third-party technology, one that will allow the company to project itself. If the rewriting of hundreds of thousands/millions of lines of code has not taken place so far, it is because the "risk of losing" was too high. This is no longer the case with {openAudit}.
 
Process automation allows you to quickly reach the target, while minimizing regressions. 
  1. {openAudit} will "parse" the Cobol, it will break down all the complexity of the code thanks to a grammar allowing exhaustive and ultra granular analyses. All the subtleties of Cobol will be taken into consideration.
  2. {openAudit} deduces the global kinematics, and the intelligence, which will be reconstructed in an agnostic algorithmic tree,
  3. Based on this, {openAudit} will produce "standard SQL",
  4. Then the intelligence will be reconstructed at least in the specific SQL of the target database,
  5. All complex processing that cannot be reproduced in simple SQL will be driven by a NodeJS executable, or other.
 
 
 
Conclusion 
  
A lot of companies are legitimately worried about getting out of Cobol.
The choice of automation, both to provide everyone with the concrete reality of what Cobol builds as a flow, and both to consider a migration, can make it possible to take this step in a simple and effective way.
 
#cobol #migration #cloud

Commentaires

Posts les plus consultés de ce blog

Sur-administrer une plateforme SAP BO simplement

Migrer de Oracle à Postgre en automatisant le processus !

La Data Observabilité, Buzzword ou nécessité ?