Use the Modify CA-IDMS Table wizard to change the selection of
records in an existing table.
You can provide the information to base the table on in one of
these ways:
- You can import schema and subschema files that were punched from the CA-IDMS
dictionary and transferred by using FTP to your workstation. These files must
be located in the CA-IDMS References folder of your
data project.
- You can tell Classic Data Architect to obtain the schema information that
is associated with all records, sets, and areas that are listed in the required
subschema directly from the CA-IDMS dictionary.
The subschema and schema reports that you select must be identical
to the reports that you used when you created the table. However, the names
of the files that contain those reports can be different from the names of
the files that you originally used.
You produce CA-IDMS schema and subschema
reports by running the CA-IDMS schema and subschema compilers and capturing
the punched output into a z/OS® data set. Sample JCL that you can use to punch
these reports is in member CACIDPCH of the SAMPLIB data set.
CA-IDMS Discovery page
Use this page to select the
data model and schema for the table in your project if you want to move the
table to a different data model and schema.
Also, use this page to specify
where the data that you want to base your table on is located.
- Database model
- Displays the path and name of the database model
in which the table is located in the project. You can select a different database
model if you want to move the table.
- Schema name
- Displays the schema in which the table is located.
You can select a different schema if you want to move the table.
- Remote CA-IDMS discovery
- Specifies that Classic Data Architect is to obtain
the schema information that is associated with all records, sets, and areas
that are listed in the given subschema directly from the CA-IDMS dictionary.
- Subschema name
- Type the identifier for the CA-IDMS subschema
to be accessed to obtain the necessary record, set, and area information.
The schema information will be obtained from the internal association between
the subschema and schema that is defined within the CA-IDMS dictionary. A
subschema can be associated with only one schema version. The subschema name
must follow CA-IDMS naming standards and must not contain leading spaces.
- Database name
- Type an identifier of 1 to 8 characters for the
CA-IDMS database that contains the data that the data server will access
at runtime.
- Access module
- Type the identifier for the access load module
to be loaded and used to connect to the CA-IDMS central version with the dictionary
that contains the specified subschema. If you do not provide an identifier,
the default IDMS load module is loaded; therefore, the central version that
is associated with the default SYSCTL DD name is accessed.
- Local
- Specifies to import a schema and subschema file
that was punched from the IDMS dictionary and transferred by using FTP to
your workstation.
- Subschema file
- Type the path and name of the file that contains
the subschema that you want to map. You can also click Browse to
search for the file on your file system. The file must have the extension sub.
If you already selected a schema, the subschema must belong to that schema.
- Schema file
- Type the path and name of the file that contains
the schema that corresponds to the subschema that you want to map. You can
also click Browse to search for the file on your file
system. The file must have the extension sch. If you
already selected a subschema, the schema must correspond to that subschema.
CA-IDMS Path Information page
Use this page to name
the table. Also, specify a path of up to ten records and sets from which you
want to choose the elements that will constitute the columns in your table.
The
first Record (Set) field is populated with all of the
records in the subschema. After you specify the initial or starting record,
the behavior of the controls on the rest of the page depends on how you chose
to use the table that you are creating.
- When using the table for queries or queries and updates
- After you specify the initial or starting record in the path by making
a selection in the first Record (Set) field, the Record
(Set) field in the next row is populated with all sets, with the
exception of the previous set, for which the previous record is either an
owner or a member.This process can continue for up to 10 rows, which is the
maximum number of rows that is supported.
- When using the table for inserts
- When you map a table for inserting CA-IDMS records that belong to multiple
automatic sets, use the No set option in addition to
the process that is described in the preceding paragraph. This option includes
in the path the owner records of the sets, ensuring that inserted records
can be connected to these sets. You should use the No set option
only for tables that you will use for inserts. Although you can still query
such tables, the result sets will be cartesian products.
See ../../com.ibm.websphere.ii.federation.classic.sqlref.doc/reference/iiyfcsqluptcmsupt.dita for more information about inserts to CA-IDMS data.
- When using the table for change capture
- After you specify the initial or starting record in the path by making
a selection in the first Record (Set) field, the Record
(Set) in the next row is populated with all records from sets
that are owned by the previous record. After you select a record and set,
the next row is automatically enabled and the next Record (Set) field
is populated with all records from sets that are owned by the previous record.
This process can continue for up to 10 rows, which is the maximum number of
rows that is supported.
If you change any record and set selection or deselect a No
Set check box, the wizard clears all of the following selections
that you made. For example, if you map a path with five record and set relationships
and then change the selection on the second row, your selections for rows
three through five are cleared, and rows four and five are disabled.
There
are cases when you need to specify a record more than once, such as when a
record has multiple roles. For example, a manager and the manager's employee
are both employees. To describe this relationship, you could use two instances
of an employee record, using the alias "Manager" to make clear the role of
that employee. In cases such as this, you must provide an alias for at least
one instance of the record to distinguish the instances from each other.
The
following example assumes the subschema is defined as shown in the following
table:
Table 1. Definition of subschema
that is used in this exampleName of set |
Owner of set |
Members of set |
COVERAGE-CLAIMS |
COVERAGE |
HOSPITAL-CLAIM NON-HOSP-CLAIM DENTAL-CLAIM |
DEPT-EMPLOYEE |
DEPARTMENT |
EMPLOYEE |
EMP-EMPOSITION |
EMPLOYEE |
EMPOSITION |
EMP-EXPERTISE |
EMPLOYEE |
EXPERTISE |
JOB-EMPOSITION |
JOB |
EMPOSITION |
MANAGES |
EMPLOYEE |
STRUCTURE |
OFFICE-EMPLOYEE |
OFFICE |
EMPLOYEE |
REPORTS-TO |
EMPLOYEE |
STRUCTURE |
SKILL-EXPERTISE |
SKILL |
EXPERTISE |
If you selected EMPLOYEE as the first record, the Record
(Set) field on the next row is populated based on how you chose
to use the table that you are creating:
- When using the table for queries or for queries and updates
- All records that are in sets that are owned by EMPLOYEE and for which
EMPLOYEE is a member appear in the field:
- DEPARTMENT (DEPT-EMPLOYEE)
- EMPOSITION (EMP-EMPOSITION)
- EXPERTISE (EMP-EXPERTISE)
- OFFICE (OFFICE-EMPLOYEE)
- STRUCTURE (MANAGES)
- STRUCTURE (REPORTS-TO)
- When using the table for inserts
- If you also check the No Set check box on the next
row, all records in the subschema without an associated set appear in the
field:
- COVERAGE
- HOSPITAL-CLAIM
- NON-HOSP-CLAIM
- DENTAL-CLAIM
- DEPARTMENT
- EMPLOYEE
- EMPOSITION
- OFFICE
- EXPERTISE
- STRUCTURE
- JOB SKILL
- When using the table for change capture
- All records that are in sets owned by EMPLOYEE appear in the field:
- EMPOSITION (EMP-EMPOSITION)
- EXPERTISE (EMP-EXPERTISE)
- STRUCTURE (MANAGES)
- STRUCTURE (REPORTS-TO)
The last three controls on the page are:
- RRDS
- Specifies that a record in the subschema has a
mode of VSAM and is not a member of a VSAM index set.
- KSDS
- Specifies that a record in the subschema either
has a mode of VSAM and is a member of a VSAM key-sequenced data set, or has
a mode of VSAM CALC.
- ESDS
- Specifies that a record in the subschema either
has a mode of VSAM and is a member of a VSAM entry-sequenced data set, or
has a mode of VSAM CALC.
Mapped Records for Table table-name page
Use
this page to verify the columns of the table that will be created when you
generate and run the DDL.
You can click Finish to generate the
model for the table.