Skip to content
How it works

The running system is the specification.

Nobody has a reliable description of what a thirty-year-old system does, except the system itself. So Cobra starts there. It reads the estate, runs the COBOL unchanged, proves each business rule against the real program, and lets you change the estate in small steps you can reverse.

How Cobra works
How Cobra works: read, run, prove, change in stepsYour estate feeds four stages from left to right. Each stage produces an artefact. Evidence from the Prove stage links back to the catalogue made in the Read stage.Your estateCOBOL, PL/I, assembler,JCL, CICS, IMS,files and databasesReadCatalogue every program,record, field, call and job1The catalogue andthe estate mapRunUnchanged, on a realruntime in a container2Your system, runningon modern infrastructureProveOne rule, one sourceline, one test3Decision tables,each row with a testChange in stepsOne slice at a time,each step reversible4Slices moved,each one provedWhat eachstage producesEvidence: every finding links back to a source line
Read this diagram as text
  1. Read. Cobra catalogues every program, record, field, call and job in your estate. It produces the catalogue and the estate map.
  2. Run. Your COBOL runs unchanged on a real runtime in a container. You have your system, running on modern infrastructure.
  3. Prove. Each business rule becomes one row of a decision table, tied to its source line, with a test that runs the real program.
  4. Change in steps. Work moves one slice at a time, and each step can be reversed.
  5. Every finding links back to a source line in the catalogue.
The philosophy

Four beliefs behind everything Cobra does.

  1. 1

    The only reliable description of an old system is the system

    The documents are old or missing, and people remember some rules and not others. One source is always correct: the system itself, while it runs. So Cobra starts there, not with interviews.

  2. 2

    Trust comes from proof that you can run again

    Each business rule is one row of a table, with the line of code that applies it and a test that runs the real program. If a later change breaks a rule, the test fails in minutes.

  3. 3

    Move first, then change. One thing at a time, with a way back

    A migration changes the software, the computers and the data. Cobra moves the software unchanged, proves the results are the same, and only then changes anything. The earlier state stays available.

  4. 4

    AI does the work. Proof approves the work

    AI makes it practical to read every program, write down every rule and test it. But AI never approves its own work: approval comes only from checks the platform calculates itself.

Step 1 · Read

One catalogue of everything the estate contains.

The Dictionary reads the source the way a compiler does and records every program, record, field, call and job. Engineers and AI agents ask it questions and get facts, each with the line it came from.

One catalogue, many questions
One catalogue, many questionsSeven source technologies on the left feed one Dictionary in the centre. Engineers, AI agents and architects on the right ask it questions and get facts read from source.Your sourceCOBOLPL/IAssembler (HLASM)JCLCICS / BMSIMS/DBMQSeriesThe DictionaryPrograms, records, fields,calls, jobs and data lineage.90+ read-only tools.Every answer cites its source.Who asksEngineer“Where is this fieldwritten, and when?”AI agent“What calls thisprogram?”Architect“What breaks if thisrecord changes?”
Read this diagram as text
  • Cobra reads COBOL, PL/I, assembler, JCL, CICS and BMS, IMS/DB and MQSeries into one Dictionary.
  • The Dictionary holds programs, records, fields, calls, jobs and data lineage, and answers through 90+ read-only tools.
  • Engineers, AI agents and architects ask it questions such as where a field is written, what calls a program, and what breaks if a record changes.
Step 2 · Run

Your COBOL, unchanged, on a real runtime.

The programs run inside a genuine Rocket Visual COBOL run unit, in a container. Nothing is simulated and nothing is rewritten. Nearly 4,000 programs of one production estate compile and run this way today.

Platform architecture
Cobra platform architecture in three tiersInside one container: engineers and AI agents query the Dictionary; the Cobra integration layer calls your COBOL programs in the Rocket Visual COBOL run unit, a licensed third-party runtime; data access providers serve your files and databases.One container: on Linux, in the cloud, or beside the mainframeEditor and metadataEngineers and editorsNavigate, diagnose, reviewAI agentsAnalyse, capture rules,build testsDictionaryAuthoritative facts about every program, record, field and jobqueryRuntime and integrationCobra integration layer (.NET)Calls, marshalling, test harness,links to modern servicesRocket Visual COBOL run unitYour COBOL programs, unchanged.Licensed third-party runtime.calldescribesDataData access providersOne layer between the programs and the dataYour files and databasesLegacy files, relational databasesread and write
Read this diagram as text
  1. Editor and metadata. Engineers, their editors and AI agents read facts about the estate from the Dictionary.
  2. Runtime and integration. The Cobra integration layer on .NET calls your COBOL programs, which run unchanged in the Rocket Visual COBOL run unit. The runtime is a licensed third-party component from Rocket Software.
  3. Data. Data access providers serve your existing files and databases to the programs.
  4. All three tiers run in a container: on Linux, in the cloud, or beside a mainframe.
Step 3 · Prove

One rule, one source line, one test.

Each rule a program applies is written down as one row of a decision table, with a test beside it that runs the real program and checks a value the program computed. 46 programs are covered this way today, 1,980 rules in all.

