When a program is started after an abnormal end, it can look for
an entry in the notify object. If the entry exists, the program can start
a transaction again. After the transaction has been started again, the notify
object is cleared by the program to prevent it from starting the same transaction
yet another time.
Here are ways to use a notify object:
- If the commit identification is placed in a database file, query this
file to determine where to start each application or workstation job again.
- If the commit identification is placed in a message queue for a particular
workstation, a message can be sent to the work station users when they sign
on to inform them of the last transaction committed.
- If the commit identification is placed in a database file that has a key
or user name, the program can read this file when it is started. If a record
exists in the file, start the program again. The program can send a message
to the workstation user identifying the last transaction committed. Any recovery
is performed by the program. If a record existed in the database file, the
program deletes that record at the end of the program.
- For a batch application, the commit identification can be placed in a
data area that contains totals, switch settings, and other status information
necessary to start the application again. When the application is started,
it accesses the data area and verifies the values stored there. If the application
ends normally, the data area is set up for the next run.
- For a batch application, the commit identification can be sent to a message
queue. A program that is run when the application is started can retrieve
the messages from the queue and start the programs again.
You can use several techniques for starting your applications
again, depending on your application needs. In choosing the technique, consider
the following information:
- When there are multiple users of a program at the same time, a single
data area cannot be used as the notify object because after an abnormal system
end, the commit identification for each user will overlay each other in the
data area.
- Your design for deleting information in the notify object must handle
the situation when a failure occurs immediately following use
of the information:
- If information is deleted immediately, it does not exist if another failure
occurs before processing the interrupted transaction.
- The information in the notify object must not be deleted until the successful
processing of the interrupted transaction. In this case, more than one entry
will exist in the notify object if it is a database file or message queue.
- The program must access the last record if there is more than one entry.
- A notify object cannot be used to provide the work station user with the
last transaction committed because the notify object is updated only if a
system or job failure occurs or if uncommitted changes exist at the normal
end of a job.
- If information is displayed to the workstation user, it must be meaningful.
This might require that the program translate codes kept in the notify object
into information that will help the user start again.
- Information for starting again must be displayed if the work station user
needs it. Additional logic in the program is required to prevent information
from being displayed again when it is no longer meaningful.
- A single notify object and a standard processing program can provide a
starting again function if the notify object is a database file. This standard
processing program is called by the programs that require the ability to start
again to minimize the changes to each individual program.