I have been programming in COBOL since 1995, but wrote my last line of code on Big Iron in October 2013.
I am not sure if there is still much of a market for COBOL skills, but I could probably code COBOL in my sleep… So if these skills are required for the next millennium bug, wake me up!
The text below is just for historical perspective.
I no longer do contracts in COBOL or mainframe.
COBOL is just a part (a very important part!) of the mainframe (z/OS) ecosystem. To be proficient as a COBOL developer, you need to know a lot of other things as well:
CICS (on-line operating system)
JCL (Job control language for batch jobs)
IDMS (operating system and database)
And then you need to be GOOD at designing and building COBOL programs. (Like not using GOTO statements…)
This requires knowledge of structured programming and using tools like Nassi Scneidermann and Jackson charts.
The COBOL program uses elements from the z/OS ecosystem to work, like DB2 SQL statements, file handling, calling other programs and CICS calls.
I have written quite a bit of COBOL programs using these elements.
In 1995 I certified as a COBOL developer. In 1999 I wrote two internationally accredited COBOL exams as part of a job selection process and passed them with flying colours.
In 2002 I certified as an AllfusionGen (Gen; Cool:gen) developer. Gen is a 4gl COBOL generator which is used by many sites to maintain their COBOL applications.
It is like developing COBOL with another layer over the COBOL.
Gen has its own ecosystem in addition to that of COBOL:
Client/Server tools (Screens, GUI etc.)
Gen Tool set (Code developer)
Guardien (Version control and deployment of models)
Encyclopedia (Contains models)
I have done development with Gen for a total of nine years.
In 2004 I started on a project were we needed to build mainframe adapters for a home-grown Service Orientated Architecture (SOA).
I designed the adapters and standardised them. Once the architecture had matured I could produce a new interface within hours. Due to the standardisation my team could produce interfaces as if on a factory production line.
Xml and xsd was used in these adapters.
In 2012 I started on a project to migrate these adapters to TIBCO. (See tab ‘TIBCO’ for more details.)
I am very comfortable in the mainframe ecosystems and I have extended it to include the xml world and the TIBCO stack.