In a DR exercise, the customer has two View databases.
One of the databases stopped working, and when a user tries to make access, they get locked up.
Release : 14.0
Component : Deliver
Per the documentation submittals by the client, here were the findings:
. When preparing for their DR test, the client did NOT bring down their View or Deliver tasks before taking the snapshot of their production environment.
Note: Before any SARDBASE UNLOAD or any extract of a View database, the View tasks (SARSTC, SARFSS, and any related on-line tasks) need to be brought down, including any Deliver tasks that do a ARCHn=DIRECT write, as there is constant database updating taking place when the tasks are active.
. According to the DR View database data extract of the first 50 records (IDCAMS), the amount of available blocks in the header was negative, which under normal
circimstances should never happen.
. Some blocks showed to have unusual values, indicating that there were more free blocks available on a cylinder than were contained in the cylinder.
. If the DR environment were still active, it would have been asked that the client run SARDBASE VERIFY on the database, to reset the data pointers.
. When the client goes to do their next DR exercise, they will run a SARDBASE VERIFY on their View database prior to starting the tasks.