Use the New CA-IDMS Table wizard to map information from a schema
to a new table. This wizard helps you convert record layouts from schema and
subschema reports in SQL column definitions.
You can provide the information on which to base the table in
one of two ways:
- You can import schema and subschema files that were punched from the CA-IDMS
dictionary and transferred via 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.
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.
When a table for CA-IDMS maps to multiple CA-IDMS
records, all updates that are made by client applications to the data are
applied only to the last record in the PATH clause. If updates need to be
done on a different record in the path, you must create another table in which
that record is the last record in the path.
Each table represents a
single record or path through an CA-IDMS schema. You define a path by starting
with a single record and then navigating sets to additional records in the
schema.
CA-IDMS Discovery page
Use this page to select the
data model and schema in which you want to create the table in your project.
Also,
use this page to specify where the data that you want to base your table on
is located.
- Database model
- Type the path and name of the database model in
which you want to create the table. For example, if your project is named
MyProject and your database model is named MyModel, type \MyProject\MyModel.
You can click Browse to select a database model.
- Schema name
- Select the schema in which you want to create
the table, or type a new schema.
- Remote CA-IDMS discovery
- Specifies that you want Classic Data Architect
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 a name 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 subschema that is specified. 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 information page
Use this page to specify
information about the location of the data structures in CA-IDMS and to specify
how the table will be used.
- Subschema name
- Displays the name of the subschema that was obtained
through a remote connection to the CA-IDMS database or from the local subschema
file that you specified.
- Schema name
- Displays the name of the schema that was obtained
through a remote connection to the CA-IDMS database or from the local schema
file that you specified.
- Schema version
- Type a valid 4-digit integer between 0 and 9999
that, together with the schema name, uniquely identifies a CA-IDMS schema.
The schema version follows CA-IDMS schema version naming conventions.
- Dictionary database
- Type a name of 1 to 8 characters for the CA-IDMS
database for the dictionary that contains the schema and subschema definitions.
The data server binds to this dictionary to gather information from the schema
and subschema when creating the logical table. The identifier follows CA-IDMS
database naming conventions.
- Data database
- Type an identifier of 1 to 8 characters for the
CA-IDMS database name that contains the user data that the data server will
access at runtime.
- Access load module
- Type an identifier of 1 to 8 characters for the
CA-IDMS batch access module to be used to communicate with the CA-IDMS central
version that hosts the user data. The CA-IDMS identifier follows z/OS load module
naming conventions.
- Select table usage
- Specify how the table will be used.
- Query
- Specifies that the table will be used for retrieving
data by Classic Federation.
- Update
- Specifies that the table will be used for updates
of data by Classic Federation.
- Insert
- Specifies that the table will be used for inserts
of data by Classic Federation.
- Change capture
- Specifies that the table will be used as a source
table for a publication or a subscription.
- Create view
- Use these controls to indicate whether you want to create a view on the
table.
- No
- Specifies that you do not want to create a view.
- Yes
- Specifies that you want to create a view on the table. This option allows
you to create a view for Classic federation. You can use the view to filter
record types and to filter rows and columns.
- Yes with change capture
- Specifies that you want to create a view on the table. This option allows
you to create a view for change capture. You can use the view to filter record
types and to filter rows. The view must reference all of the columns that
are in the table.
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 records or sets,
with the exception of the previous record and 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 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 records and set relationships,
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.
Summary page
Use this page to verify the columns
of the table that will be created when you generate and run the DDL.
If
you are creating a view on the table, you can view the SELECT statement that
Classic Data Architect will base the view on.
You can click Finish to
generate the model for the table.