Previous Topic: CA-Datamacs/II CA-DATACOM/DB Interface Options

Next Topic: UNLOAD

CREATE

The CREATE option of the CA-Datamacs/II CA-DATACOM/DB interface is designed to populate a DATACOM/DB table(s) using data generated solely by the CA-Datamacs/II field generators. The CREATE option may be used to initially populate an empty database table(s), or add additional records anywhere within an existing table. Logical capabilities exist to support adding to multiple tables. The same logical capabilities can be used to add records to a new table by using all or some key values retrieved from an existing table.

The following database relationships will be supported:

One-To-One Relationships

One-To-Many Relationships

Many-to-One Relationships

Many-To-Many Relationships

Repeating Group

To support the above relationships, the ability to process more than one table in the same run has been provided.

Various control information must be supplied identifying the database and the records to be added. Every effort has been made to retrieve as much information as possible from Datadictionary.

CA-Datamacs/II is designed to only use a record description retrieved from Datadictionary in the IBM COBOL language syntax. The Datadictionary Service Facility is utilized to retrieve the data field information and build the copybook.

When record descriptions are copied from Datadictionary, provisions must be made to merge any field generators with the correct field based on a line sequence number in columns 73 to 80. A line number will be calculated by CA-Datamacs/II and attached to each field as it is copied from the dictionary.

The following example illustrates using CA-Datamacs/II to initially populate a single CA-DATACOM/DB database.

        *DM  TBLSZE IS 10.
         IDENTIFICATION DIVISION.
         PROGRAM-ID. Datamacs.
         AUTHOR.  CA-DATACOM/DB INTERFACE.
         REMARKS. INITIAL CREATE DESIGN
         ENVIRONMENT DIVISION.
         INPUT-OUTPUT SECTION.
         FILE-CONTROL.
        *DM  GENERATE        500 RECORDS.
        *DM  PRINT           500 RECORDS.
        *DM  DATACOM CREATE  DATABASE NAME IS X------------------------X
        *DM       CHECKPOINT EVERY number-of-recs RECORDS
        *DM       BACKOUT.
        *DM  START.
        *DM   PERFORM table-name 50 TIMES.
        *DM   GO TO FINISH.
        *DM  table-name.
        *DM    ADDIT table-name.
        *
         DATA DIVISION.
         WORKING-STORAGE SECTION.
        *
        *DM  COPY TABLE NAME IS x-----------------------------x
        *DM      ELEMENT element-list  SUPPRESS.
        *DM
        *DM  CONSTANT  
        *DM    'W1' (1)  'W2' (1)  'W3' (1) 'W4' (1)                      00300062
        *DM    REPEAT EVERY 001 TIMES.                                    00300063
        *DM  SEQUENCE 'WXW RECORD AA'                                     00300071
        *DM  INCR BY  '0000000000001'                     EVERY 001 TIMES.00300072
        *DM  END-COPY.
        *
        *
         PROCEDURE DIVISION.

CREATE Programming Notes:

The *DM DATACOM statement is the keyword which activates the CA-Datamacs/II interface. Facilities are available to checkpoint records added and back them out at end-of-job. Because the VERSION keyword was not coded, PROD is assumed.

The CREATE option tells CA-Datamacs/II that the database table(s) identified in the TABLE statement(s) will be populated by data created with the field generators, if an ADDIT command is coded in the function logic.

Various processing options are available:

CHECKPOINT tells CA-Datamacs/II to free the CA-DATACOM/DB resources used so far. This entry is based on the number of records processed, regardless of the table accessed, and is only available if the MASTERLIST and DBURSTR entries allowing its use are coded YES.

BACKOUT tells CA-Datamacs/II, at end-of-job, to undo all database changes or undo them from the last checkpoint. This entry is optional.

The START statement tells CA-Datamacs/II where the logic statements begin.

The populating process is directed by coding a series of PERFORM statements. The PERFORM statement's functionality is similar to the COBOL PERFORM statement. The collection of PERFORMS, and database access commands, and other logic statements, is collectively known as 'function logic'.

The PERFORM statement points to a paragraph name which corresponds to a table name and contains an ADDIT statement directing CA-Datamacs/II to add one record to the specified table. There can be more than one ADDIT statement per paragraph. Field generators will update the record contents prior to adding the record. No explicit GO TOs are allowed inside a paragraph, unless there is no intention of returning to the paragraph. The paragraph name can be up to 32 characters long. In this example the statements contained in the paragraph specified in the PERFORM are executed 50 times, then control passes to the next statement.

The number of records to be added can be controlled two ways:

If a PRINT statement is coded, a listing is provided showing the contents of each record added. With optional parameters on the print statement, this listing can be suppressed or printed in various ways.

The job will end normally one of two ways:

A GO TO FINISH statement branches to an internal process which handles end-of-job processing and printing of runtime statistics. Basic statistics will be provided to document how many records were added to each table specified in the run.

