Page History

[ Image Removed |../../index.htm#lansa/ugub_30006.htm]
You are here:

...

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:

...

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.

...

• .

...