The IMS Catalog allows you to capture these layouts, also known as mappings in your DBD source, by using the DFSMAP and DFSCASE macros of the DBDGEN process. Until now the layout of a segment was dependent on the contents of a field within the segment itself – for example, the DEPENDINGON= parameter of the DFSMAP statement had to specify the name of a field that exists in the segment for which the mapping is being defined.
The Enhancement We Made
A new enhancement to IMS 14 and later introduces the ability to define segment layouts that depend on the contents of a field in another segment’s key or subset of that key. To be more specific, the name of a parent segment or a child segment, depending on how the database is viewed, can be used as the control segment name to be captured in the IMS Catalog. Then, the IMS Universal Drivers can use the control segment name that was captured in the IMS Catalog to apply the correct mapping to a segment. Thus, the layout of a segment is no longer restricted to the contents of a field within the segment itself.
Having the IMS Universal Drivers take care of segment mapping is one of the big benefits of this enhancement because Java application developers do not need to write custom mapping logic in their applications. Database administrators benefit as well because now they have more flexibility in how they design or augment their IMS databases and can have peace of mind knowing that the new mapping information is stored in the IMS Catalog.
To define this new information to your DBD, use the optional control segment name parameter, CTLSEGNM=, of the DFSMAP macro in conjunction with the existing DEPENDINGON= parameter. The important thing to note here is that the control segment must be a segment that is in the same hierarchical path as the segment we are trying to map, and the field you specify on the DEPENDINGON= parameter must be part of the key of the control segment. For more details see the examples below.
If you are not familiar with the existing dynamic segment layout support, check out these two articles:
Those articles will show you how dynamic segment layouts can be used and give you a better sense of how the new enhancement adds even more value and flexibility to the concept of dynamic segment layouts.
And Now For Some Examples
Let’s take this simple database as an example. It has a root segment and two child segments, ChildA and ChildB. If you look at segment ChildB you will notice that it has a key field, followed by a field named “FieldA” and finally a field or section that is 500-bytes long and has no name. Suppose we want to define dynamic segment mappings for those 500-bytes of ChildB. To do so, we have some options. The least desirable option is to write and maintain custom mapping logic in every application that will access the segment. The use of the original segment layout support provided by IMS and the use the new control segment support also provided by IMS are the more desirable options. The examples below will focus on the last two options because they are more efficient and don’t require custom mapping logic to be written as part of the application that will access the segment.
With the original support for dynamic segment layouts, we could use “FieldA” as the value for the DEPENDINGON= parameter of the DFSMAP statement. Remember, the original support states that the mapping of the segment depends on the contents of a field that is defined within the segment we are trying to map. Therefore, we can use “FieldA” because it is a field defined in segment ChildB. So, when an instance of segment ChildB is retrieved from the database, its layout will be dictated by the contents of “FieldA.” The mapping definition for segment ChildB would have the following format:
DFSMAP NAME=MAP1,DEPENDINGON=FieldA
Then you would define the different cases with the DFSCASE statement to indicate how those 500 bytes are mapped.
With the new enhancement made to IMS Database, the DFSMAP statement can now specify the name of a control segment via the new CTLSEGNM= parameter and the existing DEPENDINGON= parameter can specify the name of a field that is within the key range of the control segment specified on CTLSEGNM=. Therefore, we can now specify Root as the control segment name and its field “Kfield1” as the field whose contents will determine how the segment ChildB gets mapped. When an instance of segment ChildB is retrieved from the database, its layout will be dictated by the contents of the Root segment’s field “Kfield1.” This is possible because when we retrieve segment ChildB we are also getting key feedback data from the database. The key feedback data is the concatenation of the keys of all segments that are part of the hierarchical path above the segment we are retrieving from the database. Therefore, the mapping definition for segment ChildB can now have the following format:
|...+....1....+....2....+....3....+....4....+....5....+....6....+....7.. DFSMAP NAME=MAP1, * CTLSEGNM=Root, * DEPENDINGON=Kfiled1
Then you would define the different cases with the DFSCASE statement to indicate how those 500 bytes are mapped.
After you modify the DBD source for your database you would need to perform DBDGEN, ACBGEN, and IMS Catalog populate steps to store the new control segment information in the IMS Catalog. The latest version of the IMS Universal Drivers can pull the database metadata from the IMS Catalog and start using the new control segment information when working with SQL statement that reference segment ChildB.