You can define or modify a presence, class, and value check
for each Data Element that is called in a Segment or Table by opening
a definition wizard.
Figure 1. Definition of controls
for a Data Element called in a Segment or Table
The presence check and class control are to be defined
in a wizard that opens with the
More button
in the following definition sections of the
-CE Lines tab
in the Segment or Table editor:
- Segment call for Segments only
- Data Element call
- Undefined Data Element definition
- Group definition
- Filler definition for Segments only
For the fillers called in a Segment, you can define or modify
operators only.
This wizard is used by transaction files. A
transaction file is made of records that update a permanent file.
Transaction files are validated and update permanent files or databases.
The type of update (creation, modification, deletion, or others) is
called the action code. Validations and updates are automatically
associated with each type of update. In the common part of the file,
an action code Data Element, represents the action code. You must
associate six values with this Data Element, one for each type of
update. Each value represents the input that the user indicates in
the application to carry out the appropriate update. If you do not
specify any action code Data Element, all updates are considered as
modifications.
Presence check
In this section of the definition
wizard, you must specify whether the presence of the Data Element
is required, optional, or forbidden when the transaction file updates
the permanent file or database. The fields Type 4, Type
5 and Type 6 are not used by Pactables.
- Creation
- You select here whether the Data Element presence is required
when the transaction file creates a record in the permanent
file or database.
- Modification
- You specify here whether the Data Element presence is required
when the transaction file modifies a record in the permanent
file or database.
- Deletion
- You specify here whether the Data Element presence is required
when the transaction file deletes a record in the permanent
file or database.
- Type 4
- You specify here whether the Data Element presence is required
when the transaction file updates a record in the permanent file or
database. A type-4 action is a nonstandard action that you must describe
entirely.
- Type 5
- You specify here whether the Data Element presence is required
when the transaction file updates a record in the permanent file or
database. A type-5 action is a nonstandard action that you must describe
entirely.
- Type 6
- You specify here whether the Data Element presence is required
when the transaction file updates a record in the permanent file or
database. A type-6 action is a nonstandard action that you must describe
entirely.
Table 1. Possible values for a
nonstandard action (type 6-action)Values |
Comments |
None |
No check. |
F: Optional |
Default value. |
O: Required |
Required. Generation of a level E (transaction
refused) in standard error messages. |
P: Required (C error) |
Required. Generation of a level C (Data
Element refused) in standard error messages. |
I: Forbidden |
Not authorized. For relational databases, it
indicates the presence of a column in a table. |
Class control
- Class control
- You can select a class control that is specific to the Data Element
call. This control complements the Data Element class that is indicated
in the Data Element Definition. For example,
for a pure alphabetic alphanumeric Data Element, you can specify whether
it accepts lowercase or uppercase characters.
Table 2. Values for class controlValues |
Comments |
None (recommended) |
Only the control generated automatically by
the class is requested. |
A: Alphabetic |
For an alphanumeric class, numeric and special
characters rejected. This control is the same as the control automatically
generated if the Pure alphabetic option is
selected. |
L: Lowercase alphabetic* |
For an alphanumeric class, only lowercase letters
accepted. |
U: Uppercase alphabetic* |
For an alphanumeric class, only uppercase letters
accepted. |
9: Numeric |
Numeric only. For an alphanumeric class, alphabetic
and special characters rejected. |
B: Numeric after replacing leading blanks with
zeros* |
For a numeric class, leading blanks replaced
by zeros. |
Z: Numeric after replacing all blanks with zeros |
For a numeric class, all blank replaced by zeros. |
Note: B and Z type validations
are possible for any Data Element with a display format (unpacked). The values
that are identified by * are specific to the -CE definition for a
Segment. The other values are common to the -CE definition for a Segment
or a Table.
More
You can add, remove,
or move rows in the table with the buttons. To populate a row, put
your cursor directly on the line and use the input fields or selections.
Note: If
a line is not correct, a message in a tooltip indicates the source
of the error.
- Logical operator
- The Operator field is directly related
to the Value or Working/Special
name field. You specify if the values of the Data Element,
when called in this Segment or Table, must be lower than, greater
than or equal to the value indicated in the Value field
or contained in the Working/Special name field.
By default, the authorized values are the same as the values indicated
in the -D Lines tab of the Data Element editor.
The Values operator is the default.
Table 3. Logical operatorValues |
Comments |
No value |
Must not be on the first line for a Data Element
in a record. |
E |
AND |
O |
OR |
- Negation
Table 4. NegationValues |
Comments |
N |
Negation (NOT is generated). |
No value |
No negation. |
- Control type
- This field has different usages. More than one entry might be
required to assign all the validation conditions, update conditions,
and values that apply to a Data Element. In this case, enter the values
on as many lines as needed, immediately after the line that calls
the Data Element. The possible values are presented in tables from 5 to 8.
Table 5. Definition of the type of validationTypes |
Values |
Comments |
Contents Validation |
= |
Equal to the value entered in the Values/Subfunction field. |
|
< |
Less than the value entered in the Values/Subfunction field. |
|
> |
Greater than the value entered in the Values/Subfunction field. |
|
T * |
Must be indicated in the Update/Target field
in the table. Content validations that are entered after a T
type validation are not executed. |
|
E * |
Must have one of the values defined on the
Data Element Description (-D Lines tab). |
Validation by PERFORM |
P |
Validation by PERFORM of a subfunction defined
by the user. There can be only one validation by PERFORM per Data
Element called in a Segment. The following operations are executed:
- Transfer of the Data Element into the COBOL work area named in
the Update/Target field. Naming the work area
on the appropriate line is your responsibility.
- Perform of the subfunction entered (left-aligned) in the Values/Subfunction field.
This subfunction can check and modify (as needed) the Data Element.
The result of the validation is indicated in the error indicator (DEL-ER)
that is generated automatically. This result is transferred automatically
to the error table (DE-ERR) in the location that
corresponds to the element being processed.
- Transfer of data from the work area to the initial Data Element,
by incorporating any modifications made as a result of the performed
function. This option is recommended for date validation, with possible
inversion. In this case, the date must be defined as an elementary
Data Element. In the description of a Data Element in a transaction,
a validation by perform can be executed before or after a content
validation. If it is located before, it is executed only if the Data
Element is present with no error. If it is located after, it is executed
only if there is a content error. The value for the corresponding
location in the DE-ERR table then becomes your responsibility.
|
Note: The values that are identified by * in the table are
available only in the -CE definition for a Segment.
Table 6. Definition of the type of updateValues |
Comments |
No value |
Direct update of the Data Element in the Update/Target field,
contingent upon the valid presence of the Data Element. This type
of update can also be used with a Content Validation other
than T. |
+ |
Update by addition, contingent upon the valid
presence of the Data Element. |
- |
Update by subtraction, contingent upon the valid
presence of the Data Element. |
M * |
Update by unconditional substitution (MOVE).
Updating is done regardless of the validation result. This type of
update can be used with group Data Elements. |
Note: The value that is identified by * in the table is available
only in the -CE definition for a Segment.
Table 7. Definition of an initial valueValues |
Comments |
V * |
Initial value. It generates a value using the literal entered
in the Values/Subfunction field. It is the
default value defined on the element description if the Values/Subfunction field
is not used and if the element description has a D-type line
The Record
type field on the Call of Data Structures -CD
Lines) tab must authorize the generation of VALUES clauses.
|
W * |
Same as V, but the literal
can be continued into the Update/Target field. These
two fields are then considered as one. |
Note: The values that are identified by * in the table are
available only in the -CE definition for a Segment.
Table 8. Special usagesContexts |
Values |
Comments |
DL/1 group key Data Element |
M |
To indicate a group key Data Element associated
with the code entered (after A*) in the Update/Target field. |
Pactables function |
S * |
It indicates that the Data Element belongs to
one or more subschemas. The subschemas are entered in the Values/Subfunction field. If
the Data Element belongs to a group Data Element, you must enter a
subschema number on the group Data Element line.
|
SQL relational database function |
S |
The Values/Subfunction field
is used to indicate the subschemas which a column belongs to. |
Pactables |
D * |
Date in DDMMYY format. |
Pactables |
I * |
Date in YYMMDD format. |
Pactables |
K * |
Date in DDMMCCYY format. |
Pactables |
L * |
Date in CCYYMMDD format. |
Note: The values that are identified by * in the table are
available only in the -CE definition for a Table.
- Values/Subfunction
- The value in this field depends on the value of the Control
type field:
- Numeric or alphanumeric literal, name of a manually positioned
work area, or subfunction code (left-aligned) called by perform in
a Data Element validation.
- With =, > or <,
enter the value to be compared,
- With P, enter the subfunction code to be performed.
This code must be left-aligned,
- With +, – or M,
enter the value to be added, subtracted, or moved,
- With V, enter the literal to use as the initial
value,
- With W, enter the first part of the literal (that
extends into the next field),
- With S (Pactables and SQL DBD functions), enter
the letter O in the columns that correspond
to the subschemas to which the Data Element belongs.
Example: If, on the DELCO Data
Element call line, you enter O OOO in this
field, it means that DELCO belongs to subschemas
1,3,4, and 5.
- Update/Target
- This field has several different usages:
- To identify the target of the update,
- To identify the counter field that defines a variable number of
repetitions,
- To cause the redefinition of a Data Element within a Segment,
- To identify the external name of a DL/1 search or key field,
- As a continuation of a literal.
The possible values to be entered in this field are presented
in Table 9 and Table 10.
Table 9. Update
target: first partValues |
Comments |
Data Structure code in the Program of a permanent
file. |
Code in the Program of the Data Structure to
be updated (Usage set to P in
the Call of Data Structures), or of the Table Data Structure if the Control
type field is set to T. |
Data Structure code |
The Data Structure code for the target of an
update. |
Working Data Structure code |
Working Data Structure code for the Data Element
communication area in a perform (Control type set
to P). |
** |
Associated with a repetitions number, in order to
generate a variable number of OCCURS, using
a counter contained in an element. This counter is referenced by the
Segment and Data Element that are indicated in the Update/Target field
(second and last parts). |
|
Generation of an OCCURS DEPENDING
ON clause. The transfers of the counter between the
input, working, and output areas are carried out automatically if
this counter belongs to the common part. |
R* |
To redefine a Data Element within a Segment.
The Data Element will redefine the first Data Element that precedes
it and that is generated at the same COBOL level. Example: ELEM. GR GRPFLD 2 ELEM1 ELEM2
R* <--- or NEWVAL R* <---
If R* is
entered opposite ELEM2, ELEM2 will redefine ELEM1.
If R* is
entered opposite NEWVAL, NEWVAL will redefine GRPFLD.
|
A* |
To identify the external name of a DL/1 key
or search field. The external name (8 characters) is entered in the Update/Target second
and last parts and applies to the Data Element specified on this line. |
|
SQL relational databases |
|
The relational label of a column can be identified
in this field. The value A must be left-aligned
and followed by the external name of the column. |
Table 10. Update target: second part. The second part of the Update/Target field
is 2 characters long.Values |
Comments |
Segment code |
Default value. |
Continuation of a literal. |
|
First two characters of the DL/1 external name. |
|
- You can also enter a Data Element in the Update/Target field
to specify a hidden Data Element. It is the default value. It also
works for a modification.