5.11.1 When to Use or Not Use the File Maintenance Utility?

The file maintenance utility is provided as an aid to software developers for the entry of test data and the testing of file validation rules. As such, it is primarily designed to handle 'mainstream' processing requirements in database files set up and maintained by LANSA.

If it is used on files that contain 'non-mainstream' features, some minor problems may occur that require the construction (by application template) of purpose built (or tailor made) RDML functions to fully support your testing requirements.

Files that are under commitment control should be treated with extreme caution. If a file under commitment control is maintained, the utility will issue commit operations after each insert, update and delete. It is the responsibility of the user to ensure that the file is journalled and that the job has had commitment control started.

Some of the 'non-mainstream' situations that the file maintenance utility will not handle, requiring the construction of purpose built RDML functions, include the following:

• Files that have no primary key. The FMU insists that the physical file underlying the file being processed has a primary/unique key. This is not true of RDML functions.

• Multi-member files. The FMU will only work with the first member in any file. This is not true of RDML functions.

• Alteration of file being used by library list. The FMU will only work on the file selected, in the library selected, as it is invoked. This is not true of RDML functions which will work on the first occurrence of the file found in the library list.

• Internally described files. Again, RDML functions can be constructed to handle internally described files.

• Files that do not have an I/O module. Since version 4.0 it has been possible to use files without having an I/O module. Such files cannot be manipulated by the FMU.

• Files in production systems. The FMU is provided as a tool to aid software developers. As such, it is not a strategic part of LANSA, and should not be used in production systems in any way.

• Files with fields that have keyboard shifts J or E and are longer than 60 bytes. This is because FMU cannot guarantee the integrity of such fields. This impacts users of DBCS languages only.