TEST command

Use the TEST command to test a program, command processor, or APPC/MVS transaction program for proper execution and to locate programming errors. For APPC/MVS transaction programs, use this command to test standard transaction programs. However, you can also use this command to partially test a multi-trans type transaction program up to the point where it issues GETTRANS for the next transaction. To use the TEST command and subcommands, you should be familiar with the Assembler language and addressing conventions. Refer to the appropriate publications for information about how to code assembler programs and definitions of assembler language terminology. Also, see z/OS TSO/E Programming Guide, for more information about using the TEST command and the TEST tutorial. For best results, the program to be tested should be written in Assembler language. To use the symbolic names feature of TEST, your program should have been assembled and link-edited with the TEST operands.

If the tested program attempts to LOAD, LINK, XCTL, or ATTACH another module, the module is being searched for in the following sequence: Libraries specified by an active TSOLIB command, then TASKLIB, STEPLIB, JOBLIB, LPA, and then LNKLST. If the module is not in any of these areas, it will not be found. To avoid this, bring the module into virtual storage by using the LOAD subcommand of TEST.

If you enter the TEST command with operands, a pseudo or automatic breakpoint is established at +0 for the problem program being invoked under TEST. Therefore, do not use the AT subcommand of TEST (AT +0).

If you use the TEST command to test inbound APPC/MVS transaction programs, the following restrictions apply:

You should log on with a LOGON procedure that does not allocate APPC/MVS conversations. If APPC/MVS conversations exist, TEST issues message IKJ57501l TEST END DUE TO ERROR + with a second-level message that explains the error and then TEST terminates. You must then perform cleanup for the conversations. (To clean up the conversations, log off. When you log on again, you should ensure that any LOGON procedure command that you specified on the logon panel does not invoke a CLIST or REXX exec that allocates APPC/MVS conversations. Note that allocation of DFM data sets may cause APPC/MVS conversations to be allocated.)
The user-level transaction program profile for the LUs that are to be used for transaction program testing must be allowed. To allow user-level transaction program profiles, the LUADD statement in PARMLIB member APPCPMxx must include the TPLEVEL(USER) keyword. Use the LU or BASELU keyword to specify the LU on which to test the transaction program. These keywords are valid only when you use the TP keyword operand on inbound APPC/MVS transaction programs. BASELU is the default. For information about transaction program profiles, see z/OS MVS Planning: APPC/MVS Management.
If your installation uses RACF® and security label checking has been activated, transaction programs cannot be tested under LU=LOCAL environment. For more information about the environment for testing transaction programs, see z/OS MVS Programming: Writing Transaction Programs for APPC/MVS.

See z/OS TSO/E Programming Guide for information about:

Using the TEST command. It contains a step-by-step tutorial on how to use TEST.
Testing an APPC/MVS transaction program.
Addressing conventions associated with TEST.
Restrictions on the use of symbols.
Programming considerations and restrictions for using TEST. These include:
- 31-bit addressing
- Using virtual fetch services
- Cross-memory environment
- The vector facility

Note: Requesting an attention interrupt while testing a password protected data set might terminate the TEST command's processing.

Restriction: TEST allows a user to test AMODE 24 or AMODE 31 programs. Testing programs with any other AMODE will have unpredictable results.