In this section: |
An Access File describes the database access information, for example, database number, file number, and descriptor fields.
Note that before you can access a CA-IDMS/DB file, you must first describe it to the server in two files: a Master File, and an associated Access File. A Master File is required to describe the CA-IDMS/DB file in standard server terminology to the Adapter for IDMS/DB. For more information on the Master File, see Managing IDMS/DB Metadata.
An Access File is required to translate a request for network record types and LRF records into the appropriate CA-IDMS/DB Data Management Language (DML) retrieval commands. This file description consists of 80-character records called declarations in comma-delimited format (keyword=value).
An Access File contains three kinds of declarations:
Subschema declarations identify the subschema used, the IDMS/DB release under which the subschema was compiled, the calling mode to be used to retrieve records, and whether a trace is to be produced. Several subschema declarations may be specified in a single Access File. Each subschema declaration is followed by its segment and index declarations. Subschema Declaration Keywords describes keywords for subschema declarations.
Access File segment declarations indicate the IDMS/DB record information and the parent/descendant relationship for each network record type or LRF record described as a segment in a Master File (Access File segment declarations are not defined for OCCURS segments). Segment declarations can be specified in any order after their corresponding subschema declaration. Segment Declaration Keywords for Network Record Types and Segment Declaration Keywords for LRF Records describe segment declarations for network record types and LRF records, respectively.
Index declarations provide information about each IDMS/DB index. They may also be in any order, one for each indexed field described in the Master File, after their corresponding subschema declaration. Index Declaration Keywords for Network Record Types describes index declarations for network record types.
Each declaration consists of a list of keyword and value pairs, separated by commas. The list is free-form and may span several lines; keywords may be specified in any order. Each declaration is completed with a comma followed by a dollar sign ($). For example, this Access File contains three declarations:
SSCHEMA=PAYROLL,RELEASE=15,INDEXAREA=PRIMARY-IX-AREA, DBNAME=EMPDEMO,DICTNAME=APPLDICT,$
SEGNAME=ACCOUNT,RECORD=PAYREC,AREA=PAY-REGION, CLCFLD=EMPLOYEE_ID,CLCDUP=N,$
IXSET=IXREC-SSN,IXAREA=IX-AREA1,IXFLD=PERS_SSN, IXDUP=N,IXORD=A,$
Blank lines and lines starting with an asterisk (*) in column 1 are treated as comments. Leading and trailing blanks around keywords and values are ignored. Values that contain commas, equal signs, dollar signs, or spaces must be enclosed in single quotation marks.
If your Master File defines record types and LRF records from multiple IDMS/DB subschemas, the Access File should contain multiple subschema declarations. After each subschema declaration, list its segment and index declarations.
Subschema declarations for DML and LRF subschemas contain the following keywords; certain keywords are optional as explained in the following summary chart.
Keyword |
Description |
---|---|
SSCHEMA |
IDMS/DB subschema name. |
RELEASE |
Release of the IDMS/DB software that was used in the last compilation of the subschema. The value can be 10.2, 12, or 12.x (where x is your release version), 14, or 15. |
MODE |
Type of IDMS/DB access the adapter is to perform. Specify LR for LR and ASF records; DML is the default value. |
TRACE |
Optional keyword used for debugging purposes. It specifies whether a basic trace of all IDMS/DB calls or a detailed trace of all the parameters passed to IDMS/DB will be displayed. Values can be YES, PARMS, or NO (NO is the default value). |
READY |
Optional keyword that specifies when an LRF record is built from two or more physical record types located in several database areas. The adapter prepares or readies all the areas of the subschema. Values can be ALL or null or omitted entirely. |
DBNAME |
IDMS/DB database name from the DBNAME table corresponding to its subschema. It can be used in local or Central Version mode to translate the subschema name into the proper load module(s) for data access. |
INDEXAREA |
Name of the primary SPF index area. Required for any subschema with SPF indices. |
Keyword |
Description |
---|---|
DICTNAME |
Secondary dictionary load area, if the subschema is not located in the primary dictionary or in a load PDS. Remember that ASF subschemas are located in secondary dictionary load areas by default, so if your Access File describes an ASF record, you must specify this keyword. |
NODE |
Distributed Database Systems (DDS) node location of an IDMS/DB distributed database. The value is the IDMS/DB data dictionary table entry that identifies the DDS node location of an IDMS/DB distributed database. This keyword is required only if DDS is installed at a user site and if the subschema is located in a remote site location. |
DICTNODE |
DDS node location of an IDMS/DB distributed database subschema in a secondary dictionary load area. The value is the IDMS/DB data dictionary table entry that identifies the DDS node location of an IDMS/DB distributed database subschema. This keyword is required only if DDS is installed at the user site and if the subschema is located in a remote site location. |
Note: When running using DDS, Central Version must be used. DDS access is not supported in local mode.
Your use of keywords in segment declarations for DML record types depends on whether the record type contains a CALC key, acts as a descendant segment, or contains an index. The following keywords are common to all segment declarations.
Keyword |
Description |
---|---|
SEGNAM |
Corresponding Master File segment name of the DML record type. |
RECORD |
IDMS/DB record type name. |
AREA |
IDMS/DB area name that contains the record type. |
If your record type is CALC (that is, if the record contains a CALC key) include the two keywords below. These keywords are required for all CALC record types, regardless of how their parent/descendant relationships are implemented.
Keyword |
Description |
---|---|
CLCFLD |
Master File field name of the CALC field. |
CLCDUP |
Indicates if the CALC field allows duplicates. The value can be Y or N. |
Record types are assigned parent/descendant relationships in the server. These relationships are based on sets and CALC or index fields. Keywords for descendant segments follow. Consult your Master File to determine whether a segment is a descendant or parent.
Field |
Keyword |
Description |
---|---|---|
|
ACCESS |
Indicates the relationship that exists between record types. The value CLC or IX specifies an embedded cross-reference based on a CALC or indexed field. The value SET indicates a physical relationship based on a set of pointers. |
Set-Based (ACCESS=SET) |
SETNAME |
Name of the set relating a descendant to its parent. |
|
SETMBR |
Specifies whether the set membership is mandatory/automatic, mandatory/manual, optional/automatic, or optional/manual. This information is used to verify set membership at execution time. To determine the appropriate membership value, check the set label on your Bachman diagram. Values can be MA, MM, OA, or OM. |
|
GETOWN |
Allows or inhibits GET OWNER calls which obtain the owner records from a member record type. If the value is Y, the adapter issues GET OWNER calls to retrieve the owner record in the set when SEGTYPE is U or KLU. If the value is N, GET OWNER calls are inhibited. Specify N only when the set has no owner pointers and long member record chains are apt to occur. When GET OWNER calls are inhibited, the owner record type cannot be a descendant of its member. In other words, if GET OWNER calls are inhibited, SEGTYPE cannot be U or KLU. |
|
MULTMBR |
Indicates whether the set, in which this record type participates, contains more than one member record type. Values can be Y or N. |
|
KEYFLD |
Server field that sequences the set. Select a field from a parent or descendant segment as the value of KEYFLD in the descendant segment declaration. |
|
SETORD |
A (ascending) or D (descending) for sorted set sequence. This keyword is required. |
|
SETDUP |
Y or N if duplicates are allowed. Required for sorted sets. |
CALC-Based (ACCESS=CLC) |
KEYFLD |
Provides the search value to read CALC and index fields in descendant segments. These search values are located in parent segment fields. Specify the parent field name for the value of KEYFLD in the descendant segment declaration. The KEYFLD keyword is especially important when the two record types in a parent/descendant relationship are from different subschemas. The record type that acts as the descendant segment is the entry point into the second subschema. It must have a CALC key (CLCFLD) or index set (SETNAME) with ACCESS=CLC or ACCESS=IX, respectively. The descendant segment declaration must also list the KEYFLD value from the parent segment in the first subschema. |
Index-Based (ACCESS=IX) |
KEYFLD |
See above. |
|
SETNAME |
IDMS/DB name of the index set. A corresponding index declaration is required. |
This example shows one subschema with two segments that are CALC record types. The INVOICE record type has a set-based relationship with the CUSTOMER record type.
SSCHEMA=SAMPSSCH,RELEASE=15, SEGNAM=CUSTOMER,RECORD=CUSTOMER,AREA=CUSTOMER-REGION, CLCFLD=CUST_NUMBER,CLCDUP=N,$ SEGNAM=INVOICE,RECORD=INVOICE,AREA=INVO-REGION, CLCFLD=INV_NUMBER,CLCDUP=N,ACCESS=SET, SETNAME=CUSTOMER-INVO,SETMBR=MA,GETOWN=Y,MULTMBR=N,$
The following example shows two subschemas. The INSURANCE-PLAN record type has a CALC-based relationship with the COVERAGE record type.
SSCHEMA=EMPSS01,RELEASE=15, SEGNAM=COVERAGE,RECORD=COVERAGE,AREA=INS-DEMO-REGION,$ SSCHEMA=EMPSS03,RELEASE=15,$ SEGNAM=INSURNCE,RECORD=INSURANCE-PLAN, AREA=INS-DEMO-REGION,CLCFLD=INS_PLAN_CODE,CLCDUP=N, ACCESS=CLC,KEYFLD=COV_CODE,$
If your record type contains an indexed field, you may suppress area sweeps when the segment is used as a point of entry into the database. To prevent area sweeps, specify the optional keyword below on the segment declaration. Only those record instances connected to the specified index field are accessed.
Keyword | Description |
---|---|
SEQFIELD | Master File field name (FIELDTYPE=I) of the index. |
Note: This optional keyword requires an index declaration (see Index Declaration Keywords for Network Record Types).
Segment declaration keywords for LR and ASF records are basically the same as those for network (DML) record types. Specified values, of course, differ.
Keyword |
Description |
---|---|
SEGNAM |
Corresponding Master File segment name of the LRF record. |
RECORD |
IDMS/DB name of the LRF record. |
LR |
Value is Y. |
AREA |
IDMS/DB area name that contains physical record types. Specify READY=ALL on the subschema declaration for more than one area (if fields originate from many areas). |
LRF records use embedded cross-references to create parent/descendant relationships. Specify the following keywords for LRF records that act as descendant segments:
Keyword |
Description |
---|---|
ACCESS |
Value is LR. |
KEYFLD |
Master File field name found in the parent. |
IXFLD |
Master File field name found in the descendant. |
The KEYFLD and IXFLD keywords are required to implement parent/descendant relationships. The KEYFLD keyword specifies a field from the parent segment that provides search values. The value of IXFLD, in turn, is a field in the descendant segment that contains equivalent values for KEYFLD. Any field may be selected for IXFLD provided that the record possesses a null SELECT clause.
Suppose your Master File for one subschema contained two LRF records that act as parent and descendant segments:
FILE=DEPTEMP,SUFFIX=IDMSR,$ SEGNAME=DEPTEMP,$ . . . FIELD=EMP_ID ,ALIAS= ,USAGE=A4 ,ACTUAL=A4,$ SEGNAME=EMPJOB, PARENT=DEPTEMP, SEGTYPE=S,$ FIELD=EMPLOYEE_ID ,ALIAS= ,USAGE=A4 ,ACTUAL=A4,$ . . .
The common field is EMPLOYEE_ID; its field format is the same in both segments. The EMPJOB segment is the descendant of DEPTEMP. The descendant segment declaration in the Access File below contains KEYFLD and IXFLD values:
SSCHEMA=EMPSS06,RELEASE=15,MODE=LR,READY=ALL DBNAME=EMPDEMO,DICTNAME=APPLDICT,$ SEGNAM=DEPTEMP,RECORD=DEPT-EMPLOYEE, AREA=EMP-DEMO-REGION,LR=Y,$ SEGNAM=EMPJOB,RECORD=EMPLOYEE-JOB, AREA=ORG-DEMO-REGION,LR=Y, ACCESS=LR,KEYFLD=EMP_ID,IXFLD=EMPLOYEE_ID,$
If the EMPJOB segment (EMPLOYEE-JOB record) belonged to a different subschema, the Access File example above would include another subschema declaration positioned between the two segment declarations.
The Adapter for IDMS/DB supports two indexing schemes: the traditional method of indexing, using the Sequential Processing Facility (SPF), and IDMS/DB Integrated Indexes. Under SPF, index entries are stored in separate index areas. As of IDMS/DB Release 10, indexes may be integrated with the Database Management System (DBMS).
The following keywords apply to declarations for both SPF and Integrated Indexes. For an example of an index declaration, see Access File Syntax.
Keyword |
Description |
---|---|
IXSET |
IDMS/DB setname of the index set. |
IXFLD |
Corresponding Master File field name with FIELDTYPE=I. |
IXDUP |
Indicates if duplicate index values are allowed. Value can be Y or N. |
IXORD |
Indicates the sort order of the index. Value can be A (ascending) or D (descending). |
IXAREA |
IDMS/DB area name of the index; usage varies, see below. |
Note:
iWay Software |