APAR PK23557 added functionality to the Content Manager OnDemand for z/OS™ and OS/390® V7.1 (OD V7) product to provide simulation of Large Object support when viewing documents that were loaded into Content Manager OnDemand for OS/390 V2.1 (OD V2) for which indexes have been migrated to OnDemand V7. If the index migration program, ARSZIMIG, is run a second time for the same input without removing all residual data from the OnDemand V7 tables, then problems can occur resulting in the Large Object support performing incorrectly.
The index migration program, ARSZIMIG, migrates index values from OnDemand V2 to OnDemand V7. This program issues SQL Commits at various points. If an error occurs and some of the rows inserted to the ARSOD table get rolled back, then these rows may not get recreated when the program is rerun.
Scenario 1: Incorrect document name values in the Application Group Data Tables
The ARSZIMIG program is used to extract index values from the OnDemand V2 repositories (Directory Tables and Archived Index Objects). It creates two outputs.
- ARSOD (Object Directory) table rows: The ARSOD table contains a row for each object that holds OnDemand V2 report data. For example, if an OnDemand V2 report occurrence used 10 OAM Objects to hold all of the documents contained in that report occurrence, then ARSZIMIG would insert 10 rows into the ARSOD table, one for each OAM Object. There could be multiple index rows which point to each ARSOD row. The ARSOD table is indexed by the OnDemand V7 document name construct and contains other information such as the OnDemand V2 Report Id, Version, Object Name, Collection Name, and Compression Type.
- Generic Indexer Load File: Each OnDemand V2 Directory Table row results in multiple records being added to this Generic Indexer Load File. These records include the index name and value as well as the document name. The document name and index values are inserted into the OnDemand V7 Application Group Data Tables (the equivalent of the OD V2 Directory Tables) through the ARSLOAD job. The document name column of this table is used to select the corresponding ARSOD row, so the OAM object can be retrieved at view time.
When Large Object support is to be used at view time, a dollar sign ($) is added to the end of the document name. The presence of this dollar sign tells all OnDemand V7 components that Large Object support will be used to view the document.
A problem exists in the ARSZIMIG program logic such that if the program is run a second time for the same input, the dollar sign is not added to all document names in the Generic Indexer Load File. The ARSOD rows do have the dollar sign in all corresponding document names. For those document names missing the dollar sign in the Generic Indexer Load File, the result is that the client does not treat the viewing of the document as using the Large Object support. However, the component of OnDemand V7 that retrieves the document from OAM sees the dollar sign in the ARSOD doc name, so it does two things:
- A Large Object Header is created and placed at the beginning of the storage area holding the document. The client is not expecting a Large Object Header, so it treats this as data, displaying it as garbage on page one of the document.
- Only the first segment of the Large Object is returned to the client for viewing. There is no way to scroll beyond the end of the first segment to get to the second segment.
Also, the Index Object created in the ARSODIND table does not include the dollar sign in all document names. This causes problems with two functions:
- The arsdoc get -X command generates invalid output. It generates the report output, but the documents represented by document names missing the dollar sign appear as garbage.
- The Full Report Browse function of the Windows Client generates invalid output. The viewing of the portion of the output represented by document names missing the dollar sign appear as garbage.
Scenario 2: Rows Missing From The ARSOD Table
The ARSZIMIG program accepts as input through the ARSPARM DD statement an optional COMMIT parameter. This value determines how often the program issues an SQL COMMIT. If no value is specified, a default of 100 is used. The program counts the number of times the ARSOD table is accessed and issues a COMMIT when the commit value is reached. It also issues a commit when completing the index migration of each report occurrence.
If the ARSZIMIG program has issued a commit during the processing of a report occurrence, before generating all output for that report occurrence, and then experiences an abend for some reason, this can result in a rollback of some of the ARSOD rows. Some ARSOD rows may have been committed for that report occurrence, but some could have been rolled back.
When rerunning ARSZIMIG without first removing all residual data, the result can be that the missing ARSOD rows are never replaced. This causes an error at view time for those documents represented by the missing ARSOD rows. The document cannot be retrieved for viewing.
Problem Determination for Scenarios 1 and 2:
APAR PK31395, in addition to resolving these two problems with changes to the ARSZIMIG program, includes a new program called ARSZODV2. This program can be run to analyze the Application Group Data Tables and the ARSOD table to determine if problems exist for indexes already migrated from OnDemand V2 to OnDemand V7.
The ARSZODV2 program looks at each unique document name across Application Group Data Tables which are associated with nodes defined for migrated indexes. The ARSOD table is queried for each of these document names to determine if a row exists.
An optional input DD provides a way to limit the work done by the program to a specified set of Application Group Names. If this DD is not present, then all Application Group Names will be analyzed.
Four reports are generated from this analysis. Each is written to a separate output DD by this batch job.
|MISSOD report||Entries in this report represent document names from the Application Group Data Table for which no row exists in the ARSOD table|
|MISMATCH report||Entries in this report represent document names that do not match between the Application Group Data Table and the ARSOD table. The document name in one table has a dollar sign on the end, but the value in the other does not.|
|MISSLID report||Entries in this report represent rows from the ARSOD table where the load ID column is blank.|
|ALLGOOD report||Entries in this report represent data that has been found to be correct.|
Install APAR PK31395 to correct the problems with ARSZIMIG for future index migrations. See the attached document “PK31395 Problem Determination Installation and Execution” for details on the ARSZODV2 program.
For index migrations identified in the MISSOD, MISMATCH and MISSLID reports described above:
- Perform an arsadmin unload for the load IDs identified.
For report entries that do not include a load ID, the load ID can be constructed as follows:
For example, the MISSOD report may show
ARSZODV2 ONDEMAND ARSOD / AG DATA TABLE COMPARISON - MISSING ARSOD REPORT 2006-09-28
AGID DOC NAME ARSOD DOC NAME INDEX PRIMARY NID AGID NAME LOAD ID
---------- -------------- -------------- ----------- --------- -------------------------
5049 1FACA 7 OAA
5052 1FADA 7 PAA
The load ID for the first row would be:
The document name used in the load ID consists of the numeric and just the first three alphas.
The start and end dates can be set to zero for purposes of running an ARSADMIN UNLOAD.
- Ensure all rows from the ARSOD table are removed for the document names identified.
For a given document name, run a query such as
SELECT * FROM hlq.ARSOD WHERE DOC_NAME IN (‘1FACA’, ‘1FACA$’)
Include the entire document name from the report as one entry in the IN values. Add a dollar sign (x’5B’) on the end of the document name for the other entry.
If any rows are found, remove them, for example:
DELETE FROM hlq.ARSOD WHERE DOC_NAME = ‘1FACA’
DELETE FROM hlq.ARSOD WHERE DOC_NAME = ‘1FACA$’
- Rerun ARSZIMIG and ARSLOAD for the reports identified.