Test-Driven Reverse Engineering.
There are two parts.
A modern language. C#, Java, Python, Scala. Do not use a DSL. Any DSL you choose simply becomes another COBOL.
A suite of test cases that the original programs appear to pass successfully.
Note that most COBOL systems have a huge number of individual application programs. Almost incomprehensible.
However, the number of programs which do database Create-Update-Delete is considerably smaller.
Step 1 is to partition the space of COBOL programs into two:
For the 80%, you can use whatever reporting tools appear relevant. Hypercubes or whatever. It doesn't matter, since this is only reporting, and any commodity reporting tool will work. Invest as little time in reporting as humanly possible. Create extract-transform-load (ETL) that populates a simple data warehouse; create metadata for that warehouse that fits a reporting tool. Done.
For the 20%, you have serious, difficult work ahead of you to gather a suite of test cases, confirm that the original COBOL actually processes them as expected, and then writing new code in C#, Java, Python or Scala to implement that programming logic.
You will find that 20% of the Create-Update-Delete programs involve simple business rules that can be easily articulated, fit the regulatory environment, and are easy to implement in Stored Procedures or Java (C# or Python) code. Avoid stored procedures. (Haterz will tell you stored procedures are essential, but can't provide a reason.)
You will find that 80% of the Create-Update-Delete programs involve exceptions, special cases, overrides and incompetent programming too horrifying to examine closely. (It's like being a character in a story by HP Lovecraft; you begin to doubt the very existence of logic or rationality.)
Make the best guess you can at this code and trust your test cases. Time spent creating test cases and samples is more valuable than time spent reverse engineering old COBOL.