|
(SR# 5003-367607)
This article is only for customers using the TurboIMAGE/XL feature Dynamic Detail Dataset Expansion (DDX).
The DDX feature of TurboIMAGE/XL has a known problem which may cause you to lose some of your new data entries added following the dynamic detail dataset expansion. This defect has been in the feature since its introduction, but has surfaced recently and has been reported by a few customers. The problem has been fixed both for MPE/iX 5.0 and MPE/iX 5.5, and the patch information is as follows:
MPE/iX Patch ID TurboIMAGE/XL
Release Version
5.0 TIXKX11 C.06.23
5.5 TIXKX13 C.07.07
These patches are not contained in this release. Contact your HP Response Center to obtain the correct patch. If you want to know more about the problem and ascertain if you may be susceptible to it, continue reading.
Problem description
The problem is that, following a dynamic expansion, the addition
of the new data entries (DBPUTs), which exceed the INCREMENT in number,
are written to the data set beyond the physical end-of-file
(MPE EOF). When the database is closed and reopened, those
new entries exceeding the INCREMENT are inaccessible.
If a program attempts to read that data or add more data entries
in that area, it gets an error -212, "Database is Corrupt."
The diagram below illustrates the problem.
| |
| |
| |
| |
| |
|----------| -------- > Old MPE EOF as well as IMAGE EOF (1)
| |
|INCREMENT |
|----------| -------- > New MPE EOF (51) after expansion by INCREMENT
| | equivalent to 50 MPE records.
| | -------- > New entries placed from this point on are lost.
| |
|----------| -------- > New IMAGE EOF (101) as calculated by the adjustment
to CAPACITY of set, following the expansion.
The real problem is that, for certain expansions, the new
CAPACITY is inadvertently adjusted by adding the INCREMENT
more than once instead of adjusting only once. This results in
incorrect calculation of IMAGE EOF and subsequently allows new data
entries to be placed in the area which really does not belong to the
data set file. Therefore, when the data set is closed, the new entries
added beyond the MPE EOF are not retained as part of the data set
file by the MPE file system and are subsequently lost.
The circumstances in which such an erroneous adjustment could take place are as follows:
- While an actual DDX is being performed by DBPUT for one process,
a second process (user) accessing the same data set for the
first time causes execution of IMAGE's "open data set" module.
In a narrow timing window, the result will be incorrect extraneous adjustment of the CAPACITY by adding the INCREMENT! Specifically, the CAPACITY has been
incremented twice, while the MPE EOF has been correctly
incremented--only once.
How to tell if you already have this problem
If you use DDX, check each detail data set enabled for DDX. Remember,
the problem is associated only with the detail data sets which have
undergone dynamic expansion.
You can check for this condition as follows:
- Use the FORM SETS command of QUERY, which gives the Current Capacity (CC) and Blocking Factor (BF) of each data set.
:query
HP32216D.03.11 QUERY/3000 TUE, NOV 4, 1997, 3:20 PM
COPYRIGHT HEWLETT-PACKARD CO. 1976
>b=dbusa
PASSWORD = >>
MODE = >>1
>form sets
DATA BASE: DBUSA TUE, NOV 4, 1997, 3:20 PM
DATA BASE LANGUAGE ATTRIBUTE: NATIVE-3000
ITEM CURRENT ENTRY ENTRY BLOCKING
SETS: TYPE COUNT CAPACITY COUNT LENGTH FACTOR
PEPU01 D 3 1010 11 12 10
- Calculate the IMAGE EOF of a DDX data set using the following formula:
(CC + (BF-1))/BF
For example:
IMAGE EOF = (1010 + (10-1))/10 = 101
- Verify this calculated EOF with the MPE EOF given by the
command :LISTF dbnamenn,2 where dbnamenn is the
file name of that DDX data set.
:listf dbusa02,2
ACCOUNT= TESTACCT GROUP= DDX
FILENAME CODE ------------LOGICAL RECORD---------- ----SPACE----
SIZE TYP EOF LIMIT R/B SECTORS #X MX
DBUSA02 PRIV 256W FB 51 200 1 112 2 4
- If the two EOFs do not match, there is a problem.
In the example, MPE EOF of 51 and IMAGE EOF of 101 do not match--the problem
exists.
The SHOW DBUSA CAPACITY command of DBUTIL gives capacity parms:
No. of %Max ------- Capacity ------------ Dyn
Data Set Name Type Entries Cap Max Current Initial Increment Exp
PEPU01 D 11 1 2000 1010 10 500 YES
Based on the above formula for calculating MPE records,
the initial capacity was 1 MPE record
( (10+9)/10), and the increment was 50 MPE records ( (500+9)/10).
The correct physical EOF should be 51 (1+50). However,
IMAGE EOF as shown by QUERY is 101 (1+50+50). This establishes that the IMAGE EOF was adjusted twice.
If you use one of the IMAGE/SQL structure maintenance tools (such as Adager, DBCPLUS, or DBGENERAL), it may have the capability to locate instances of this problem, and if you discover that
one of your data sets is so afflicted, it may be possible to correct
the problem using the same tool. (See the documentation for your tool.)
How to avoid experiencing this problem on your IMAGE database
The simplest answer is to install and use one of the TurboIMAGE/XL
beta patches mentioned above. This is the option that HP recommends.
However, if you are unable to acquire and install the patch immediately, consider the following alternative:
- Until you install the patch, avoid opening a data set
from one process while another is expanding it!
Here are some ways you might accomplish this; each way is independent of the others:
- Preallocate and pre-expand DDX data sets which are nearly-full
by adding, in exclusive mode, many new dummy entries. Add more than your actual processing will add. Then delete
them before your real processing begins.
- Open all DDX-enabled data sets needed from each process which accesses them
before allowing any process to add data to any of these sets.
- Access the database exclusively, if possible, until the expansion
has completed.
- Disable DDX on any nearly-full data set, using an HP or
third-party tool.
Page last updated on Mon Dec 22 1997
|
Printable version