Anatomy of a proved rule
Anatomy of a proved ruleA COBOL source line becomes one decision-table row. A test runs the real program on seeded data and reads the value the program computed. If the value matches the row, the rule is attested. If not, the result is a finding with its line, cause and proposed fix.COBOL source linesIF WS-BALANCE < ZERO MOVE 'OD' TO WS-STATUSEND-IF1Decision rowWhen: balance is below zeroThen: status is ODSource: lines 412 to 4142TestSeeds a balance of -1.Runs the real program.Nothing is mocked.3Computed valueRead from a recordthe program wrote:status = OD4Matches the row?yesRule attestedEvidence recorded for auditnoFindingThe line, the cause anda proposed fixWhat stays togetherThe row, its source lines, its test andits result are kept side by side, so areader can check any one against theothers. The example is invented.
Read this diagram as text
  1. The rule starts as lines of COBOL source. The example here is invented.
  2. It is written down as one decision-table row: a condition, an expected outcome, and the source lines beside it.
  3. A test seeds the data and runs the real program. Nothing is mocked.
  4. The test reads a value the program itself computed.
  5. If the value matches the row, the rule is attested. If it does not, the result is a finding: the line, the cause and a proposed fix.
Step 4 · Change in steps

Find where the estate divides before you cut it.

The estate map reports which parts of the business could be lifted out, and what each one would have to cut. The hard part is usually shared data, not shared code, and the map names the records that have to find an owner.

Where an estate divides
Where an estate divides: the code divides, the data does notThree panels. First, programs group cleanly into capabilities. Second, the same capabilities against record types: some records are written by more than one capability. Third, one slice lifted out: the records it owns move with it, and the shared records are kept in step by replication.1. The code dividesBillingits own programsClaimsits own programsPolicyits own programs2. The data does notBillingClaimsPolicyR1R2R3R4R5R6shared recordRecords written by more than onecapability cannot simply move with one.3. A slice takes what it ownsBilling slice, on CobraR1R2R3owned: movedshared: a copyreplicationClaims and Policy, stayingR3R4R5R6The code divides. The data does not, so the data is sliced where it can be and replicated where it cannot.
Read this diagram as text
  1. The code divides. Programs group cleanly into business capabilities such as billing, claims and policy.
  2. The data does not. Some record types are written by more than one capability. On one measured estate, 123 of 198 record types are written by two capabilities or more.
  3. So the data is sliced where it can be, and replicated where it cannot. A slice takes the records it owns. Records it shares with capabilities that stay behind are kept in step by data replication tooling.

A slice therefore includes its part of the data model. Records a capability owns move with it. Records it shares with capabilities that stay behind are kept in step by data replication tooling, such as IBM’s Change Data Capture. You know which case applies before work starts, because the map measures it.

How this is different

Three things change in a migration. Change one at a time.

A full migration changes the software, the computers that run it, and the data. Replacing all three at once is high risk. Replacing them in stages with a rewrite means years of old and new software, old and new computers, and data copied between them in two forms. Cobra does neither.

Three things change in a migration
Three things change in a migration: the software, the computers and the dataA grid. Three approaches in rows: all at once, in stages with a rewrite, and Cobra. Three columns: the software, the computers it runs on, and the data. All at once changes all three on one day. A staged rewrite mixes old and new in all three for years. Cobra moves to new computers first, with the same software and the same shape of data, and makes other changes later, one at a time.The softwareThe computersThe dataWhat you carryAll at onceReplace everythingin one moveNewWritten againNewOn the same dayNewReshaped forthe new codeHigh riskThree changeson one dayIn stages, rewrittenReplace part by part,over yearsOld and newMixed, for yearsOld and newTwo platformsOld and newCopied andreshapedHigh complexityA mix of old andnew in all threeCobraMove first,then changeThe sameUnchanged. Changelater, where it paysNewThis moves firstThe same shapeMoves with the code.Reshape later if wantedOne changeOne kind of changeat a time
Read this diagram as text
  • All at once. New software, new computers and reshaped data on the same day. High risk.
  • In stages, rewritten. Old and new software, two platforms, and data that is copied and reshaped between them, for years. High complexity.
  • Cobra. The computers change first. The software is the same and the data keeps the same shape. Other changes come later, one at a time.
Three approaches to a migration, by what happens to the software, the computers and the data
ApproachThe softwareThe computersThe dataWhat you carry
All at onceNewNewNewHigh risk on one day
In stages, with a rewriteOld and new, mixedOld and newOld and new, copied and changed in formHigh complexity for years
CobraThe sameNewThe same formOne kind of change at a time

Cobra moves the software to new computers first. The software is the same, so the data keeps the same form. That removes the all-at-once risk, and most of the complexity of the staged approach. After the move, you change the software and the data where there is a business reason, on a system that is already proved.

Cobra also works beside whatever conversion or transformation tooling you or your integrator choose: the catalogue, the decision tables and the tests describe and prove the behaviour, whichever path the code then takes.

See it on your code

Start with one slice.

One part of the business, running on Cobra, with its rules tabled and tested. You see how it works on your estate before you commit to a programme.

Start with a sliceSee three scenarios