Electrical computers and digital processing systems: multicomput – Computer-to-computer data routing – Least weight routing
Reexamination Certificate
1999-03-15
2003-05-27
Courtenay, III, St. John (Department: 2126)
Electrical computers and digital processing systems: multicomput
Computer-to-computer data routing
Least weight routing
C707S793000
Reexamination Certificate
active
06571270
ABSTRACT:
BACKGROUND OF THE INVENTION
1. Field of the Invention
This invention relates to a method, computer system, and computer program product that relates to the database management system IMS® available from INTERNATIONAL BUSINESS MACHINES CORPORATION®.
More particularly, this invention relates to solving a problem in that transactions sometimes hang after an asynchronous APPC call issued by IMS from the IMS dependent region during syncpoint processing.
2. Related Art
The following discussion provides the necessary background to understand the invention.
IMS/ESA
IMS/ESA (Information management system/Enterprise systems architecture) provides for a continuous link to information stored in databases. IMS/ESA provides access to critical data, keeping data accurate and consistent while providing timely access to many end users.
There are two major parts to IMS/ESA: a database system (IMS Database or IMS DB), and a data communications system (IMS Transaction Manager or IMS TM). Together, they create a complete online transaction processing environment providing continuous availability and data integrity.
IMS/ESA runs under the MVS/ESA or OS/390 operating systems, which run on the S/390 platform.
IMS DB
At the heart of IMS DB are its databases and its data manipulation language, Data Language/I (DL/I) IMS databases are hierarchic collections of data, information organized in a pyramid fashion with data at each level of the hierarchy related to, and in some way dependent upon, data at the higher level of the hierarchy. DL/I calls provide for the creation and manipulation of these IMS databases.
The IMS DB function provides a full-function resource manager and a fast path resource manager for hierarchical database management. These resource managers map the data language (DL/I) application call interface to the underlying operating system access methods. This mapping enables the application code to function independently of operating system access methods and to remain transparent to the physical storage of the data. The data managed by IMS are organized in hierarchical database records. A database record is composed of segments, a segment being the smallest piece of information that IMS can store. A segment contains fields that are the smallest pieces of data an application program can manipulate. A field identified as a unique key field can be used to navigate the database to find a specific segment. The hierarchical structure of the segments establishes the structure of the database record. A root segment identifies a database record, and a database record cannot exist without a root segment. Dependent segments are the pieces of data that complete the rest of a database record. The IMS DB full-function resource manager provides sequential access, indexed sequential access, and direct access for database processing. The fast path DB resource manager provides the direct method for processing data by using direct access pointers to the segments.
IMS TM
IMS transaction manager (TM) is a message-based transaction processor that is designed to use the OS/390 or MVS/ESA environment to advantage. IMS TM provides services to process messages received from the terminal network (input messages) and messages created by application programs (output messages). It also provides an underlying queuing mechanism for handling these messages.
TM provides for a variety of online processing options. For example, transactions may be defined for high-volume data-entry applications, for interactive applications, or to support predefined queries. IMS TM supports a wide variety of terminals and devices. It also enables the development of a wide range of high-volume, rapid-response applications, and the dispersal of data processing locations geographically, while keeping centralized control of databases.
Transactions
A transaction is a specific set of input data that triggers the execution of a specific process or job. A message destined for an application program and the return of any results is considered by IMS TM to be one transaction. IMS TM running with IMS DB is designed to handle thousands of transactions per second.
Data Integrity
One of the fundamental concepts supported by IMS DB is the concurrent update capability from multiple application programs. IMS DB contains a program isolation local lock manager to support concurrent application program processing. The local lock manager controls access to the database records to ensure data integrity by preventing duplicate access to the same record until the application program completes its processing of the record. The database record is locked when a position is first obtained on is the record. The item locked is the root segment. The database record is locked until position is changed to a different database record or until the application program reaches a commit point.
Because data are always accessed hierarchically, when a lock on a root segment is obtained, IMS determines whether any application programs hold locks on dependent segments. If there are no locks on dependent segments, it is not necessary to lock dependent segments when they are accessed. When an application program updates a segment, the segment, not the database record, is locked. IMS DB uses the Internal Resource Lock Manager (IRLM) global lock manager to support the global sharing of databases across systems in a sysplex (discussed below). When the IRLM is used, no lock is obtained when a dependent segment is updated. Instead, the root lock is held at single update level when exiting the database record. Therefore, no additional locks are required if a dependent segment is inserted, deleted, or replaced. This establishes the foundation for two-way data sharing and N-ways data sharing in a System/390 (S/390) Parallel Sysplex cluster.
Another key aspect of data integrity is recovery. The IMS logger function provides recovery and restart capability for the system. IMS logs the following events:
When IMS starts up and shuts down
When application programs start and terminate
Changes made to the database
Communication messages received and responses sent
Application program checkpoints
System checkpoints
The IMS logger writes log records to a direct access storage device (DASD) logger to support high-volume traffic. IMS first writes log records to a high-speed DASD data set called the Write-Ahead Data Set (WADS). When IMS fills a DASD track on the WADS, IMS copies the entire track to another DASD data set called the Online Log Data Set (OLDS). When IMS is close to filling the last available OLDS, it archives the full ones to System Log Data Sets (SLDSs). While the Log Archive utility is creating an SLDS, it can also create a Recovery Log Data Set (RLDS). The RLDS contains only the log records needed for database recovery. The Database Recovery Control (DBRC) facility is used to support log management, database recovery control, and data sharing.
DBRC automatically records all log data sets produced by the on-line IMS subsystem and by log archiving jobs in a pair of Key-Sequenced Data Sets (KSDS) called RECON (recovery control). IMS uses this information for database recovery jobs if databases are registered and also for IMS restart. DBRC also tracks the archiving requirements of the on-line data set (OLDS) and, if requested, generates and submits the Job Control Language (JCL) for archiving jobs.
DBRC also records:
Database image copies
Database reorganizations
Database recoveries
Accumulations of database changes
Backouts of database changes
Because DBRC records this information in the RECON, DBRC can generate JCL for executing a database recovery.
Data sharing requires that the databases be registered with DBRC. DBRC checks on whether subsystems have authority to perform the requested task and whether other subsystems are not currently reserving the database. Concurrent access to databases by systems in one or more processors is controlled with a common (shared) DBRC RECON data set. To maintain data integrity, status indicators in the RECON data set control concurrent access and recovery
Lai Robert S.
Schneider Richard
Courtenay III St. John
International Business Machines - Corporation
LandOfFree
Timeout detection facility does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with Timeout detection facility, we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Timeout detection facility will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-3010581