It is said that it is easier to convert a COBOL programmer to Java or .Net than for the middleware programmer to COBOL technologies. Why, first the reluctance of the former to learn a legacy technology and the second it is much structurally rigid as fas as following rules in coding and logic constructs.

But just like the article on learning Java for the COBOL programmers, learning this language is not hard if given enough perseverance and mentoring. First, you have to get hold of a IBM z/os or mainframe or for that matter a Microfocus Focus PC or Unix server. Second, got to have an opportunity to code it by maintaining existing code or writing a new simple code integrated with Java or .Net in the presentation layer. Second, got to know the online counterpart of Java or .Net like CICS or IMS DC.

After learning the basic of these technologies, then you have to write the batch execution job, called JCL.

Simply put, COBOL language has rigid rules for coding. The comment goes on the 7th column. The first letter of the code should start on the 8th column. The program has to be divided into Configuration Division, Working Storage Division, File Control, and Procedure Division. There is no such thing as a . call as in object.method but the call is done through 'perform a certain paragraph or section name which contains the sub-routine just like in a function call. Everything is done procedurally although goto's which are not recommended can be done. This is called spaghetti coding which is taboo in structurally written COBOL. When you see such you would know that it was written way back in the '70's.

Now for the JCL. It is composed of the job card portion, the exec statement and the DD statement. All JCL are written in a 80 byte size length owing to the old card reader machine where the cards are 80 bytes long and are punched in a puncher machine. The job are fed into what they call an internal reader which is an off-shoot of the punch card reader in the old days.

More to come in my eBook...