Like COBOL, each CA-Datamacs/II statement must end with a period.

The TABLE statement's purpose is to provide the information necessary to build the record (element) descriptions from Datadictionary and identify the tables involved with the CREATE. Assuming the region is large enough, up to 240 tables may be used. Two keywords on the TABLE statement allow an ELEMENT or DATAVIEW to be used to determine which fields will be included in the record description. If neither is specified then all the fields defined to the table are copied into CA-Datamacs/II.

After each TABLE statement, any field generators needed would be entered, along with a line sequence number to merge the field generator with the correct field as it is copied from Datadictionary. CA-Datamacs/II will place the table DATACOM-ID in the leftmost 3 positions of the sequence number and calculate a sequential number, beginning with 00060, incremented by the value in INCREMENT-SEQ, and place it in the rightmost 5 positions of the sequence number.

If users are running in batch mode, they can determine the field sequence number by doing a SYNTAX run and removing the SUPPRESS option of the COPY TABLE statement. CA-Datamacs/II will calculate the sequence number and print it out. When the user is in the ISPF front-end environment, the requirement of a line sequence number is transparent to them. They just specify the type of field generator they wish attached to a selected field and the front-end does the rest.

The following example illustrates using CA-Datamacs/II to initially populate more than one table within a CA-DATACOM/DB database.

        *DM  TBLSZE IS 10.
         IDENTIFICATION DIVISION.
         PROGRAM-ID. Datamacs.
         AUTHOR.  CA-DATACOM/DB INTERFACE.
         REMARKS. INITIAL CREATE DESIGN
         ENVIRONMENT DIVISION.
         INPUT-OUTPUT SECTION.
         FILE-CONTROL.
        *DM  GENERATE        500 RECORDS.
        *DM  PRINT           500 RECORDS.
        *DM  DATACOM CREATE  DATABASE NAME IS x--------------------------x
        *DM       VERSION T001
        *DM       CHECKPOINT EVERY number-of-recs RECORDS
        *DM       BACKOUT.
        *DM  START.
        *DM   PERFORM table-name1 50 TIMES.
        *DM   GO TO FINISH.
        *DM  table-name1.
        *DM    ADDIT table-name1
        *DM    ON-DB-ERROR '10' GO TO FINISH.
        *DM    PERFORM table-name2 3 TIMES.
        *DM  table-name2.
        *DM    ADDIT table-name2.
        *
         DATA DIVISION.
         WORKING-STORAGE SECTION.
        *
        *DM  COPY TABLE NAME IS x----- table-name1 -----------x
        *DM      ELEMENT element-name1,element-name2,element-name3
        *DM      SUPPRESS.
        *
        *DM  SEQUENCE 00001 BY 00010 EVERY 1 TIMES.                       00300061
        *DM  SEQUENCE 'RECORD     WA'                                     00300071
        *DM  INCR BY  '0000000000001'                     EVERY 001 TIMES.00300072
        *DM  END-COPY.
        *
        *DM  COPY TABLE NAME IS x------ table-name2 ----------x
        *DM      DATAVIEW NAME IS dataview-name
        *DM      SUPPRESS.
        *
        *DM  SEQUENCE 00001 BY 00010 EVERY 1 TIMES.                       00400061
        *DM  SEQUENCE 'RECORD     RA'                                     00400071
        *DM  INCR BY  '0000000000001' EVERY 001 TIMES.                    00400072
        *DM  END-COPY.
        *
        *
         PROCEDURE DIVISION.

CREATE programming notes for multiple table adds:

In this example a one-to-many table relationship is being created.

All the notes from the single table apply here, but now we have an additional table we are loading. Therefore, one additional COPY TABLE statement is coded and one more PERFORM/paragraph with an ADDIT command is needed to populate the table.

For every record added to the first table, 3 records are being added to the second table.

Normally, CA-Datamacs/II bypasses duplicate records with an error message and continues processing. You can stop processing by testing for the appropriate CA-DATACOM/DB error return code (ON-DB-ERROR) and end the job by coding a GO TO FINISH.

Even though '500 RECORDS' was coded on the GENERATE statement, only 200 records will be generated. This is due to the PERFORM logic which was coded. The mainline PERFORM causes the paragraph 'table-name1' to be executed 50 times. Another PERFORM, inside 'table-name1' causes the paragraph 'table-name2' to be executed 3 times for each execution of 'table-name1'. Since each paragraph contains an ADDIT statement, 50 records will be written to table-name1 and 150 records will be written to table-name2, for a grand total of 200 records.

In this example, we see the record descriptions have been built using elements defined individually for table-name1 and with a DATAVIEW for table-name2. However, the version used between the two is completely different. When specifying individual elements, the VERSION on the DATACOM statement controls which version of the elements would be selected, but when a DATAVIEW is specified, its own VERSION must be entered. In this case, the DATAVIEW defaulted to PROD, and whichever elements were related to this DATAVIEW were selected.