Understanding the overall architecture of a PowerCOBOL application is the key to developing consistent and efficient applications. In this section you will learn not only about application architecture, but also how to access files and data items across multiple forms and programs.
PowerCOBOL makes extensive use of newer enhancements to the COBOL language in order to effectively design the application architecture.
For many years, a major complaint about COBOL versus newer programming languages was that COBOL is too static.
Some other programming languages support the creation of functions that have their own local data items. In a traditional COBOL program, all data items must be predefined in the WORKING-STORAGE or LINKAGE Sections.
This means that these data items are accessible from any portion of the COBOL program.
Local data is the concept of having a function (for example, a sub-routine) that has its own data items, which are not made available to the rest of the application. Only the function is aware of its data and thus only the function may change its data.
This is one of the basic building blocks of object-oriented programming. It allows developers to break up complex applications into smaller, more easily managed functions that in turn encapsulate their data and methods.
The ANSI 85 specification thus includes support for embedded programs. This allows COBOL programmers to create independent COBOL programs (complete with a unique Program-ID) and to embed these independent programs right into an existing COBOL program. They may then be called like normal external COBOL programs.
Because these programs are embedded into the main application, they are much more efficient to communicate with at run-time. Additionally, they may encapsulate their own data and sub- functions (methods) within an application.
NetCOBOL fully supports embedded programs. PowerCOBOL takes advantage of this by creating embedded programs for each event procedure and/or form procedure created by a developer.
The most recent enhancement to the COBOL language is object- oriented extensions.
PowerCOBOL can create ActiveX controls (created as .DLL files) and register them with the Windows operating system.
The following figure shows the overall architecture of a PowerCOBOL application.
Figure 9.5 The overall architecture of a PowerCOBOL application
In reviewing Figure 9.5 above, the following facts should be considered:
A PowerCOBOL application may consist of one or more executable application modules. The main application module may be either an .EXE or a .DLL file. All other application modules should be .DLL files. Each of these executables may contain one or more COBOL programs.
Each form that is defined in a PowerCOBOL application will cause a separate COBOL program module to be created. A PowerCOBOL executable application module may contain one or more form modules.
Each form module will have one general area for its file and data declarations, along with constants and other COBOL specific declarations at the form level.
Each form module will contain an event loop in its PROCEDURE DIVISION. Additionally, any number of user specified procedure statements may be added to the form's PROCEDURE DIVISION. The event loop will exist as a COBOL EVALUATE statement. The PowerCOBOL run-time system will manage Windows events and pass them into the appropriate form module. The form module in turn evaluates each event passed into it and branches to the appropriate event procedure. This means that control comes into the form module from external events through the form's PROCEDURE DIVISION.
Each form's PROCEDURE DIVISION may contain any number of user-specified procedures or event procedures. All of these procedures will physically exist as embedded COBOL programs. The IS COMMON clause is automatically added to each Procedure's PROGRAM-ID clause to allow it to be accessed from anywhere within the form module.
Each form may specify one or more data items as global, by using the IS GLOBAL clause in the DATA DECLARATION, thus allowing these items to be accessed and shared by all of the user or event procedures defined within that specific form.
Each form may specify one or more file definitions as global by using the IS GLOBAL clause on the FD statement in the form's DATA DIVISION File section.
Form file definitions and data items may be shared across forms in the same executable application module by declaring them external by using the IS EXTERNAL clause. Any file definition or data item that you wish to share across forms must be identically declared in each form's FILE and/or WORKING-STORAGE sections.
Form file definitions and data items may be shared across separate executable application modules by declaring them using the IS EXTERNAL clause as well. Identical file and/or data item definitions must exist in both application modules including the IS EXTERNAL clause.
Individual user and event procedures contained within a form module (which themselves exist as embedded COBOL programs), may contain file definitions and data item definitions. Attempting to use the IS GLOBAL clause will not, however, allow these items to be shared outside of that specific user or event procedure.
User and event procedures are static by default. This means that data items are not automatically re-initialized upon re-entry into one of the procedures. When a user or event procedure is exited, it is not canceled, thereby preserving the current state of the data when it is re-entered. If you wish to ensure that one of more data items are initialized each and every time a specific user or event procedure in entered, use the COBOL INITIALIZE verb for each data item required.
A form module may invoke another form module within the same executable application module or even within a separate executable application module. In both cases the OPENFORM or CALLFORM method is called.
Note that an application .EXE module may only share data with a .DLL module. An .EXE cannot call another .EXE and share data using external data declarations.
Note that it is potentially dangerous to add raw procedural code to a form's PROCEDURE DIVISION unless you select New under the Edit PROCEDURE DIVISION pop-up menu. Using the New option forces any code you enter to be encapsulated into an embedded COBOL program complete with a unique Program-ID (which will become the user procedure name). This is illustrated in figure 9.5 above as a User Procedure. One potential use of the form's Procedure option is to specify a #INCLUDE statement to copy in some number of embedded programs which may exist outside of the application. Make sure that each of these programs contained in the #INCLUDE file contains a unique Program-ID and an END PROGRAM statement at the end of each.
