Process Module (PM) objects are used to extend the capabilities of ACCENT R commands. The Structured Programming Language (SPL) which resides in PM objects is a complete replacement for 3rd Generation Languages such as Fortran, COBOL, Basic, and Pascal. They execute additional logic as records are being processed by commands. A PM consists of SPL procedural statements grouped into sections. Each section models a specific program need. This makes it easy to design the solution for a particular application. It also reduces the amount of programming code that is needed.
This concept of breaking the solution to a problem into a logical section will help you organize the code and come to the solution much quicker than using the current methods in 3 GL’s. Once you grasp the concept you will find you are much more productive using this technique.
In addition to the statements described in this section, Screen Management Facility (SMF) statements are available for developing full-screen window-based applications. Also, a full complement of Structured Query Language (SQL) standard data manipulation statements are described in the SQLgateway manuals. Open Structured Query Language (OSQL) commands are described in Chapter 8.
Every program contains three types of logic: 1) beginning logic which is executed once; 2) processing logic which is applied to each record as it is read; 3) final logic which executes after all records are processed. ACCENT R models these situations with PM sections. In the simplest situation, the sections are INITIAL, DETAIL, and FINAL. When ACCENT R runs the PM, it executes statements in the INITIAL section before reading any records. It then reads one record at a time and executes the DETAIL section for each record. After all records have been processed, it executes the statements of the FINAL section.
The DETAIL section is one of several record processing sections that can be used to process different subsets of records.
When a PM processes transaction records against a master Data Set (DS), ACCENT R provides separate sections. One defines what logic is to be executed: when a transaction matches a master (MATCHED section); when the transaction does not match any master (UNMATCHED:T section); when a master does not match any transaction (UNMATCHED:M section). ACCENT R takes care of reading master records, reading transaction records, matching the records on specified fields, executing the appropriate sections, and handling end of file situations. This modeling provided by PM sections relieves the programmer of a great deal of logic that is normally required in a 3rd Generation Language program.
The different sections provided by ACCENT R not only help create solutions to applications quickly, but also provide an organizational framework for the logic. It makes the program more understandable to others who may be required to maintain it. Writing the solution to an application in an ACCENT R PM takes substantially fewer lines of code than in a 3rd Generation programming language and executes as quickly.
A PM is usually designed to operate with one of the Data Manipulation commands, but it can also be designed to operate as a stand-alone program in which all record processing is done specifically with statements in the PM.
A Process Module (PM) is created with the DEFINE PM command. It is saved in the Data Base Library (DBL) that is declared when the PM is created. The PM can be changed at any time with the MODIFY PM command.
Two versions of the PM are stored in the DBL:
The source version, containing the actual text of the statements entered when the PM was defined (or last modified).
The compiled version, which is produced when a SAVE subcommand is given.
The HOLD subcommand causes the source version to be stored in the DBL even if the PM is incomplete or contains logic errors. However, the PM will not execute until it has been compiled with the SAVE subcommand.
To assist you in debugging your PM code, ACCENT R offers several tools. First, you can TRACE execution by using the command ENABLE PM TRACE. This instructs ACCENT R to print the line number of each statement before it is executed. Second, you can enter shadow statements in your PM which are statements that are proceeded with an asterisk "*". These statements are executed only if you use the DEBUG option of the SAVE subcommand. Third is the PM debugger which allows you to set break points, watch points, step execution a line at a time, display variables and set variables. A complete description of all PM debugging features is provided in the chapter on PM DEBUGGING TOOLS.
The sections that make up Process Module (PM) objects are divided into three groups for documentation. The general sections establish the environment, declare Data Sets (DS) and System Files (SF), define subroutines, and initialize and finalize processing for use with all database servers. The general sections are:
|
defines Data Sets, Indexes, Reports and Global Storage |
|
|
defines local variables |
|
|
defines subroutines |
|
|
statements executed before any records are read |
|
|
statements executed after all records are processed |
|
|
statements executed only if certain conditions happen |
The report specification sections create title pages, headings, subheadings, footings, and totals for reports. They are driven by page breaks or by control breaks within the records. The report specification sections are:
Record processing sections are provided for different processing situations such as matched records, and unqualified records. Each record processed invokes the appropriate section. "Simple" refers to the use of one DS. "Join" refers to the use of a Master Data Set and Transaction Data Set. The record processing sections are:
|
Simple |
Join |
|
|
BEFORE DETAIL AFTER UNQUALIFIED |
MATCHED BEFORE:M UNMATCHED:M AFTER:M UNQUALIFED:M |
BEFORE:T UNMATCHED:T AFTER:T UNQUALIFIED:T |
The suffix :M after the section name define this as a section where only master records are processed. The suffix :T after the section name defines this as a section where only transaction records are processed. The use of Master and Transaction Data Sets are described later in this chapter.
A PM called by one of the following commands must have a CONTROL section and one record processing section. All other sections are optional.
|
ALTER CHANGE DELETE ENTER EXTRACT LOAD |
MERGE PURGE REPORT SELECT SORT UPDATE |
The order of the sections in a PM is governed by the following conventions:
Any of the following sections that are used must appear before any other sections, and must be in the order shown.
|
CONTROL DECLARE PROCESS INITIAL |
TITLES HEADINGS SUBHEADINGS FOOTINGS |
Any of the following sections that are used can be in any order, as long as they follow the sections listed above.
The TOTALS section, if used, must follow all sections listed above.
The FINAL section, if used, must follow all sections listed above.
The EXCEPTIONS section, if used, must be last in the PM.
Within the PM, each section is introduced by a section name statement in the form:
section_name [SECTION]
Section_name can be any of the section names listed above. Section name statements, like all PM statements, must have line numbers. Since they are non-executable statements, each section name statement must be on a line by itself.