3.12.2 Detailed Logical View Maintenance

This screen is displayed when:


 DC@P200602                XXXXXX Logical View                         




 Logical view name             : __________                            

 Description of logical view   : _________________________________

 Access path maintenance option: IMMED Unique? NO  Dynamic select? NO  

 Key field details :                                                   

      Field       Description                              A/D  S/U/A  





 Select/Omit criteria :                                                

   AND/OR    SELECT/OMIT       Field       Operation(s)                

               ______          __________  _________________________

               ______          __________  _________________________

               ______          __________  _________________________

               ______          __________  _________________________

               ______          __________  _________________________  


 Fnn=Help  Fnn=Exit  Fnn=Cancel  Fnn=Messages                          




Working from this screen you can:

Input Options

These input options apply when creating a new logical view in a file definition:

Logical View Name

Specifies the name that is to be assigned to the logical view/ file. Logical file names must be unique. No other physical or logical file can exist in the same library with the same name.

This name was once restricted to a maximum length of 8 characters but can now be 9 or 10 characters long. It is strongly recommended that 9 and 10 character file names be unique in their first 8 characters. This retains uniqueness in the formation of the $$ file name used in making the file operational and importing.

Note that no library name is required. LANSA will always create the logical file in the same library as the associated physical file. This is the library that was specified when the file definition was first created.

A naming standard that is frequently adopted requires the logical file name to contain or relate to the associated physical file name. This is to prevent confusion amongst users when they are accessing the physical or logical files.

For instance, the physical file (and LANSA file definition) of a customer master file might be named CUSMST. The associated logical views might be called:


Customers ordered by customer name


Customers ordered by post code


Customers ordered by state

Description of Logical View

Specifies a description that is to be associated with the logical view/file. This field is an identification aid to any user of the file. Wherever possible include information in the description that specifies what the logical view/file should be used for. e.g. "Customer master ordered by post code" or "Orders by customer number, order number"

Access Path Maintenance Option

Specifies what method is to be used to maintain the "access path" associated with this logical view/file. When a logical view is created to arrange the information in a file into a specific order the system creates an "access path".

The access path is essentially the logical file "key fields" arranged in a special structure that allows:

An access path exists for every logical view/file created. Every time a record in the file is added, deleted or updated the operating system must update all the access paths to this file. To do this it must use up part of the computer's time and available processing cycles. This of course degrades the performance of the system. The more access paths that are being maintained, the slower the system will run.

This field allows the type of access path maintenance to be used to be manually specified. Allowable values are:


The access path should be maintained immediately (i.e.whenever a record is added, updated or deleted from the file). This option is the most common. If the logical file is to be used in an interactive environment then IMMED should always be used.


The access path should only be maintained when the logical file is used. This type of access path lies dormant and is not maintained by the operating system until such time as someone needs to use the logical file. Thus it places no burden on the operating system until it is actually required. Typically logical views that use this option are only used once a week (say) to "sort" a file into a specific order.


Specifies whether or not the key fields nominated are to form a unique key to the file.

The default value is NO, which indicates that the key fields nominated do not form a unique key to the file. This allows multiple records with the same key to exist in the file.

The only other possible value is YES, which indicates that the key fields are to form a unique key to the file. This means that one (and only one) record can exist in the file for any given key value.

When defining a new logical file over a physical file that already contains records and using the YES option make sure that there are no duplicate records (i.e.key values) already in the file. If duplicate records do exist, then the "make operational" job will fail as this logical view cannot be loaded because of the duplicate records. The job log will indicate the cause of this problem. To correct, remove or Change the duplicate records.

Dynamic Select?

Specifies whether or not any select/omit tests specified on the lower portion of the screen are to be done at execution time.

The default value is NO, which indicates that the dynamic select feature should not be used. In this case the access path associated with the logical file will contain only records that match the select/omit criteria specified.

The only other possible value is YES, which indicates that the dynamic select feature should be used. In this case the access path associated with the logical file will contain all records in the file. The select/omit testing should be done when the program reads the records from the file.

If you specify YES, then do not specify any select/omit tests the value will be automatically changed back to NO.

The dynamic select facility is a feature of the operating system. Using it can have significant overall performance benefits in some situations. For more information about this facility refer to the appropriate IBM supplied manual.

Key Field Details

