Makelist begins by creating a list of logically related databases. The DBDGEN definitions are used to determine the relationships. Once the set is determined, it creates the required load and logical pointer update steps to load the databases.
Makelist builds the list by starting with a single DBD name. The databases referenced by logical children in the input DBD are added to the list. These newly-added DBDs are scanned and databases referenced by their logical children are also added to the list. This continues until all of the relationships are located. Makelist requires that all of the physical DBDs have been genned. If a DBD referenced by a logical child is not found, an error message is issued and Makelist terminates. The error message includes the required DBD name. You should gen the DBD and re-run Makelist.
Databases referenced by logical children also need to be genned and at least zeroloaded. That is, if you need access to a database with a logical child, you must also gen the logical parent database and at least zeroload it.
However, if you need a database which contains only a logical parent for a unidirectional relationship, the database containing the logical child is not required. Thus, you may get different results from Makelist depending on the DBD name you start with.
You should review the output of Makelist for databases which define unidirectional logical relationships. You could also run Makelist multiple times with different initial DBD names and merge the output Runlist files. Database load steps can also be added by editing the Runlist command file manually. This is an ASCII text file and can be edited in any text editor. For any required logical child database which was not located, add a Load step at the top of the file and a PtrUpdate step at the bottom. All PtrUpdate steps should follow the Load steps.
Consider three logically related databases - 'A', 'B', and 'C'. Database A contains a logical child segment which defines a uni-directional logical relationship to database B. Database B contains the logical parent for database A's logical child. A second uni-directional logical relationship is defined between databases B and C. Database B contains a logical child segment which points to the logical parent in database C.
In other words, database A points to database B and database B points to database C. A is related to B and B is related to C by uni-directional relationships.
Example 1
If database A is used as the starting DBD name, databases B and C are both included. Database C contains no logical child segments and does not require a pointer update step. The sequence of the load steps is:
LOAD A DSN(... LOAD B DSN(... LOAD C DSN(... PTRUPDATE A ... PTRUPDATE B ...
Example 2
If database B is used as the starting DBD name, only database C is included. Database C contains no logical child segments and does not require a pointer update step. The sequence of the load steps is:
LOAD B DSN(... LOAD C DSN(... PTRUPDATE B ...
If your application requires the use of database A, a Load and PtrUpdate step must be added manually. MFIMS does not require database A if you only access databases B and C. The Load step for A must be placed prior to the first PtrUpdate step. The PtrUpdate step can be placed anywhere after the last Load step.
Example 3
If database C is used as the starting DBD name, databases A and B are not included. The load step is simply:
LOAD C DSN(...
If your application requires the use of database A and B, the Load and PtrUpdate step must be added manually. You do not need databases A or B if you only need access to database C. The steps to load all three databases is shown in Example 1.