Using dynamic resource definition and online change for testing

Using dynamic resource definition and online change capabilities, you can plan to perform selective testing during execution of an IMS online test system. Your testing can be accomplished without generating a modified test system merely to accommodate some temporary changes.

You can perform testing that supports:

• The addition of new applications
  • New transactions, programs, and MFS formats
  • Additional databases
• Modifications to existing applications
  • Modified database definitions
  • Replaced PSBs and programs
  • Altered MFS formats
  • Necessary deletions for the above modifications

You cannot use this method to test the use of terminals or devices not already defined to the IMS system.

Another factor might be the security arrangements. Planning for change must ensure that appropriate authorization exists to use the transactions or existing terminals for the duration of the test.

You might plan for a group of application changes to make up a test package to be executed during IMS online operation in a test system, or even during a production cycle. Online change is best used to migrate pretested changes without the need for a full restart interruption. Your planning should include the following considerations:

• Online data resources must be adequately protected. Carefully assess the risk that an application program being tested could damage production data.
• Added databases must be included in the JCL for the IMS control region; a solution for z/OS® systems is to use dynamic allocation.
• Although changes to database structures can be reflected in a new ACB build, this might not always be practical if the changes require a reorganization.
• You must coordinate the update of IMS.PGMLIB with the status of the online processing. A replaced program might cause problems, unless the end user is aware of the activity. The library update might have to be carried out in the interval just before the /MODIFY COMMIT command.
• You must assess the potential performance impact to tuned systems, although a monitored test execution can provide valuable information for performance planning.

The entry of the /MODIFY PREPARE command begins the cut-over operation. When activity has stabilized for the resources affected by the content of the online change, the /MODIFY COMMIT command completes the cut-over. Testing can now begin. When you complete the planned testing, repeat the /MODIFY PREPARE, /MODIFY COMMIT command sequence to reinstate the old unmodified system data sets that were inactive during the testing. It is the responsibility of those performing the test to nullify the effects of the testing and back out any inappropriate changes made to the databases.