This section describes the Adabas Vista partition outage feature.
Note:
Earlier versions of Adabas Vista referred to the partition outage
feature as partial data operation (PDO). This method of specifying this feature
is no longer supported.
The partition outage feature can be used to manage planned outages for a partitioned file.
Using this feature, tolerance levels can be defined which control the action to be taken when a partition becomes unavailable. Application access to the partitioned file can be maintained transparently even though all the partitions of the file may not be available. Data is returned from the available partitions.
Sensitivity to partition outage can be set unilaterally or overridden on a user basis by an application. This provides flexible control over what happens when a partition becomes unavailable.
The suitability of this feature should be assessed for each partitioned file. For suitable files, using this feature:
maximizes Adabas Vista file availability (24 * 7);
maintains partitions transparently; and
recovers partitions transparently.
Partition unavailability is determined by the following Adabas response codes:
| Response Code | Description |
|---|---|
| 17 | partition locked |
| 48 | partition locked by an Adabas utility |
| 148 | database not active |
The partition parameter
Critical
is used to specify the outage tolerance level for a paritition.
As an example, assume that a file is partitioned by country.
Using partition outage, it will be possible to take only the UK partition offline. Access may continue as required for the other countries, but UK data is unavailable until returned online.
In that users in the UK work predominantly on UK data, partition outage can be set so that only UK data is critical to UK users. UK users tend not to use or need data from the other countries.
Consequently, UK users are unaffected by USA outages. However, UK outages do interrupt UK users because their critical data is affected. Similar arrangements can be made for the users in other countries.
Adabas Vista API function PARTOPTS can also be used to to update or extract a user's current Critical parameter setting for a specific partition. The API function CRITREP can be used to list those partitions that are not currently available.
Since Adabas Vista partitions are actually independent Adabas files, it is possible to maintain them individually.
Independent partition maintenance can be used to size, order, and restore according to the needs of the individual partition. It is not necessary that all partitions adhere to the same physical constraints.The Adabas Associator space required by the partition can be individually fine tuned as well.
Separating partitions into independent Adabas files also allows you to perform parallel maintenance.
Note:
Earlier versions of Adabas Vista referred to this feature as
restricted segment option (RSO).
The partition restriction feature provides access control for each partition of a partitioned file. Partition restriction can either be implemented for all of the partition users or it can be defined so that certain applications are permitted to override the restriction at runtime.
Partition restriction:
dynamically restricts user views of partitioned files,
provides access based on user role controlled by the application,
maximizes focused access.
This feature therefore provides the following benefits:
Security: the availability of data can be restricted to authorized users
Performance: the amount of focused access can be increased by limiting the number of partitions available to each user based upon role, location, or other criteria.
The type of access to a partition (none, read-only, read/write, or
single partition) is specified using the parameter
Access.
Adabas Vista partitions do not have to be identical. Provided all the partitions support all of the views to be used by Adabas Vista, the files can operate with different physical layouts (FDTs). Of course, the Adabas source fields that are common to all partitions must be defined identically in each FDT.
For example, if an organization combines with a similar trading company, it is likely that the two companies hold similar data. In this case, a new file for another country could be added to the partitioned definition.
The partition sharing (multipart) feature can be used to define multiple partitions of the same partitioned file in order to share the same Adabas file while preserving the collating sequence of the single file image. In this way, specific portions of a file can be split away from the main file with minimal data manipulation.
This feature is activated using the parameter
Shared
Partition.
The distributed lock mode feature provides greater control of record hold logic in a partitioned environment.
When multiple partitions are targeted for distributed access and hold processing is involved, it is possible for successive accesses within the same process to be satisfied from the same partition. However, the other partitions still have another record within the same process on hold because that record is taking part in collating-sequence checking to ensure that the user receives the data in the correct sequence across partitions. If as a result, records are held for longer periods than expected, the frequency of the following response codes may increase:
response code 145 because of record contention; and
response code 9, subcode 2 because of Adabas transaction timeout
(TT) expiration.
The GET statement should be used to hold
records immediately before modification. This minimizes hold queue sizes and
contention. This is even more relevant when using partitioned files.
If this recommendation cannot be followed, it may be useful to adjust
the job parameter Distributed Lock
Mode.
A clustered application uses multiple jobs in unison to provide a single (clustered) service. CICS in MRO or plex mode, IMS/TM, and UTM are examples of such clustered applications.
Clustered applications can route transactions dynamically from one job (member) in the application cluster to another, usually for load-balancing purposes. Dynamic transaction routing can occur within an operating system image, or across operating system images that are members of an IBM sysplex cluster.
The Adabas System Coordinator provides Adabas Vista support for dynamic transaction routing within and across operating system images.
See section Using Cluster Services for more information.
