This document covers the following topics:
Natural for DL/I allows use of data stored in IMS/DL/I databases with Natural applications. Natural for DL/I uses the following control blocks:
Natural for DL/I database descriptions (NDB) containing the information about the segment structure of an IMS/DL/I database and about the key fields of the segments.
Natural for DL/I program specification blocks (NSB) reflecting an external view of a database, as it is used by an application program.
User-defined fields (UDF) establishing a field structure in a database segment.
For more details see the description of the Natural SYSDDM Utility in the Natural Utilities Menu.
Predict supports the use of Natural for DL/I in the following ways:
IMS/DL/I databases can be documented.
User-defined fields can be documented (as segment layouts).
Userviews of segments can be defined.
Natural DDMs for IMS/DL/I segments and their userviews can be generated.
Copy code for segment layouts in third generation languages can be generated.
User-defined fields for Natural for DL/I can be generated.
The documentation of NSBs (Natural for DL/I program specification blocks) is currently not supported by Predict.
IMS/DL/I data structures are documented with objects of the following types:
Databases are documented with database objects of type I.
Segments are documented with file objects of type I.
Sequence fields, search fields and alternate index fields are documented with field objects in these files.
Segment layouts are documented with file objects of type J.
Userviews are documented with file objects of type K.
There are two types of IMS/DL/I databases: physical and logical. The file list of a database object of type I consists only of files of type I.
Segments of an IMS/DL/I database are documented with file objects of type I. There are four types of IMS/DL/I segments:
logical segments (only in logical databases);
physical segments (only in physical databases);
logical children (only in physical databases);
virtual logical children (only in physical databases).
Each file of type I belonging to a physical database contains the sequence field, the search fields and the alternate index fields of the segment it documents. These fields are referred to below as "IMS/DL/I fields".
Each file of type I belonging to a logical database contains the IMS/DL/I fields of the segment of a physical database from which it is derived. A concatenated segment in a logical database contains the IMS/DL/I fields of both the logical child (virtual logical child) and the logical parent (physical parent of paired real logical child) from which it is derived.
User-defined layouts for an IMS/DL/I segment are documented with files of type J. Each file of type J has a master file of type I that documents the segment. Field definitions of a segment layout have the same structure as definitions of a sequential file: the position of a field cannot be specified directly but is determined by its offset. The offset is calculated from the lengths of the fields already defined. Therefore dummy fields must be defined if space is to be left free between two fields.
The IMS/DL/I fields of a file object of type I can be contained in the file of type J but they must have the same format, length and offset as in the file of type I.
Predict allows field IDs longer than 19 characters for files of type J; IDs of this length are not supported by SYSDDM. For this reason we recommend the following:
Only use Predict to generate DDMs from files of this type. Do not use the utility SYSDDM. This can be enforced by setting the general default parameter Protection > SYSDDM utility to C or D.
Only use the Predict Coordinator to transfer DL/I structures. If you use Natural utilities, field IDs longer than 19 characters will be truncated.
Userviews of the segment are documented with file type K. Userviews have as master files the files of type I that document the segment. A userview (file type K) can contain the IMS/DL/I fields of the segment (type I) and fields of each layout (type J) of the segment.
Databases and file objects of type I are created by incorporating Natural for DL/I NDBs using the Incorporate NDB function. These objects cannot be created manually using Predict maintenance functions Add Database/File.
The following rules apply for incorporation of IMS/DL/I databases and segments:
A Natural for DL/I NDB is generated by assembling an IMS/DL/I database description (DBD) with the Natural for DL/I macro library according to the Natural Utilities documentation. When this has been done, the NDB can be incorporated into Predict.
Before a logical NDB is incorporated, the physical NDB or NDBs from which the logical NDB is derived should be incorporated so that the references to source segments can be established. Also, if a physical NDB contains a virtual logical child and the paired real logical child is located in a different NDB, the NDB containing the real logical child should be incorporated first. If this is not possible, because there are either references back to the first NDB, or references to source segments inside the same NDB, the incorporation must be run twice to make sure that all source references are established.
If user-defined fields for a segment have been defined in the SYSDDM DL/I services before the NDB is incorporated, the Incorporate NDB function incorporates the user-defined fields as well. In this case, at least one file of type J is created. If there are redefinitions in the user-defined fields, several layouts are created for the segment.
For details and options of the NDB incorporation function, see the section Incorporation in the External Objects in Predict documentation.
The segment structure of an IMS/DL/I database and the format, length, offset and type of the IMS/DL/I fields can be changed by carrying out the following three steps:
rewrite the IMS/DL/I database description
reassemble the IMS/DL/I database description with the Natural for DL/I macro library
incorporate the resulting NDB into Predict using the Replace option.
Note:
These attributes cannot be changed with maintenance functions as
described in the section Maintenance in the
Predict Reference documentation.
When an NDB is replaced, existing segment layouts in Predict are not replaced. Hence, user-defined fields are only incorporated once, and should from then on be maintained only in Predict.
Only certain attributes of Predict field objects contained in files of type I can be changed, for example, Field ID, Natural edit mask and Abstract. Certain changes to field formats are allowed, as described in the section Field in the Predefined Object Types in Predict documentation.
Segment layouts (type J) can be modified without restrictions. Also, new layouts can be created and existing layouts can be deleted.
A userview (file of type K) can be created by selecting fields of a segment (file of type I) and fields of layouts (files of type J) that belong to that segment. Attributes such as field ID, Natural edit mask and field comments can be changed in Predict objects belonging to files of type K.
DDMs can be generated for files of type I, J and K.
The generation of a DDM requires the existence of the corresponding Natural for DL/I user-defined fields (UDF). The required UDF is generated automatically whenever a DDM for a segment is generated (or regenerated if the segment layouts have been changed). A UDF can also be generated independently from the generation of a DDM. When generating the UDF, Predict automatically selects a valid database number (for example a database number which is defined in an IMS or DL/I macro) and a free file number. These numbers are later used for the DDM generation.
The position and length of fields in a UDF is determined from the layouts of the segment (file type J).
Each DDM contains the IMS/DL/I fields of the given segment and the higher level segments. Additionally the following definitions will be contained for the different file types:
The DDM of a file of type I contains the fields of all layouts of that segment.
The DDM of a file of type J contains the fields of that layout.
the DDM of a file of type K contains the fields of that userview.
Copy code for record buffers in third generation programming languages can be generated for a given layout (file of type J). Synchronized and align options are not allowed: for FORTRAN copy code, fields must already lie within the appropriate boundary.