Suggested areas for Automation

Control IMS resources

Automating control of specific resources can measurably improve availability at both the application and user level.

Restart transactions or programs after an abend

You can write an EXEC to automatically respond to the IMS message DFS554A and issue commands to restart the abending program and transaction.

The EXEC can control the restart according to the type of abend or the number of occurrences. This automatic restart eliminates the delay caused by manually restarting a program and transaction. Also, EXEC can notify the database administrator who is responsible for the applicatio. See the sample EXEC DFS554A in the BBUSER library.

Restart dropped lines

You can write an EXEC that responds to the IMS message DFS970I and issues commands to restart a dropped line (up to a specified number of tries). The EXEC can also issue a WTO to the network operator at a specific destination (ROUTCDE) if these retries fail. See the sample EXEC DFS970I in the BBUSER library.

Control a large group of IMS resources

Some IMSs are so large that IMS hangs if a /STOP NODE ALL or similar command is issued. Within an EXEC, use the generic commands so that commands can be issued for groups of resources. Then schedule each EXEC in stages to give IMS time to handle the commands. The staging can be done by the operator, or the first EXEC scheduled by the operator could schedule a time-initiated EXEC to handle the staging automatically, or delays can be included between the groups of commands within an EXEC.

Control a group of related resources simultaneously

All of the resources for an application can be started or stopped at the same time when the operator submits an EXEC at the COMMAND line. For example, COMMAND ===> %PAYROLL START starts all of the databases, terminals and transactions for the application program PAYROLL. This feature not only speeds up the process, but also avoids input errors likely when the operator must key in a long series of commands and resource names.PSee the sample EXEC PAYROLL in the BBUSER library.

Manage the IMS test system

Your test system can be automatically started daily at a specified time, message regions started, databases switched regularly, and users notified prior to shutdown. PSee sample EXEC DRIVER in the BBUSER library.

Stage IMS startup

An EXEC can issue the commands that start the IMS control region, dependent regions, groups of lines and message regions, and assign transactions to classes. Or, the EXEC can issue the transaction classing assignments only. PThe sample EXEC DFS994I in the BBUSER library starts up IMS resources in response to the IMS message DFS994I.

Reconfigure resources

A time-initiated EXEC can be scheduled to handle system reconfiguration for batch-oriented work when the major online workload has finished; for example, at 6:00 P.M. Some of the possible actions are to send a message to all online users, stop most message regions, and then schedule BMPs.

The EXEC can also allow the operators to delay these actions for a specified number of minutes by setting a global variable, which is tested at the beginning of this reconfiguration EXEC.

Program changes in a virtual fetch environment

An EXEC can automate the steps needed to stop and restart the affected message regions when a program is changed and Virtual Fetch is being used.

Fast Path MSDB recovery

An EXEC can be scheduled to capture MSDB messages at checkpoint, to start a batch job to copy the MSDBs to MSDBINIT. If an ERE (emergency restart) occurs, the current version of the MSDBs is automatically loaded.

Control ISC links

An EXEC can restart a failing link or reassign a link to a backup.

Control MSC links

An EXEC can restart a failing link or reassign a link to a backup.

Simplify DB2 command input

EXECs can also be used to group logically related DB2 databases together, such as all DB2 databases used by IMS transactions. You could then display all the locks for that group of databases by invoking your EXEC: COMMAND ===> %DB2DB LOCK and then viewing the results on the Journal log. The DB2DB EXEC would contain DB2 commands such as