Specifies the fields that comprise the logical file key and the order that the key information should be stored. Key fields are specified from top to bottom in order of their importance in the key hierarchy (i.e.major to minor). Major keys come first. The net length of the logical file key (which is the sum of the lengths of all fields that comprise the key) cannot exceed 255 bytes (characters).

Although only the first 3 key fields are shown (or can be input) on the display the roll key can be used to review or input additional key field details.


Specifies the name of one of the field(s) in the logical file key. Any fields named as a key must first be defined as a field in the file definition. Fields can be selected by entry as a full or partial name or as a "?", which causes the multiple selection screen to be displayed. If the field name is left blank and the A/D or S/U/A flags are changed this will also cause the multiple selection screen to be displayed. The list will contain all the real fields in the current file definition. A maximum of 20 keys can be specified. Refer to 3.10.1 Select Fields When Working from File Definition Menu for details.


Displays the description of the key field. This is obtained from the LANSA data dictionary.


Specifies whether the associated key is to be stored in ascending or descending sequence (i.e.from lowest to highest or highest to lowest order). Allowable values are:


(Ascending) store in lowest to highest order


(Descending) store in highest to lowest order.

This is an optional field. If not specified, A is assumed.


Specifies, for numeric key fields only, additional details about how the key is to be ordered. Allowable values are:


(Signed) indicates the numeric fields should be stored taking into account their signs (+ or -).


(Unsigned) indicates the numeric field should be stored without taking into account their signs. The numeric field is to be treated just like a character field.


(Absolute value) indicates that the numeric field should be stored by its absolute value. Note that this is not the same (and does not always produce the same order) as the U option.


Character fields are always U (unsigned) fields. If you specify something other than U for a character field it will be automatically changed to U.

This field is optional. If you do not specify it will default to U for character fields and S for numeric fields.

These additional options are supported by the operating system . For more details about them refer to the IBM manual Data Description Specifications. Refer to logical file keywords SIGNED, UNSIGNED and ABSVAL.

Select/Omit Criteria

Specifies any record selection or omission criteria that is to apply to the logical view/file. If a record in the physical file is "omitted" from a logical file then it is effectively "invisible" to any user accessing the file via the logical view.

A record can be omitted for 2 reasons:

Select/omit criteria are a powerful facility but should be used with some caution because the effect of making some records in the physical file "invisible" when accessed via certain logical views can cause confusion amongst some users of the system.

Select/omit criteria are entered as a series of select/omit statements. When both SELECT and OMIT are used the order of the statements is important. The statements are processed in the order specified. If a record matches the criteria of a statement it is selected or omitted as specified and following statements are not tested.

Extensive examples of select / omit criteria follow this section.


This is an output field only. It indicates whether the select/omit statement is ANDed or ORed with this statement.


Indicates whether the condition specified in the operation(s) field is to be used to select or omit records when found to be true. Allowable values are:


Use operation to select records


Use operation to omit records


Form an "and" with previously SELECT/OMIT operation

When using select/omit statements specify SELECT,OMIT or blanks in the SELECT/OMIT column. Using SELECT or OMIT implies an OR relationship with the preceding select/omit statement. Leaving the entry in the SELECT/OMIT column blank implies an AND relationship with the preceding select/omit statement.


Specifies the name of the field that is to be used in conjunction with the operations(s) field to evaluate the select/omit expression. Field named must be defined in the file definition. In addition it can be selected by entry as a full or partial name or as a "?", which will cause the single field select screen to be displayed. The list will contain all the real fields in the current file's definition. Refer to 3.10.1 Select Fields When Working from File Definition Menu for more details.


Specifies the operation that is to be performed against the field nominated in the "field" field. Allowable formats are


Equal to


Not equal to


Less than


Not less than


Greater than


Not greater than


Less than or equal to


Greater than or equal to

     The value specified for <value> can be a character literal in quotes (e.g. 'BALMAIN'), a hexadecimal literal in quotes (e.g. X'F1E6'), a numeric literal (e.g.  1.54) or the name of another field in the file definition.

Where a condition will not fit on one line it can be continued on the next line by entering a "+" sign as the last character on the line. The "+" indicates that the line continues with the first non-blank character on the next line.

A normal example of using continuation lines would be the following which is considered to be one select/omit statement even though it takes 3 lines to enter:

AND/OR   SELECT/OMIT   Field      Operation(s)      

         SELECT___     NAME____   VALUES('ACME & CO' + 

         _________     ________   'SMITH ENGINEERING' +

         _________     ________   'ACME ENGINEERING')__