2 ms·
I have written a pair of compilers (not COBOL) myself, so at one moment I've thought about that possibility: "maybe I should spend a little time improving my CO
by acqq 6y ago
I have written a pair of compilers (not COBOL) myself, so at one moment I've thought about that possibility: "maybe I should spend a little time improving my COBOL knowledge and move to that niche."
I wouldn't have problem working in archaic language, thought I. Or with non-trivial codebases.
But then I've got another impression: the companies don't expect a new candidate just to knew the language and work with old codebases. They expect also the people to be able to work with ancient terminals, as in: no grep for you. Even worse it's "no ASCII for you." I.e. not a single tool to which I'm used I'd be able to use. Whatever I'm used to work with, I won't be able to use.
That's where I became demotivated.
- js8 6y agoI work on the mainframes. It's straightforward to download the code to modify it locally and re-upload it. Then you can use all the tools you're comfortable with. We are moving towards using Github as a main source repository, even for mainframe code. However, yes, knowledge of how to operate 3270 terminal is required. And it has a form of grep, actually, as well as compare tools. EBCDIC is just another encoding, not a huge problem.
- Animats 6y agoEBCDIC. That's still around? Ugh. COBOL apparently still has major problems with UNICODE. COBOL in IBM land can only do UTF-16. Some IBM products are big-endian UTF-16, and some are little-endian UTF-16. COBOL (PeopleSoft version) in Oracle land can do UTF-16 and, sometimes, UTF-8 in programs for fields not stored in the database. It's late for the language to be in that state.