This section describes the three phases of the Coordinator Check Cycle.
This section covers the following topics:
During this phase of the Check Cycle, the Coordinator detects conflicts that result from the Internal IDs of objects on the Coordinator FDIC. The concept of the Internal ID and possible solutions of conflicts are described in this section.
All objects are given an Internal ID. This Internal ID is assigned automatically when an object is added. It is unique worldwide and remains the same throughout the entire lifespan of the object. Even if an object is renamed, the Internal ID remains unchanged.
When you transfer data with the Coordinator you must decide whether the Internal ID is transferred with the object or whether a new Internal ID is assigned in the target environment. This is controlled by the parameter with Internal ID of the Export/Unload function. This parameter is set to Y as default.
If with Internal ID is set to Y, objects are loaded to the target environment together with their Internal ID. If you set this parameter to N, the Internal ID will be ignored. The advantages and disadvantages of the two methods as well as examples are given below.
| Parameter with Internal ID set to N: | Parameter with Internal ID set to Y: |
|---|---|
|
|
| Advantage | Advantage |
| No conflicts resulting from the Internal ID are possible. Each object recieves a new Internal ID, and the objects are handled on the basis of their object IDs. | Objects can be transferred backwards and forwards within your organization, and you will still be able to identify each object uniquely. |
| Disadvantage | Disadvantage |
| Conflicts will occur when these copies are consolidated at a later date. | Conflicts are possible. These conflicts must be resolved before you can load the data. See Conflicts resulting from the Internal ID |
In an environment with two FDIC files, FDIC A and FDIC B, the following transfer operations are performed with the parameter with Internal ID set to Y:
The system TOURS is created on FDIC A. TOURS is unloaded from FDIC A and loaded into FDIC B.
On FDIC A, the system TOURS is renamed in SAG-TOURS. The renaming does not affect the object's Internal ID; the Internal ID remains unchanged.
The system SAG-TOURS is unloaded from FDIC A and loaded into FDIC B.
On FDIC B, the system TOURS has been overwritten by SAG-TOURS, because TOURS and SAG-TOURS have the same Internal ID. This means that on FDIC B, only the system SAG-TOURS exists.
Performing the example above with the parameter with Internal ID set to N has the following result:
Both systems TOURS and SAG-TOURS exist on FDIC B. Transferring objects in former versions of Predict, before the Internal ID was introduced, had the same result.
Note:
Choose this method if you wish to create a copy of
the object in the target environment in order to use this copy as a template
for new objects.
In an environment with two FDIC files, FDIC A and FDIC B, the following transfer operations are performed with the parameter with Internal ID set to Y :
The system SAG-TOURS is created on FDIC A.
The system SAG-TOURS is created on FDIC B.
The system SAG-TOURS is unloaded from FDIC A and loaded into FDIC B.
The Coordinator determines that SAG-TOURS on FDIC A and SAG-TOURS on FDIC B are different objects, because they have different Internal IDs. The Coordinator informs you about this conflict and cancels the operation.
On the Coordinator FDIC, you can:
rename the system SAG-TOURS, for example, to TOURS. then the system can be loaded. This results in two systems on FDIC B: SAG-TOURS and TOURS.
delete the system SAG-TOURS on FDIC B. Then the system SAG-TOURS can be loaded.
delete the system SAG-TOURS on the Coordinator FDIC.
Performing the example above with the parameter with Internal ID set to N has the following result: On FDIC B, the system SAG-TOURS is overwritten by the loaded system SAG-TOURS. Transferring objects in former versions of Predict, before the Internal ID was introduced, had the same result.
Note:
Choose this method if you wish to create a copy of the
object in the target environment in order to use this copy as a template for
new objects.
Conflicts may occur when objects are unloaded with their Internal IDs and then loaded. These conflicts must be resolved by the user before the data transfer can be continued. Conflicts are normally resolved on the Coordinator FDIC.
When a conflict occurs, the report listing created when the function is started is updated. See Logging Coordinator Functions .
The possible conflicts and their solutions are described in the following sections.
Note:
If you remove the conflicting object from the extract
containing the list of objects to be transferred, this will enable you to
continue the data transfer. It is not, however, a solution we recommend.
Main FDIC contains an object with the same object ID but with different Internal ID, and no other object with this Internal ID exists on the Coordinator FDIC:
There are two ways to resolve this conflict, depending on the desired result.
Consolidate the Internal IDs of objects of the same name (see Consolidating Internal IDs in Batch Mode).
Note:
Choose this solution only if both objects with the same
name and different Internal IDs have the same business meaning.
Execute command CLEAR to cancel the load operation with which the conflict occurred.
Unload the object that caused the conflict once again with its Internal ID (function Unload with parameter Data type=I from the Coordinator main menu).
Execute the function Load Internal ID to consolidate the Internal IDs. As a result, all objects of the same name will have the same Internal ID.
Reexecute the load operation you cancelled in step 1.
Rename OBJ-1 on the Coordinator FDIC:
This conflict can only occur if you used the Special Function Maintain Standard Fields > Move field to another standard file to assign a standard field to another standard file. See Maintain Standard Fields in the section Special Functions in the Predict Administration documentation.
In the example below, the target environment contains a field with the same Internal ID as the object to be loaded, but the corresponding file has a different Internal ID to the file in the source environment.
This conflict is resolved automatically: The field in the source environment (Coordinator FDIC) is given another Internal ID. This is logged in the report listing (see Logging Coordinator Functions) so that the relationship can be restored at a later time with the Special Function Maintain standard fields > Reassign standard relationships.
The data to be loaded contains different objects with the same Internal ID as shown in the example below. This conflict can only occur if there are errors in the ALF or Migrate file you created.
Correct your ALF or Migrate file, or delete one of the conflicting objects in the Coordinator FDIC.
When data is transferred to or from another FDIC, the data is checked against the corresponding security definitions in Natural Security (NSC). The database and file number of the Natural Security file are specified with parameters General Defaults > Protection > DBnr/Fnr of NSC file.
The following rules apply:
For functions Unload and Export, security checks are performed against the NSC file of the source FDIC.
For functions Load, Import and Test, security checks are performed against the NSC file of the target FDIC.
Source and target FDICs do not necessarily have to have the same NSC file.
For functions Unload and Export you need the following access:
at least READ access to an object. Objects for which you do not have READ access will not be unloaded / exported.
READ access to the extract(s) containing the objects to be transferred.
EXECUTE permission to the function CO-EXPORT in Natural Security.
You must have at least READ access to all objects within the IMS structure, and all objects must be present in the transfer set (not necessarily in the same extract). If one of the objects is missing or if you do not have sufficient access to one or more objects in the structure, all IMS objects are skipped, and the function continues without these objects. The report listing is updated accordingly.
OBJ-4 is not included in the extract because of insufficient access rights and will not be exported/unloaded (for example, when function Build Extract is used with restrictions).
However, depending on the retrieval function used to create the extract, the extract may contain objects to which the user does not have READ access (OBJ-3 in this example). These objects will not be exported/unloaded either.
It is also possible that the current user does not have READ access to objects in the extract because it was created by another user with different access rights.
When the Unload or Export function is executed, Predict Security checks the objects in the extract against Natural Security authorizations in the source environment. If the user does not have at least READ access to an object, the object is not exported/unloaded and the rejected object is logged to a report listing.
For functions Load and Import you need
ADD access in the target environment if new objects are loaded/imported.
MODIFY access in the target environment if existing objects are to be overwritten.
EXECUTE permission to the function CO-IMPORT in Natural Security.
If objects fail the security check because the user does not have sufficient access, the Load/Import function stops, and the objects must either be removed from the set of objects to be transferred or the appropriate permission must be granted in the target environment.
No data is transferred with this function, but the same access rights are required as for functions Load and Import, and the same checks are performed. If objects fail the security check because the user does not have sufficient access, the Test function stops.
No special security checks are performed for function Purge Transfer Data.
Coordinator functions are protected using Authorizations for the following functions in Natural Security:
| NSC Function | Coordinator Functions |
|---|---|
| CO-IMPORT | Load, Import and Test |
| CO-EXPORT | Unload and Export |
The Consistency Check is the third phase of the Coordinator Check Cycle. Objects to be transferred are checked for logical consistency, for example that a file number only occurs once within a database. The same checks are performed as in Maintenance functions.
When they are created, all logically inconsistent objects are written to the report listing which logs the function, and extract #SAG-ERROR is added or modified.
You must resolve logical inconsistencies on the Main or Coordinator FDIC before you can continue the data transfer.
If you delete objects in the Coordinator FDIC to resolve the inconsistencies, the extract #SAG-TRANSFER is updated accordingly.