Comment by skissane

> I worked specifically on connecting COBOL system to a DB/2 database, and one thing was for certain: understanding the data format was the hardest part of the problem.

But now you are shifting the goalposts: from getting readonly access to the data, to understanding what it actually means. Yes, I totally agree, a lot of legacy COBOL systems, it can be very hard to work out what the data actually means - even though you probably have a COBOL copybook telling you what the columns/fields are, they can be full of things like single letter codes where the documentation telling you what the codes mean is incorrect. And likewise, you are right that seemingly simple tasks like adding a field can be monumental work given the number of different transaction screens, reports, batch jobs, etc, that need to be updated, and the fact that many mainframe programmers don’t know what “DRY” stands for

But simply getting read-only access to data? Most mainframe COBOL systems would already support that. Could there be some really badly maintained ones in which it was never configured properly and they just give DOGE read-write access because DOGE refuses to wait for it to be done properly? I doubt that’s the norm but it might be a rare exception. Such a system would likely violate security standards for federal IT systems, but agencies can get exemptions.