All Entries have the following attributes:
Name, this attribute sets the name of the Entry. The Model Developer uses this name in the Model Document. The name of the Entry should start with an uppercase character and can be followed by lowercase characters, uppercase characters, digits or underscores '_'.
Model Document statement, this attribute determines whether the Entry is single of plural. It can have values WITH or FORALL. The value is similar to the keyword that the Model Developer uses in the Model Document.
Data Retrieval, the Data Retrieval attribute determines how the data should be retrieved. Depending on the DID Module connection type this can be the name or full path of a program, a query, a special value or something else. The Data Retrieval string that you enter here is stored in the DID. The content of the string is only verified during the execution of a Model. You should be very careful with what you enter here.
Key Retrieval, the Key Retrieval attribute determines how the data should be retrieved for the Key Selection screen. Depending on the DID Module connection type this can be the name or full path of a program, a query, a special value or something else. The Data Retrieval string that you enter here is stored in the DID. The content of the string is only verified during the execution of a Model. You should be very careful with what you enter here. Defining Key Retrieval only makes sense for Main Entries. Other Entries will never use Key Retrieval.
Codepage, the codepage attribute sets the codepage for the Entry. If you do not define the codepage, ITP will use the codepage defined in the DID Module, if any. The codepage attribute is used to translate the contents of Fields and parameters. During Model execution, ITP determines the codepage of the system on which it runs. Parameters that are passed to the Data Retrieval or Key Retrieval are translated from the system codepage to the codepage defined in the Entry. Fields that are yielded by the Data Retrieval or Key Retrieval are translated from the codepage defined in the Entry to the codepage used by the system.
ITP uses sensible defaults for the codepage value. You should only set the codepage attribute if you experience problems.
Export, this optional attribute defines whether the Entry should be exported from this DID Module, YES or NO. You can import exported Entries into other DID Modules. An imported Entry can be used as a Subentry in other Entries. When the attribute is missing, it is set to NO.
List of Formal Parameters, you can optionally define formal parameters for an Entry. The formal parameters are used in Data Retrieval and Key Retrieval. In most instances, the formal parameters are a set of keys that determine which record or row should be retrieved from the database. They can however be used for other purposes. The Data Retrieval and Key Retrieval determine what they are used for. The individual parameters are defined similar as Fields. Field attributes that do not make sense when they are used in a parameter definition, such as SCREEN_FIELD or OFFSET are silently ignored.
List of Fields, each Entry contains at least one Field. You have to make sure that the Data Retrieval delivers exactly the Fields that you define, with the correct data type and in the exact same order that you define. The result that ITP receives from the Data Retrieval is handled as one big Field. ITP only verifies the total length of the Fields defined in the Entry. ITP then tries to split the result according to the Field definition of the Entry. When the type, length or order of the Fields in the Entry does not match the Fields that are retrieved, you might get strange results and/or error-messages during Model Execution. There are some situations in which you can exploit this behavior and merge or split Fields that are retrieved.
List of Subentries, you can optionally define a list of Entries that can be used as Subentry to this Entry.
Database file, some connection types make use of the database file attribute. When the connection type does not use this attribute, it is silently ignored.
Database record id, some connection types make use of the database record id attribute. When the connection type does not use this attribute, it is silently ignored.
Entries in a Local Connection DID Module have the following attributes:
Calling Convention, in Local Connection DID Modules you have to specify a calling convention for an Entry. For Local connection the calling convention can have values DLL16, DLL32 and PROGRAM. The calling convention determines how the Data Retrieval and Key Retrieval is started.
Entries in an XML WebServices Connection DID Module have the following attributes:
Calling Convention, in XML WebServices Connection you have to specify a calling convention for an Entry. For XML WebServices Connection the calling convention can have values HTTPREQUEST and SUBELEMENT. The calling convention determines how the Data Retrieval and Key Retrieval are started.
Entries in an XML MQSeries Connection DID Module have the following attributes:
Calling Convention, in XML MQSeries Connection you have to specify a calling convention for an Entry. For XML MQSeries Connection the calling convention can have values MQREQUEST and SUBELEMENT. The calling convention determines how the Data Retrieval and Key Retrieval are started.
Entries in an AS/400 Connection DID Module have the following attributes:
Record length, in AS/400 DID Modules you can specify a record length for an Entry. When you specify a record length, you also have to specify an offset for each Field in the Entry. ITP verifies during DID creation that all Fields fall within the specified length. ITP does not generate a warning or error when you do not specify the offset attribute. For Fields that have no offset attribute, an offset 0 is assumed.
When you use the record length attribute in other connection type DID Modules ITP generates an error message during DID creation.
Grammar
entry-definition ::=
DEFINE_ENTRY
NAME entry-name
entry-attribute-sequence
[ entry-parameters ]
entry-fields
[ entry-subentries ]
END_DEFINE_ENTRY
entry-attribute-sequence ::=
model-document-statement
data-retrieval
[ key-retrieval ]
[ local-connection-entry-attributes ]
[ as400-connection-entry-attributes ]
[ database-file ]
[ database-record-id ]
[ entry-codepage ]
[ entry-export ]
model-document-statement ::=
MODEL_DOCUMENT_STATEMENT single-or-plural
single-or-plural ::=
WITH
| FORALL
data-retrieval::=
DATA_RETRIEVAL retrieval-name
key-retrieval ::=
KEY_RETRIEVAL retrieval-name
local-connection-entry-attributes ::=
entry-calling-convention
entry-calling-convention ::=
CALLING_CONVENTION calling-convention
as400-connection-entry-attributes ::=
entry-record-length
entry-record-length ::=
RECORD_LENGTH natural-number
database-file ::=
DATABASE_FILE file-name
database-record-id ::=
DATABASE_RECORD_ID file-name
entry-codepage ::=
CODEPAGE codepage
entry-export ::=
EXPORT_ENTRY yes-or-no
yes-or-no ::=
YES
| NO
entry-parameters ::=
DEFINE_PARAMETERS formal-parameter-sequence END_DEFINE_PARAMETERS
formal-parameter-sequence ::=
field-sequence
entry-fields ::=
DEFINE_FIELDS field-sequence END_DEFINE_FIELDS
Example
DEFINE_ENTRY
NAME Customer
MODEL_DOCUMENT_STATEMENT WITH
DATA_RETRIEVAL (* ... *)
KEY_RETRIEVAL (* ... *)
DEFINE_PARAMETERS
(* ...
Here go the parameter definitions
... *)
END_DEFINE_PARAMETERS
DEFINE_FIELDS
(* ...
Here go the Field definitions
... *)
END_DEFINE_FIELDS
END_DEFINE_ENTRY