the language itself is not usually the main obstacle when it comes to dealing with legacy code. interfaces between logically distinct parts of the code will be

the language itself is not usually the main obstacle when it comes to dealing with legacy code. interfaces between logically distinct parts of the code will be fuzzy or nonexistent. you can't trust comments or sometimes even the names of functions (if the code is this structured at all!). you have to look at what every function you're calling actually does, what global variables it depends on, search for weird cases elsewhere that can change those globals, this type of stuff. you have to build intuition implicitly from the code about design paradigms the organization used when the code was written. sometimes if the code was actually maintained, you end up learning several sets of paradigms from different eras. at the end of all this, much of your accumulated knowledge might not apply outside of that organization. you could be starting almost from scratch at your next job working on legacy code. I don't mean to discourage you; it can be quite satisfying. it has almost an archeological feel sometimes. if you're a college student, I might recommend getting into c or c++ instead of cobol though. you'll have a much easier time finding an entry-level job when you graduate, and you'll at least have the option of working on newer projects too.