This section contains the following topics:
Compiler Interface Parameter List
Any program can call the DDDL compiler (IDMSDDDC) as a subroutine to extract information from or update information in the dictionary. The program or dialog passes to IDMSDDDC an input file that contains the DDDL statements to be used to obtain the desired information. The DDDL compiler places the extracted data in an output file, which can be examined and processed by the program or dialog.
The DDDL compiler uses these files:
Each of these files consists of 80-byte records. Normally, the compiler controls these files, directing the input and print files to the terminal and discarding the punch file. However, when a program or dialog calls IDMSDDDC as a subroutine, the calling program specifies that these three files can be directed to a work-area file, a scratch area, a queue, another program, or a null file. Advantages and disadvantages associated with each of these storage mechanisms are as shown in the following table.
|
Storage type |
Advantages/disadvantages |
|
Work-area file |
Offers the fastest access but is limited in size; this mechanism is the best choice for small files. |
|
Scratch area |
Can accommodate a large volume of data; however, scratch areas are volatile and may require the calling program to perform I/Os. |
|
Queue |
Can accommodate a large volume of data; however, the calling program must perform I/Os and initiate run units to access queues. |
|
User program exit |
Offers the most advantages. The user has maximum control over the file's records, selecting certain records for special processing. |
|
Null file |
Suppresses the output from IDMSDDDC. If the program tries to read the null file, an end-of-file condition is returned immediately. |
It may be advantageous to combine two mechanisms. For example, direct the file to a user program exit that directs a work area's overflow to a scratch area. The work area is described under Work-area File.
The input file can contain any valid DDDL statements. All standard compiler security applies to issuing these statements.
To ensure proper access to the compiler, it is recommended that the first two commands in the input file be SIGNON and SET OPTIONS.
The dictionary named or defaulted to in the SIGNON command must match the dictionary being used by the calling program.
You may also wish to specify SET OPTIONS FORMAT IS FIXED because the resulting columnar format is easier for the calling program to parse. Note, however, that the columnar format associated with each entity-occurrence definition is subject to change from release to release. Therefore, the user program should be coded in such a way as to easily accommodate such changes.
You should ensure that null values are not passed to the DDDL compiler as part of an entity name; if nulls are present, the compiler will not be able to locate the object entity.
When a user program calls the compiler interface, that program automatically starts a compiler session. Therefore, the last command passed to the compiler by the program should be a SIGNOFF command. If the SIGNOFF command is not present in the input file, the compiler interface suspends the compiler session. If the calling program terminates, the compiler session remains suspended. If the user then signs on to the compiler from the same logical terminal, the suspended session is reactivated and any session options established by the calling program remain in effect; however, the work file has been cleared.
To call the DDDL compiler, the user program issues a LINK request, naming the module IDMSDDDC and passing seven parameters: a compiler input/output (CIO) block, one compiler input/output file (CIOF) block for each of the three IDD files (input, print, and punch), followed by a user parameter for each of the three files (input, print, and punch).
|
Copyright © 2014 CA.
All rights reserved.
|
|