Effect of ADD on Areas
ADD copies the area description from the schema description into the subschema description.
Effect of DELETE on Areas
DELETE removes the area from the current subschema description in the dictionary; the area remains associated with the schema.
AREA Statement Determines How Programs Can Ready the Area
ADD and MODIFY AREA operations can restrict the ready modes in which programs using the current subschema can ready the area, and can specify a default ready mode in which the area will be readied for programs using the current subschema.
The UPDATE (RETRIEVAL) IS ALLOWED clause can be repeated for as many different ready modes as required.
Specify Default Ready Mode for All Subschema Areas or use the FORCE Option
If a program issues an explicit READY for one area, it must issue an explicit READY for all areas to be accessed unless the areas use the default usage mode with the FORCE option. The automatic READY mechanism is turned off as soon as one area is readied explicitly by a program and then only areas using the default usage option FORCE are automatically readied.
Considerations for Using the FORCE Option with ADS Dialogs
The FORCE option is provided to allow application changes to be deferred when a record in an index set is moved to a different area. This type of change might be done to implement a Mixed Page Group Index Set. When the FORCE option is used on an AREA referenced by ADS dialogs having extended run units, those dialogs must be modified in some manner, as indicated in the scenarios and workarounds outlined below.
Three types of issues can occur with respect to the use of the FORCE option with areas that ADS dialogs access using an extended run unit:
Most ADS dialogs READY all areas for RETRIEVAL, therefore the default usage modes are often defined as RETRIEVAL. However, UPDATE dialogs require one or more areas to be readied for UPDATE. In cases where a new area is defined using the FORCE option and the subschema is referenced in one or more UPDATE dialogs, the RETRIEVAL/UPDATE clause for the new area must be set to UPDATE to allow updating the index set. Applying this setting changes all RETRIEVAL dialogs which reference that subschema area to UPDATE, which can cause degradation in performance, or in some cases may cause deadlocks to occur due to increased locking.
Workaround
Identify the dialogs that UPDATE the index (there should not be too many). Change the UPDATE dialogs by one of the two following methods:
This workaround only functions if the run units are not extended.
This issue can occur in situations such as this example:
An update dialog readies one area for UPDATE and another for RETRIEVAL. This dialog then LINKs to a dialog that does not ready the second area, but also readies the first area for UPDATE to allow updates to an indexed set that the upper-level dialog does not use. For efficiency, ADS keeps the run unit open through both dialogs. If one record of the indexed set is moved from the UPDATE area to the RETRIEVAL area, the lower-level dialog needs UPDATE access to the new area.
As the run unit is rebound only when the dialogs are recompiled, the second run unit does not have UPDATE access to the second area. ERROR-STATUS abends such as 0801 and 1209 can occur.
Workaround
Change the subschema to ready its second area for UPDATE using the FORCE option. Be aware that doing so can cause the locking problems described in the preceding issue.
Note: Using a tailored subschema for the lower-level dialog is not an option because the run unit would no longer be extended.
When two dialogs use the same subschema with extendable attributes, the run unit is extended if one dialog LINKs to the other. When an indexed set is modified to span page groups, then neither of these dialogs is able to access the new area unless the dialogs are recompiled or the subschema is modified to FORCE a READY for the new area.
Problems can occur in the situation when a subschema is changed to add a new area using the FORCE and UPDATE options. When a lower-level dialog in an extended run unit is recompiled, its RAT (READY AREA TABLE) is changed to access the new area and the run unit from the higher-level dialog will no longer be extended. In normal situations, the dialog performs as before, except that multiple run units are bound and finished during each execution of the transaction. If an abend occurs, only part of the transaction is rolled back because multiple run units were bound.
Workaround
Recompile all dialogs in the run unit thread if the FORCE option is used on an AREA referenced by ADS dialogs having extended run units.
|
Copyright © 2014 CA.
All rights reserved.
|
|