Browse Prior Art Database

Reduce Error Flow by Handling Edit/Add Request in Direct Connect

IP.com Disclosure Number: IPCOM000104961D
Original Publication Date: 1993-Jun-01
Included in the Prior Art Database: 2005-Mar-19
Document File: 2 page(s) / 61K

Publishing Venue

IBM

Related People

Dawson, CA: AUTHOR [+2]

Abstract

Assume a client-server calendar application that uses legacy applications like OfficeVision/VM* and OfficeVision/MVS* for its service and that has a graphical front-end running in OS/2* or DOS Windows**. Also assume the design point for this application requires that some part of the server data is shadowed locally on the client for the end user to work with. This local data enhances performance and permits disconnected user support.

This text was extracted from an ASCII text file.
This is the abbreviated version, containing approximately 52% of the total text.

Reduce Error Flow by Handling Edit/Add Request in Direct Connect

      Assume a client-server calendar application that uses legacy
applications like OfficeVision/VM* and OfficeVision/MVS* for its
service and that has a graphical front-end running in OS/2* or DOS
Windows**.  Also assume the design point for this application
requires that some part of the server data is shadowed locally on the
client for the end user to work with.  This local data enhances
performance and permits disconnected user support.

      Current* with OV/VM workgroup support is a good working model
of this kind of application, and it represents the state-of-the-art
for this kind of direct connect' application.

      All the user's host data cannot be shadowed on the PC.  The
performance and storage implications are obvious.  However, the user
can determine how much data to shadow on the PC.  This is called the
synchronization range.

      The data can be updated from the PC or from the host and, at
regular time intervals, the host data (for the requested sync range)
is downloaded to the PC to compare the two and the updated host
information is modified on the PC.  When an event is modified from
the PC, a request is sent to the host to EDIT that event.

      The problem with the current solution occurs when a EDIT
request is sent to the host and that event has already been modified
on the host (and not yet downloaded to the PC), the user will get an
error message because that event could no longer be found on the
host.

                 PC                 HOST
               -------              -------
               Event A              Event A

       Secretary changes Event A on the host to Event B

               Event A              Event B

       User tries to change Event A to Event C from the PC.  When
       the request to EDIT get to the host, the request fails
    ...