3.19.1 What Happens When a File Definition Is Loaded (or Re-Loaded)?

These are the steps taken in the loading / re-loading of a file definition:

• The user's authority to alter the LANSA file definition is checked.

• The LANSA file definition is checked to ensure that the file is defined as being "OTHER". (Maintained by some method OTHER than LANSA.)

• The fields within the external file are checked to see if they currently exist within LANSA data dictionary. If they do then their type, length, number of decimal positions and keyboard shift must match the dictionary definition. If they do not exist then the field definition is automatically added to the LANSA data dictionary.

Note: At this stage, if any FATAL errors have occurred then the process will end prematurely and the LANSA file definition will remain unchanged.

• The LANSA physical file definition is then deleted and re-loaded from the external file definition. Any rules or triggers that directly reference fields no longer in the file definition are automatically deleted.

• The LANSA definitions of any logical files based on the physical file are then deleted and re-loaded from the external file definitions. As each logical file is located, the user is asked whether or not they wish to make the file accessible via LANSA.

Note: A logical file may be "dropped" for any of these reasons during this stage of the load process:

• You elect to not make the logical file accessible

• It resides in a different library than the physical file

• It is not recognized as being a logical file

• It contains more than one record format

• Its key is made up of concatenated fields

• Its name exceeds 10 characters in length

• It has already been defined to LANSA

• An identical access path already exists

• Other errors prevent the extraction of its definition.

If a logical view is "dropped" by LANSA it just means that the logical view cannot be used / accessed via LANSA. This has no impact on any system other than LANSA.