Sharing SQL Access Modules or Catalogs across DBnames
Article ID: 66556
Updated On:
Products
Issue/Introduction
It is possible to share an SQL catalog across multiple DBnames, but this can pose problems unless the DBnames contain the same dictionary segment as well.
Environment
IDMS - All Supported Releases
Cause
The potential for run-time problems is introduced in this situation because of timestamps.
Resolution
When SQL is coded in a program or dialog, a Relational Command Module (RCM) is created; each RCM must then be included in an Access Module (AM) which contains the optimized path for the SQL statements. However, the RCM is stored in the dictionary load area (DDLDCLOD) while the AM is stored in the catalog load area (DDLCATLOD). At run-time we will try to verify the timestamps in the AM against those in the RCM. If two DBnames contain the same catalog segment but different dictionary segments, then the AM will always contain the timestamps from the RCM in the DBname where it was last recompiled. At run-time, when the application is run from that DBname it will run with no problem. However, if it is run against the other DBname, the AM will be compared against timestamps from a different DDLDCLOD area, which will result in a 1012 run-time error. The DB001012 message says the compile stamps in the SQLPIB and applications access module RCM do not match.
When one SQL is shared across two DBnames, then you have these options to avoid the DB001012 timestamp errors in comparisons against the RCM:
1- Use the same dictionary segment in both DBnames, so that the catalog and dictionary segments are always kept in sync; or
2- If you have to have a different dictionary in each DBname, then use different dialog / program names (& RCM names) in each DBname, so the timestamps can be kept in sync.
Feedback
