Browse Prior Art Database

Application Programs Data Supplier Facility

IP.com Disclosure Number: IPCOM000121058D
Original Publication Date: 1991-Jul-01
Included in the Prior Art Database: 2005-Apr-03
Document File: 4 page(s) / 188K

Publishing Venue

IBM

Related People

Joshi, SR: AUTHOR

Abstract

In today's ever changing world of data management, the needs of business are constantly pushing for better data storage and, ultimately, savings in storage space if possible. A more versatile, simple and maintainable solution to problems is always the path to tread on. As newer and newer systems are developed, each one has access to its own data of course. However, a need always arises when application program B will need to look at application program A's data on a read- only basis. As an example, application A can be a Personnel Data Management System that owns its data, a financial tracking system could be application program B and an acccounting system C is another application program.

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

Application Programs Data Supplier Facility

      In today's ever changing world of data management, the
needs of business are constantly pushing for better data storage and,
ultimately, savings in storage space if possible.  A more versatile,
simple and maintainable solution to problems is always the path to
tread on.  As newer and newer systems are developed, each one has
access to its own data of course.  However, a need always arises when
application program B will need to look at application program A's
data on a read- only basis.  As an example, application A can be a
Personnel Data Management System that owns its data, a financial
tracking system could be application program B and an acccounting
system C is another application program. Both B and C will require
some subset of personnel data like employee serial number, department
number and the internal address of a given employee.  Hence B and C
will look at A's data for read-only purposes and let application A
handle Add/Updates/ Deletes of its own data.

      Data can be stored in flat file format, in database management
facility or any other state-of-the-art storage method.  If the data
storage facility used in terms of all three systems is flat files,
then the owner of A's data must make disks available to all B and C
users, to read the data. This would mean that users of B and C
programs could read all data even after the termination of their
programs.

      Alternatively, if data is stored in a SQL/DS* relational
database, then on some VM machines like IBM VM/XA* or the first few
releases of the SQL/DS product, switching of relational databases
like SQL/DS from one database to another is not available.

      Secondly, if application A already has the facility to store
and maintain the data, then it seems rather redundant for
applications B and C to try to duplicate the same data again and
worry about update propagation problems

      Thirdly, if by any chance application A has to change the
layout of its own data, then applications B and C must be notified to
be reprogrammed.

      This article provides an alternative to all of the above
problems.  Because several issues can be addressed just by
implementing this simple and straightforward idea, it seems to be a
versatile effort in programming some application programs this way.

      The suggestion here is that an Application Programs Data
Supplier Interface (APDSI) be introduced to handle some requests such
as those from applications B and C for application A's data.  This
system has been tried and successfully implemented on IBM
System/370*, VM/SP CMS release 4.0 (HPO) and VM/XA CMS release 5.5
operating systems.  Use of CMS IUCV is essential to implement this
idea.  The entire package is on line, multi-programmable and
multi-user.  Accessed data hereby is always current. Response time
using CMS IUCV is virtually the same as that of application programs
scanning the data files. ...