Minimizing errors

Use these techniques to help you make your applications error-free. Some of these suggestions apply not only to programming, but also to operations and systems.

What often happens is that, when two application systems that run perfectly by themselves are run together, performance goes down and you begin experiencing lockouts or waits. The scope of each system has not been defined enough.

The key points in a well-designed application system are:
  • At all levels, each function is defined clearly with inputs and outputs well-stated
  • Resources that the system uses are adequately defined
  • Interactions with other systems are known

Protecting CICS from application errors

  • You can use the storage protection facility to prevent CICS® code and control blocks from being overwritten by your application programs. You can choose whether to use this facility by using CICS system initialization parameters. For more information about this facility, see Storage protection.
  • Consider using standards that avoid problems that can be caused by techniques such as the use of GETMAIN commands.

General rules for testing applications

  • Do not test on a production CICS system. Use a test system, where you can isolate errors without affecting live databases.
  • Use someone other than the application developer to do the testing, if possible.
  • Document the data you use for testing.
  • Test your applications several times. See Testing applications.
  • Use the CEDF transaction for initial testing. See Execution diagnostic facility (EDF).
  • Use stress or volume testing to find problems that are not found in a single-user environment. A good tool for this is Teleprocessing Network Simulator (TPNS, licensed program number 5740-XT4).

    TPNS is a telecommunications testing package that enables you to test and evaluate application programs before you install them. You can use TPNS for testing logic, user exit routines, message logging, data encryption, and device-dependencies, if these are used in application programs in your organization. It is useful in investigating system performance and response times, stress testing, and evaluating TP network design.

  • Test whether the application can handle correct data and incorrect data.
  • Test against complete copies of the related databases.
  • Consider using multiregion operation. See Multiregion operation.
  • Before you move an application to the production system, run a final set of tests against a copy of the production database to catch any errors.

In particular, look for destroyed storage chains.

Assembler language programs (if not addressing data areas properly) can be harder to identify because they can alter something that affects (and abends) another transaction.

For more information about solving a problem, see Troubleshooting and support.