ODMA Incident Report

X000009: Incorrect ODMOpenDoc ODM_REFCOPY Flag

Last updated 2001-03-06-08:24 -0800 (pst)
The latest version of this information is available on the AIIM DMware ODMA site.
Category: Functionality - Critical Incident ID: X000009
Priority: 9 - Urgent Status: Correction Pending
Component: Odma.h 2.0.0
Repaired in: tbd
 Related information:
ODMA 2.0 Specification section 2.13, ODMOpenDoc definition of ODM_REFCOPY,
ODMA 1.5 Specification definition of ODMOpenDoc,
Q000705: Changes Between ODMA Versions,
P000702: ODMA Library Release 2.0.1 project
Assigned To: tbd
Reported By:
Paul O'Sullivan (1999-11-03)
Bob St. Jean (1999-11-03)
Date Logged: 2000-08-11
Date Recorded: 2001-03-06		 Date Closed: none

Content

1. Incident Summary

2. Actions Toward Resolution

3. Working Around the Problem

4. Analysis

Contributors

1. Incident Summary (2001-03-06)

In the original ODMA 2.0 Library header file Odma.h, the value for ODMOpenDoc flag ODM_REFCOPY is incorrectly defined.

The value, introduced in ODMA 2.0, is the same as if 

ODM_VIEWMODE | ODM_MODIFYMODE 

were specified for the value of  the ODMOpenDoc flags parameter.  Consequently, a correct use of ODM_REFCOPY will be rejected for error ODM_E_INVARG by all versions of ODMA DMS integrations, whether for ODMA 2.0 or for earlier versions of ODMA.

Why is this considered critical?

The incorrectly-defined value makes it impossible to ever successfully test the ODM_REFCOPY case with an ODMA-aware application or a properly operating ODMA 2.0-compliant DMS integration.  Consequently, production installations should never encounter the problem this defect causes.

The problem is considered critical because there is a risk of independently-introduced repairs that damage the interoperability of ODMA implementations.  In addition, ODM_REFCOPY functionality is not successfully deliverable until this situation is remedied. 

2. Actions Toward Resolution (2001-03-06)

The following actions are proposed:

  1. Record the existence of of the problem and establish an incident report as notification and as documentation of the repair that is needed.  [2001-03-06: Completed]
  2. Open a project for developing a maintenance and functionality release 2.0.1 of the ODMA 2.0 Libraries.  That release will remedy several defects in the current library header files.  This will be project P000702.
  3. Present a workaround for this specific problem. 
  4. Look at what it would take to have Connection Manager trace logging provide detailed flag and result code reporting.
  5. Close this incident report when (1-5) are complete and it is clear that proper handling of flags for ODMOpenDoc is fully confirmed.

3. Working Around the Problem

4. Analysis of Incident (2001-03-06):

The value of 3 is incorrect.  The correct value is 4.  That will always be the correct value.

This situation will be experienced only by an ODMA-aware application that requires an ODMA 2.0 DMS integration in order to operate, and that requests an ODM_REFCOPY.  this request will always fail if the original header files are used.  In addition, no ODMA 2.0 DMS integration constructed with those header files will be able to perform a valid ODM_REFCOPY case of ODMOpenDoc.  An ODM_E_INVARG response should always occur instead.

Contributors

Dennis Hamilton
reviewed old ODMA Tech mail for untracked incidents, logged this incident (2000-08-11) and then recorded the incident (2001-03-06) as part of having all backlog recorded.
Paul O'Sullivan
reported the original incident.
Bob St. Jean
confirmed the error and specified the correction.

created 2001-03-06-08:24 -0800 (pst) by orcmid
$$Author: Orcmid $
$$Date: 01-03-06 13:20 $
$$Revision: 3 $