BMC Application Restart Control Document 2 PDF
BMC Application Restart Control Document 2 PDF
Key Benefits
Business Challenge
Many organizations run a significant amount of work in batch mode, but shrinking windows shorten the time
Maximizes availability by
reducing or eliminating batch rerun time
beginning of the job (after recovery of affected databases and files). It is not practical to back out everything
only way to restart at the point of failure is to ensure that the application takes periodic checkpoints of the
available to run batch jobs. When a batch job fails, it must be restarted at the point of failure or at the
and start from the beginning because backing out updates from can take twice as long as running the
application. Nor is it practical to restart from the wrong point, then back out errors and start over again. The
contents of application working storage areas. Taking too many checkpoints wastes CPU resources, but
taking too few lengthens the time required to recover the failed job.
Minimizes implementation
requirements by ensuring easy
retrofit into existing applications
minimize contention between batch jobs and online processing. You can often implement checkpoint/restart
functionality with no changes to application code or jobs. AR/CTL helps you determine the best balance
between performance, restart time, and checkpoint overhead by controlling the checkpoint frequency
Ensuring data integrity is the primary reason for automating restarts. Manually searching for the last
Products
checkpoint is time-consuming and error prone. Restarting from the wrong checkpoint can result in errors,
duplicate entries, omitted updates, or other problems. Recovering from an inaccurate restart can be even
more complex and confusing than the original problem. AR/CTL products select the right checkpoint every
time, eliminating errors and the need to restart your restart. AR/CTL products provide the following features:
Automatic restart checkpoint selection ensures integrity and shorten restart time
Application working storage can capture and restore an application programs working storage areas
in main memory, which allows the program to resume processing at the last checkpoint. It can capture
and restore saved areas of virtual storage for subprograms executing under the main program.
Application reattach improves the operational stability of many application environments by providing
automation to react to certain types of abend conditions. Abends often result from lock contention.
Many times, this makes it possible to schedule update processes to run in parallel rather than serially.
Checkpoint and restart coordination for DB2, IMS, and CICS/VSAM restarts
Automatic checkpoint simplifies and speeds the process of implementing checkpoint/restart logic into
application programs
Program exception handling automatically redirects bad input data that causes S0C7 abends into a
reject file and lets the application continue. Redirected records can be cleaned up the later.
Flat files automatically manages flat files and ensures that the contents of the files are synchronized
with database activity when checkpoints are issued. During restart processing, the files are
automatically repositioned to their state as of the latest checkpoint.
Suspend and resume processing for the following products to obtain a point of consistency required for
reorganization or recovery:
-
SQL return code handling can intercept a defined SQL return code received during application
program processing and issue a user-defined user abend code and reason code. This can be used to
standardize 911 processing throughout an entire application environment.
Cursor repositioning any checkpoint restart solution can effectively save working storage, but only
AR/CTL for DB2 can return the application to the proper position within the cursor. You no longer need
to add logic to your DB2 applications to track and store the cursor position for use in checkpoint restart.
Batch Attachment facility performs the attachment to DB2 on behalf of the application; can run in an
Attach Only mode to provide the DB2 attach for programs not using Checkpoint/Restart services
Restart with no code changes fully supports and enhances the IMS Extended Restart Facility,
Requires no application code or JCL changes; eliminates the need to change application code to call a
third-party restart program
Flat file management supports and manages IMS GSAM files and native file techniques; there is no
need to convert flat files to GSAM
Checkpoint management externally filters excessive checkpoint activity to provide significant savings
in elapsed time and CPU consumption. Many legacy applications were developed to run on slower
processors and the checkpoint intervals were never recalibrated for hardware upgrades.
DBRC conversion aid can automatically provide a logging environment to avoid having to retrofit DL/I
JCL when converting an application to run under DBRC
Local VSAM access services for VSAM data sets that are accessed exclusively by a batch VSAM
application program provides checkpoint support and automatic backout support for VSAM files
VSAM file sharing supports remote VSAM file sharing between batch applications and CICS regions
executing on the same or different z/OS images. This allows batch application programs to update
$1.88 billion.
VSAM files while they are online to CICS and in full update mode and makes it possible to avoid
converting a VSAM file to DB2 or IMS to provide 24x7 type access to the file.
BMC, BMC Software, and the BMC Software logo are the exclusive properties of BMC Software, Inc., are registered with the U.S. Patent and
Trademark Office, and may be registered or pending registration in other countries. All other BMC trademarks, service marks, and logos may be
registered or pending registration in the U.S. or in other countries. All other trademarks or registered trademarks are the property of their
respective owners. 2004, 2009 BMC Software, Inc. All rights reserved. Origin date: 12/09
* 115319*