Enhancements to Existing Features › Allow RLA Access over DDL Database

Allow RLA Access over DDL Database

DDL Implementation

When you want to convert the existing DDS database to DDL database and you continue to use RLA functions that were built using DDS database without regenerating and recompiling them, you have the option to use the generation mode. You have an option to set the generation mode of access paths as:

L(L-DDL) or M(M-MDLVAL with model value YDBFGEN set as *DDL)

Note:

• Irrespective of the value of the YSQLFMT model value and if the generation mode is *DDL, the RCDFMT keyword is generated.
• The current implementation of *DDL supports only *TABLE as data access method.
• When you generate the SQL/DDL with certain column names, they fail to generate and throw error messages. However, using the same field names for the DDS implementation result in successful generation.

  Example: If you have a field starting with a number such as “2nd_Order”, the SQL/DDL fails to generate a table with such column name with the following error:

  “SQL0103 - Numeric constant 2nd_Order not valid.” 
  

  However, the DDS implementation with the same field name is successfully generated.

Limitations:

• Due to an IBM limitation, date field in *ISO format (DT#) is converted to date format of job, when DDS database containing this date field is converted to DDL database.

  Therefore, a decimal data error occurs when RLA function is executed after converting the database from DDS to DDL.

  Note: To resolve this issue, contact IBM for the following PTFs:

  • SI51190 for V7R1
  • SI51290 for V6R1
• The current implementation of the DDL generation mode is not valid for the following cases:
  • Access paths that have virtual fields
  • SPN access path
  • QRY access path
  • Multi-member files

  Workaround for Virtual Fields, SPN, and QRY Access Paths: If the earlier generation mode is *DDS, revert to it and regenerate the access path. You need not regenerate the functions that use this access path. If you want to have an SQL type database, regenerate the access path using *SQL generation mode. The functions using this access path must be regenerated.

  Workaround for Multi-Member Files: If you want to have more than one member for the access paths, revert to *DDS generation mode.

  Note: If you want to change an access path, which is previously defined as *DDS with a MAXMBR compiler override, to *DDL, you must revert to *DDS generation mode and must remove the compiler override, and then change back to *DDL generation mode.

• When you attempt to compile/generate a *DDL based access path which has any of the above limitation scenarios, the source is not generated. Also, the corresponding entry is not added to the Job List.

The following documentation deliverables were updated for this feature:

• Administration Guide
• Building Access Paths Guide
• Building Applications Guide
• Command Reference Guide
• Generating and Implementing Applications Guide
• Implementation Guide
• Release Notes
• Tutorial Guide