CA IDMS Reference 19.0

PDF
English

Stand-Alone Tables

Contents
idmscu
Contents
Overview
Stand-alone tables can be associated with any record element at map-definition time. Stand-alone tables are typically used to list values when:
  • The values are subject to change
  • The values can be used by several record elements
A stand-alone table is defined and generated by the TABLE statement of DDDL. Clauses in the TABLE statement determine the search technique, arrangement of values, and the type of values for a table as follows.
Search Technique
The
search technique used for the table
 is determined by the SEARCH IS LINEAR/BINARY clause, as follows:
Clause
Description
SEARCH IS LINEAR
Specifies that a linear search algorithm is used for the table. The following considerations apply to linear searches:
A linear search progresses sequentially through the table; the first value in the table is examined first, the second value second, and so forth, until either the target value is found or the end of the table is reached.
The arrangement of values in the table, as established by the SORTED/UNSORTED parameter discussed later in this section, determines the order of values in the table and, thus, the order of the search.
SEARCH IS BINARY
Specifies that the table is searched with a binary search algorithm. The following considerations apply to binary searches:
A binary search compares the target value against the table's midpoint value and determines which half of the table contains the target value. The selected portion then is halved in the same way; this process is repeated until either the target value is found or the end of the table is reached.
When SEARCH IS BINARY is specified, values in the table are kept in sorted order, regardless of the SORTED/UNSORTED specification for the table. The SORTED/UNSORTED parameter is discussed later in this section.
Binary searching cannot be performed on an edit table that contains ranges, since binary searching requires all values in the table are the same length.
A binary search in a code table can be specified for either an encoded value or a decoded value (as specified in the ON ENCODE/DECODE parameter of the SEARCH IS BINARY clause), but not for both. If binary searching is performed for encode values, decode values are searched linearly; if binary searching is performed for decode values, encode values are searched linearly.
Arrangement of Values in the Table
The arrangement of values in the table is determined by the TABLE IS SORTED/UNSORTED clause, as follows:
Clause
Description
TABLE IS SORTED
Specifies that values in the table are sorted in ascending order according to the EBCDIC collating sequence. The following considerations apply:
An
edit table
 of ranges is sorted according to the lowest value in the range
A
code table
is sorted according to its encoded values
TABLE IS UNSORTED
Specifies that values in the table are not sorted; the table is stored in the order of its appearance in the defining TABLE statement.
Type of Values in the Table
The type of values in the table is specified by the TABLE DATA IS NUMERIC/ALPHANUMERIC clause. This specification affects the results of a table search. For example, the validity of the value 20b (where the b character denotes the blank character) depends on the type of values specified for the table:
  • The entry is valid if the edit table is an ALPHANUMERIC table of valid values (20b falls alphabetically in the range 100 through 200)
  • The entry is invalid if the edit table is a NUMERIC table of valid values (20 falls numerically outside the range 100 through 200)
Where are Load Modules Stored?
Load modules for stand-alone tables are stored in the DDLDCLOD area of the data dictionary.
For more information about DDDL syntax and syntax rules, see the
CA IDMS IDD DDDL Reference section
.
Linked vs Unlinked
The map developer specifies whether a stand-alone table is linked or unlinked when enabling the table:
  • A
    linked table
     is included in the map load module with which it is associated. Map load modules that use a linked table must be regenerated when changes are made to the table.
  • An
    unlinked table
     is loaded at runtime by the map load module with which it is associated. It is unnecessary to regenerate map load modules that use an unlinked table when the table is changed.
It is often preferable to enable stand-alone tables as unlinked tables since stand-alone tables are typically used as general-purpose tables for several record elements.
Compiling, Generating, Loading of maps
Linked Stand-alone Tables
The compilation and runtime loading of a map that uses linked stand-alone tables are illustrated in the following drawing.
A linked stand-alone table becomes part of a map load module that uses it; the map load module must be recompiled if a linked table is changed.
Overview (4)
Unlinked Stand-alone Tables
An unlinked stand-alone table is used by a map, but is not part of the map load module; changes to an unlinked table do not affect map load modules that use the table.
Overview (5)
Examples
The following examples demonstrate the use of DDDL statements to define and generate stand-alone tables.
Example 1
The following sample TABLE statement adds a stand-alone edit table of valid values to the dictionary; the search technique is linear and the table is unsorted:

