Logical Record Facility › Introduction

Introduction

The Logical Record Facility (LRF) is a runtime facility that allows application programmers to access CA IDMS data without having to know the physical structure of the database. Under LRF, programmers do not have to use database navigation statements to access information. This is because the DBA predefines database access logic that is typically coded by programmers. The following steps take place when you generate a table through ASF with LRF:

1. Record and element definitions are added to the data dictionary (stored tables only):
   • Records are named RFUR-nnnnnn-DATA, where nnnnnn is the table definition number.
   • Element names are the STORED COLUMN NAME shown on the Extended Column Definition screen.
2. Record and set descriptions are added to the IDMS/R schema (stored tables only). The following descriptions are added (nnnnnn is the table definition number):
   • RFUR-nnnnnn-DATA record—The record type in which rows of the table are stored as record occurrences.
   • RFUR-nnnnnn-OOAK record—An IDMS/R-defined OOAK record.
   • RFUS-nnnnnn-SET set—An unsorted indexed set defined if the storage sequence of the table is NEXT, PRIOR, FIRST, or LAST.
   • RFPS-nnnnnn-SET set—An indexed set defined if the storage sequence of the table is designated by the key number of an index key.
   • RFFS-nnnnnn-yyyy set—One for each fast access key defined on the Extended Key Definition screen. The variable yyyy is the field definition number for the column, which is assigned in the FDEFREC.
   • RFKS-nnnnnn-zzzz set—One for each additional key defined on the Extended Key Definition screen that is not used as the storage sequence. The variable zzzz is the key number of the additional key.
3. A subschema is generated, which consists of:
   • A logical record that contains the following elements:
     • ASF-RDEF-REC— The table definition record
     • RFUR-nnnnnn-OOAK—The system-defined OOAK record
     • RFUR-nnnnnn-DATA—The record used to store rows of the table
     • RFUR-nnnnnn-WORK—An IDD work record, which is included if any work fields are defined for the table

     ASF names the logical record by modifying the table name to conform to COBOL naming conventions.

   • Logical-record paths, which allow an application program to access occurrences of the logical record:
     • For a stored table, ASF generates an OBTAIN, STORE, MODIFY, and ERASE path by default.
     • For a table definition (an ASF view), ASF generates an OBTAIN and MODIFY path only.
4. A map is created. The columns defined for the table become the data fields for the map. The map is named RMnnnnnn (nnnnnn is the table definition number).
5. A dialog that uses the subschema and map is generated to allow online access of the table through ASF. The dialog is named RDnnnnnn (nnnnnn is the table definition number). In addition to the subschema (RUnnnnnn) and map (RMnnnnnn), the dialog has the following components:
   • ASF-PARM-REC— A parameter record included in every ASF-generated dialog
   • Process modules, as follows:
     • RDnnnnnn-PREMAP—Premap process, which prepares the map for display
     • RDnnnnnn-CLEAR—Response process for the CLEAR key, which exits from the ASF screen
     • RDnnnnnn-ENTER—Response process for the ENTER key, which is used to retrieve the next table row
     • RDnnnnnn-PA1—Response process for the PA1 key, which exits from ASF
     • RDnnnnnn-PF1—Response process for [PF1], which stores a table row
     • RDnnnnnn-PF2—Response process for [PF2], which modifies a table row
     • RDnnnnnn-PF3—Response process for [PF3], which erases a table row

Note: For more information on table generation through ASF, see the chapter "Creating and Using Stored Tables".

You can extend the capabilities of ASF by tailoring the subschemas it generates. You do this by using the subschema compiler to change the ASF-generated paths. The following considerations apply:

• If you want to continue to access the subschema through ASF, you cannot change the way the RFUR-nnnnnn-DATA records are accessed. You should leave intact the logic that uses the ASF-RDEF-OWN, ASF-RDEF-REC, RFUR-nnnnnn-OOAK, and RFUR-nnnnnn-DATA records.
• If you ever regenerate the table in ASF, your changes will not be reflected in the new table.
• If you use the subschema compiler to add fields (such as work fields) to an ASF-generated table, the fields won't be recognized by the IDB catalog. Therefore, it is best to add the fields through ASF and then modify them, as appropriate.
• If tables generated through ASF are placed in extent areas, the application that uses the subschema must ready the areas in a shared usage mode. This is done through the READY ALL statement.

Note: Be aware that when you change an ASF-generated subschema, you may also have to change the associated map and dialogs.

In the examples shown below, modifications are enclosed in a box.