Over the years, the COBOL language has evolved as a result of the various standards committees in place. COBOL is typically a procedural language (although the standards committee has approved object-oriented extensions to COBOL).
This means that traditional COBOL programs are structured to define files and data statically, followed by fixed procedures, which are executed in a structured, hierarchical pattern. The flow of control is strictly under the control of the programmer, and he or she is responsible for every aspect of the entire application.
To interact with terminal console screens, early COBOL provided the ACCEPT and DISPLAY verbs. These were and still are single line-oriented read and write functions for the console.
Over the years, COBOL screen I/O has evolved in a variety of ways from specific language vendors implementing proprietary extensions.
Some of these extensions have included enhancements to the ACCEPT and DISPLAY verbs to allow for full screen I/O, such as positioning on a specific row and column on the screen.
The implementation of the SCREEN SECTION by several vendors allowed for an entire screen layout to be predefined, complete with a variety of field attributes available. The ACCEPT and DISPLAY verbs were then used for an entire screen, as opposed to a single line on the display.
Vendors such as IBM implemented complex on-line transaction processors (OLTP) such as CICS and IMS/DC on mainframes.
This approach separated the screen handling from the program, defining an application programming interface for interacting with predefined screens. These screens were defined by writing assembler language macros (for example, BMS and MFS) which were compiled and assembled outside of the COBOL program.
The COBOL program was given a data and attribute definition block to work with, while all of the complexities of managing the actual screen I/O and physical display were taken care of by the On-line Transaction Processor (OLTP).
When graphical user interfaces (GUI's) first arrived, they required complex application programming interfaces. This proved to be a very complex and tedious development task for the typical programmer. It was common for 60% or more of a program's application logic to be dedicated to handling the GUI alone.
These programs proved to be extraordinarily complex, unstable, and non-portable to other GUI environments.
Realizing these problems, language tools vendors began developing higher level "GUI painter" products that would allow developers to create GUI components (for example, screens with push buttons) and would then generate large portions of the associated program code.
This approach proved helpful, but developers were still responsible for creating the entire application architecture and making sure all of the application components interacted properly.
Later, development tools vendors attempted to provide higher level GUI development tools that would allow the painting of an entire GUI for an application. This typically included a scripting language that allowed the developer to define the interaction between GUI components within the GUI development environment, and thus outside of the actual COBOL application.
The COBOL application could then make simple calls to the GUI run-time provided which would then manage the GUI outside of the actual application.
The main benefits from this approach were that the COBOL application code shrank significantly and programmers could concentrate on dealing with application-specific needs like file and database I/O.
Some of these GUI run-times were portable to other operating systems, and the overall GUI development process was simplified as it was logically separated from the application.
The drawbacks to this approach for COBOL developers were that the scripting languages were not in COBOL, and the developer was thus forced to learn a new language. The developer additionally had to be careful to design the application architecture to properly interact with the GUI run-time facility.
Another less obvious drawback was the fact that GUI's are typically object oriented and deal with the operating system in a recursive and object-oriented fashion, while COBOL has remained primarily a procedural language. COBOL developers are thus often forced to fit the procedural model of a COBOL program onto the more object-oriented model of a GUI.
PowerCOBOL solves these problems in the following ways:
