3.1.4 LANSA and Other System File Definitions

When a file definition is being set up under LANSA you will be requested to nominate who is to maintain the associated physical and logical database file definitions.

Two options are possible:

• The first is to nominate LANSA as the file maintainer. By doing this you are indicating that LANSA should set up and maintain (i.e. create, change and delete) any IBM i physical and logical files associated with the file definition. If this option is used the file must not already exist in the system, because you have elected to have LANSA create the file and maintain it in the future.

• The second is to nominate some OTHER system or mechanism as the file maintainer. In this case you are indicating that the physical file (and any associated logical files) already exist in the system and you only wish to load the definition of the files into LANSA and you will continue to maintain the definition of the file outside of the LANSA system. Once this has been done and the associated I/O module created, the file can be accessed through LANSA just like a normal LANSA maintained file, even though it is not one of the LANSA files in the strict sense.

When the OTHER option is used in a file definition several of the file definition facilities behave in a different manner. For instance:

• The "fields in a file" facility will display the fields in the file definition but will not allow them to be changed. This is because the file definition is not to be maintained (i.e. changed) by LANSA.

• The "logical views" facility will display the logical view definitions but will not allow them to be changed for the same reason as the preceding point. In addition select / omit criteria are not displayed for a logical file maintained by some OTHER system.

• The "make new or amended definition operational" facility will never actually perform an action that modifies the associated physical or logical database files in any way. Only the LANSA created file I/O module will ever be changed.

In all the cases just mentioned, a "reminder" message will appear on line 22/24 when the facility is used. This indicates that the file is maintained by some OTHER system and thus certain actions cannot or will not be taken.

Also when the OTHER option is used in a file definition, binary, date, time and timestamp fields will be supported. As these fields' support only exists for OTHER files, and Visual LANSA does not allow direct porting of OTHER files, this feature will only be supported for the IBM i operating system.

• Any binary field encountered will be enrolled in the LANSA data dictionary as a packed decimal field with the same number of digits and decimals as the source binary field.

• As far as LANSA is concerned the binary field is a packed decimal field at all levels above the I/O module (or I/O module routines in *DBOPTIMIZE or *DBOPTIMIZE-BATCH functions)

• This allows direct support of already existing files containing or keyed by binary fields, but not creation of files through LANSA containing or keyed by binary fields.

• Date, time and timestamp fields (IBM L, T and Z data types) found in the file are enrolled as alphanumeric fields with the same length as required by the formatted field (For example, a date field with *ISO format would be defined with a length of 10 characters).

• When date, time and timestamp fields are added to the LANSA Data Dictionary, default values consistent with those defined by IBM are assigned in the LANSA Data Dictionary. These default values must be reviewed to verify their suitability. Special care must be taken with date fields with 2-digit years, as the resulting date may be different to the expected date based on the comparison year for century change within LANSA or IBM threshold year for century change (outside LANSA). For example year 01 may result in year 2001 instead of 1901. The timestamp default value is provided by the system variable *TIMESTAMP_DFT which returns a value of 0001-01-01-00.00.00.000000.

• If date fields are used, it is strongly recommended that date formats which include the century be used. If that is not possible, then the LANSA's year for century change and the operating system's year for century change definitions must be consistent to prevent unpredictable results during date comparisons or validations. It must be noted that when a date field using a 2-digit year format (For example date format *JUL) is used in a key list, the sorting sequence is determined by the operating system (For example Julian date 40/001 is January 1st, 1940 and 39/365 is December 31st, 2039).

• Default values are only assigned when equivalent fields are not found during the load of the OTHER file. It is the developer's responsibility to ensure that existing fields have default values which are valid date, time or timestamp values in the correct format.

• LANSA will handle these fields as alphanumeric fields with the only difference being that the I/O modules (or I/O module routines in *DBOPTIMIZE or *DBOPTIMIZE_BATCH functions) will validate that these fields contain valid date, time or timestamp values, before attempting to add or update records to the OTHER file. The developer must provide the logic (using existing LANSA features for handling dates, such as Built-In Functions) to operate these fields.