COBOL programming is one of the most sophisticated and comprehensive programming environments in existence. There are many approaches to troubleshooting COBOL source code. In infancy the COBOL programmer typically places display statements in the program to sort of track the processing path of the application. The results of the display statement would appear on a system output device usually standard system printed output queue. To examine the contents of a specific part of data more source code was created just to handle such a situation.
The other option would be to interpret core dumps or system dump COBOL programming is one of the most sophisticated and comprehensive programming environments in existence. There are many approaches to troubleshooting COBOL source code. In infancy the COBOL programmer typically places display statements in the program to sort of track the processing path of the application. The results of the display statement would appear on a system output device usually standard system printed output queue. To examine the contents of a specific part of data more source code was created just to handle such a situation. The other option would be to interpret core dumps or system dumps. This is also a daunting task because the programmer had to understand exactly how IBM, Sperry or Honeywell processed application programs once loaded into memory. To give a brief example the IBM operating number systems were binary and hexadecimal (base 16). The Sperry and Honeywell operating number systems were binary and octal (base 8). My head is hurting already. Now in the IBM environment you have to know how to locate various pointers. As an example, to determine the offending computer instruction you had to know the base address of register fourteen. At displacement of register fourteen plus twelve words forward (offset of twelve words) is the offending instruction. Another example is that the beginning of working storage was and offset from BLL cell number eight. If this all sounds like Greek it pretty much is. The Sperry architecture employs a separate strategy of registers and locating specific instructions in a COBOL program. The Honeywell architecture employed a more bizarre strategy for retrieving information from a core or system dump. I was never more relieved when I learned to effectively use the COBOL debug facility.
The COBOL debug facility allowed for debug packages (a specific structured syntax) that would identify specific lines of COBOL source code as they were executed. The data used in the instructions as well as the instruction itself would be dumped to the system output queues in a format that makes sense to a COBOL programmer. This approach saves paper because instead of dumping a snapshot of the entire memory map (usually several hundred pages) only the pertinent areas of memory are dumped (usually one page). Learning COBOL is labor intensive and time consuming.
Learning many of the idiosyncrasies of COBOL and the finer aspects of using COBOL is more labor intensive and requires even more time. Please feel free to contact me at my web site below for further assistance in this as well as other endeavors. Simply click on the free consultation link at the top of every active page on the web site.
Mr. Arch Brooks, Software Engineer