3.20.3 The Make New or Amended Definition Operational Job Failed
The most common causes of a "make new or amended file definition operational" job failure are described in detail below:
The Renamed "$$" File Has Not Been Deleted
When LANSA re-creates a file it renames the existing version of the file by appending the prefix "$$" to the name. Thus existing file CUSMST would be renamed $$CUSMST before the new version of CUSMST is created.
This will always work the first time that a file is re-created because no "$$" version exists. However, if the file definition is changed a second time, and nobody bothered to delete the "$$" version created during the first change, it will fail. This is because it will attempt to rename the existing file to a name that already exists.
When re-creating a file after amending its definition this is recommended:
1. Check that the new file has been re-loaded correctly (i.e. it actually contains the correct data).
2. Delete the "$$" version. Note that "$$" versions are only created when it is necessary to delete and re-create the physical file. Thus not all file re-creation jobs will actually produce a "$$" version of the file.
The File Cannot Be Allocated for Exclusive Use
The file re-creation job attempts to place an exclusive lock on the file being re-created. If any other user or job in the system has the file open then the re-creation job will not be able to gain an exclusive lock and will fail. This situation is indicated clearly by messages on the job log.
In such cases request that all users of the file stop using it. This may mean waiting until batch jobs complete or asking interactive users to cease using certain processes. In cases where LANSA processes were created with the HEAVY usage option (see process definition for more details) the user may have to sign off and on again to actually close the file.
To find which users / jobs have a particular file open use the WRKOBJLCK (display object locks) command that is part of the IBM i operating system control language. Refer to the IBM supplied for more details.
Note: When a "make file definition operational" job fails, examine the associated job log carefully for problems such as these before contacting your product vendor. When examining a job log read it backwards. The message(s) associated with the problem that caused the job to fail will be one of the last messages issued. Messages at the beginning of the job log may appear to be the problem, but may in fact indicate normal situations that are catered for by LANSA.