ADD TABLE DEPTEDIT
TYPE IS EDIT VALID
SEARCH IS LINEAR
TABLE IS UNSORTED
VALUES ARE ( SHIPPING PERSONNEL ACCOUNTING
     MARKETING 'OFFICE SERVICES' )
GENERATE
          .
Example 2
The following sample TABLE statement adds a stand-alone edit table of valid values to the dictionary; the search technique is binary:

ADD TABLE NAMEEDIT
TYPE IS EDIT VALID
SEARCH IS BINARY
VALUES ARE
 ( ADAMS
   AGASSIZ
   BACH
     .
     .
     .

   XERXES
   YEATS
   ZENO )
GENERATE
 .
Example 3
The following sample TABLE statement adds a stand-alone code table to the dictionary; the search technique is linear and the table is unsorted:

ADD TABLE DEPTCODE
TYPE IS CODE
SEARCH IS LINEAR
TABLE IS UNSORTED
VALUES ARE
( 01          SHIPPING
  02          PERSONNEL
  03          ACCOUNTING
  04          MARKETING
  05         'OFFICE SERVICES'
  00          NOT FOUND
  NOT FOUND   MISSING  )
GENERATE
 .
Use of the NOT FOUND Condition
The following examples illustrate the use of the NOT FOUND condition in the value list of a code table.
Example 4a
When NOT FOUND (a condition to be acted upon) is used in the encode column of a code table, the following occurs:

VALUES ARE
( 100          MATHEMATICS
  200          ENGLISH
  300          SCIENCE
  NOT FOUND    INVALID-DEPT-NO  ) 
  • On mapout, NOT FOUND is used as a catchall. At mapout, any value other than 100, 200, or 300 will match the NOT FOUND condition in the table. The corresponding value, INVALID-DEPT-NO will be moved to the map field.
  • On mapin, NOT FOUND produces automatic editing errors under the following conditions:
    • If the value entered does not match a decoded value and if there is no catchall value.
    • If the value entered in the map field is INVALID-DEPT-NO the corresponding value is NOT FOUND instead of real value. As a result, the table is re-searched but no match is found.
Example 4b
When NOT FOUND is used in the decode column of the Code Table's value list, the following processing occurs:

VALUES ARE
( 100          MATHEMATICS
  200          ENGLISH
  300          SCIENCE
  000          NOT FOUND   )
  • NOT FOUND is used as a catchall on map-ins. Any value entered in the map field, other than Mathematics, English, or Science will match the NOT FOUND condition and its corresponding value, 000, will be moved to the buffer.
  • On mapout, NOT FOUND causes a program to abort as described:
    • If a value in the buffer does not match an encoded value or a catchall, the user program will abort with the message, MAPPING DATA ERROR
    • If 000 is the value in the buffer, its corresponding value is NOT FOUND. The encode values are then re-searched looking for a NOT FOUND condition. When there is no match, the application aborts.
Example 4c
When NOT FOUND is used in both the encode and decode column of a code table's value list as shown, the following processing occurs:

VALUES ARE
( 100          MATHEMATICS
  200          ENGLISH
  300          SCIENCE
  000          NOT FOUND
  NOT FOUND    INVALID-DEPT-NO  )
  • On mapout and mapin, the NOT FOUND condition is used as a catchall:
    • Any value other than ENGLISH, MATHEMATICS, or SCIENCE, that is entered in the map field will match the NOT FOUND condition in the decoded column and its corresponding value, 000, will be moved to the buffer on mapin.
    • On mapin, if an invalid department number is entered in the map field, a match is found in the decode column and its corresponding value, NOT FOUND, is moved to the buffer. The decode column is then re-searched looking for NOT FOUND. When it is found, its corresponding value, 000, is moved to the map field.
    • Any value other than 100, 200, 300, or 000 will match the NOT FOUND condition in the encode column, and its corresponding value, INVALID-DEPT-NO, is moved to the buffer.
    • On mapout, if 000 is in the buffer, there is a match in the encode column and its corresponding value is NOT FOUND. The encode column is then re-searched looking for NOT FOUND. A match is found and its corresponding value, INVALID-DEPT-NO, is moved to the map field.