When the LANSA file definition has been amended and the menu option to make an amended file definition operational is taken this occurs:

• LANSA compares the amended definition of the file with the associated IBM i physical and logical files that currently exist. During the comparison a list is prepared that details all the actions required to make the physical and logical files identical to the amended file definition. This procedure is analogous to the "set operational" procedures used by many IT installations.
• Working from the list of actions built in the preceding step LANSA then recreates the physical and logical files to match the amended file definition. All of the work is done in temporary areas so if the recreation fails the database will be left in its prior condition and users can continue to use it.

• The type of action taken during a re-creation vary widely with the type of amendment made to the LANSA file definition. This is best illustrated by examples:

  Type Of Amendment	Actions Taken During Re-Creation
  New logical view added	New logical view created in temp area New logical view moved to user library.
  New field added to file	New physical file created in temp area New logical views created in temp area New I/O module created in temp area New physical file in temp area loaded from existing physical file. Existing physical file renamed * Existing logical views deleted Existing I/O module deleted New physical file moved to user library New logical views moved to user library New I/O module moved to user library
  Validation rules changed	New I/O module created in temp area Existing I/O module deleted New I/O module moved to user library.

  Note the action indicated with a "*". The existing physical file is renamed by prefixing it with "$$". Thus existing file CUSMST will be renamed $$CUSMST before the new version of CUSMST is actually moved into the user library.

  
  

  This is an important step because it means that the data in the file can never be accidentally lost. However, 2 points should be noted:
   
• When a file re-creation has completed there are 2 versions of the file in the user library. The new version that has been loaded and the old version (with the "$$" prefix). This means that until the "$$" version is deleted twice as much disk space is being used.
• The "$$" version can be manually deleted (refer to the DLTF delete file command in the IBM supplied Control Language Reference Manual) or a request can be set to YES on the Make File Operational screen to delete the $$ version of the file during the batch process. Note that the request to delete a $$ version of a file will only appear if a $$ version of the file being recreated actually exists.