If you are licensed for the IMS Option, you can use the product to test and debug either batch or online IMS applications. Test the IMS programs with the product the same way as other programs, but you need to remember that the IMS program is not the first program executed when an IMS application is invoked; the IMS program is attached by the IMS Region Controller (DFSRRC00). This occurs whether the application is a DB/DC application (MPP or BMP) or a DB application (batch).
Your product interfaces with the IBM BTS (Batch Terminal Simulator) program, which you use to simulate online applications.
Notes:
The JCL for executing a batch IMS program has an EXEC statement that specifies the module DFSRRC00. The application program name is specified as a parameter to the DFSRRC00 module. To facilitate testing IMS batch applications with your product, create a CLIST to allocate IMS and CA InterTest™ Batch‑related data sets. Ask your technical support person for assistance in creating the CLIST, if needed.
The CLIST allocations are as follows:
DFSRESLB IMS IEFRDER DFSVSAMP
Note: On the ddname DFSRESLB, the IMS RESLIB data set is concatenated to itself. This is necessary to prevent a dynamic allocation to the ddname. If the IMS RESLIB data set is not concatenated to itself under the ddname DFSRESLB, USER 0684 abends and other unpredictable user abends can occur.
INT1PARM INT1LOAD INT1PNNL INT1PROF INT1MSGL INT1CLOG INT1CLIB INT1REPT
Note: For additional information on CA InterTest™ Batch‑related CLISTS, see the appendix "Basic Foreground Demo Session."
Replace Step 5 in the section Preparation for Testing Execution with the following information:
Generally, the execution parameters are DLI,membername,psbname. If the application program module name and the psbname are the same, then the psbname parameter does not need to be specified.
The application generates a dynamic STEPLIB DD statement from the data set names listed under the STEPLIB portion of the Execution Control panel. For more information on dynamic STEPLIB facility in Execution Control Panel, see the chapter "Debugging Panels."
The following screen is an example of an Execution Control panel for IMS batch testing:
-------------- CA InterTest™ Batch EXECUTION CONTROL Panel --------------------- COMMAND ===> ------------------------------ Allocations ------------------------------------ ALIB Dsname ===> Member ===> EXEC Job Step ===> Proc Step ===> -------------------------- Execution Overrides -------------------------------- PGM ===> DFSRRC00 Initial Commands ===> PARM ===> DLI,PHIDMINQ or Number of Linkage Parameters ===> Task Libraries ===> 'IMS.RESLIB' DSNAME ===> 'USER01.LOAD' or ===> (DDNAME) ===> ===>
Use the Monitor Control panel to identify the programs that have their execution controlled by the application. Identify only the programs that you wish to debug with the application. Also, provide the PROTSYM files that contain the symbolic information for the programs that you would like to debug.
---------------- CA InterTest™ Batch MONITOR CONTROL Panel --------------------- COMMAND ===> Monitor PL/I ==> N --------------------Monitored Programs ----------------------------- ==> DLIPGM1 ==> SUBPGM1 ==> SUBPGM2 ==> SUBPGM3 ==> DLIPGM2 ==> ==> ==> ==> ==> ==> ==> ==> ==> ==> ==> ==> ==> ==> ==> ==> ==> ==> ==> ==> ==> ==> ==> ==> ==> ----------Symbolic (PROTYSM) Files ----------------Endevor Auto Populate ----------------- ==> 'USER01.PROTSYM' ==> Y |Always | ==> ==> |Auto-Populate | ==> ==> |Non-LE-Enabled | ==> ==> |Assembler? | ==> ==> |==> Y (Y/N) | ==> ==> ----------------- ==> ==>
In this example assume that you have two driver modules to debug and test: DLIPGM1 and DLIPGM2. DLIPGM1 calls five subprograms: SUBPGM1, SUBPGM2, SUBPGM3, SUBPGMA, and SUBPGMB. DLIPGM2 calls SUBPGMA and SUBPGMB. SUBPGMA and SUBPGMB do not need to be debugged. In this run, they will be executed, but not symbolically debugged. Thus, their names do not need to be included on the Monitor Control panel.
BMPs are batch IMS programs that run under the control of an online IMS control region. The job is executed in an IMS BMP region. The BMP accesses databases that are allocated to IMS. Thus, the CLIST you use to invoke the application will not include allocation statements for the databases.
If you need assistance in creating the CLIST, ask your technical support person.
Note: If you prematurely end your test session with an END, CANCEL, or QUIT command when testing BMPs, the BMP region does not know the testing session is ending. The BMP region may abend with an S13E.
The following screen shows you an example of an Execution Control panel for IMS BMP testing:
-------------- CA InterTest™ Batch EXECUTION CONTROL Panel --------------------- COMMAND ===> ------------------------------ Allocations ------------------------------------ ALIB Dsname ===> Member ===> EXEC Job Step ===> Proc Step ===> -------------------------- Execution Overrides -------------------------------- PGM ===> DFSRRC00 Initial Commands ===> PARM ===> BMP,PAYROLL,,,,N0003,,2,,,0002,,,IMST or Number of Linkage Parameters ===> Task Libraries ===> 'IMS.RESLIB' DSNAME ===> 'USER01.LOAD' or ===> (DDNAME) ===> ===>
From the Monitor Control panel, the process to test a BMP is the same as the process to test an IMS batch program.
At least one BMP must be added to the IMS/VS Stage 1.
Ask the appropriate technical staff member to add the following application definitions to your IMS/VS System:
Note: You should only use this on an IMS/VS test system. The DOPT option can have a performance impact on a production IMS/VS system.
The BMP defined is used to test the online application. Perform the following steps:
For example, the BMP PSB is ABCD1234 and the application PSB is MYAPPLTN. Thus, the PSB defining MYAPPLTN should be linked into the dynamic PSB library with a name of ABCD1234.
The programmer can use the same BMP name for any IMS/VS online applications to be tested and debugged.
Note: The dynamic PSBLIB data set must be concatenated after the ACBLIB data set. The PSB must reside in a library with the same format as IMSVS.ACBLIB and be concatenated to the IMSACB DD statement. The dynamic PSB must not be a member of IMSVS.ACBLIB.
/SET TRAN trancode
where trancode is the trancode of the BMP defined in the previous section. This command directs all input messages from this LTERM (logical terminal) to trancode. Normally MFS provides the trancode to IMS/VS. The trancode of the application to be tested is different from the trancode through which the application Batch gains control.
BMP,mbr,psb,in,,ostd,,stimer,,,cputime,,,imsid
where:
/RESET
If you have two programmers testing online IMS/VS applications, you could define the following MACROS:
APPLCTN DOPT,PSB=INT01,PGMTYPE=BATCH TRANSACT CODE=(INT01A),PRTY=(0,0) APPLCTN DOPT,PSB=INT02,PGMTYPE=BATCH TRANSACT CODE=(INT02A),PRTY=(0,0) (PRTY=(0,0) is the default when PGMTYPE=BATCH.)
Jones would like to test and debug program PAYROLL while Smith tests program MANUFACT. Jones would either do a PSBGEN or copy his PSB (PAYROLL) into the dynamic PSBLIB member INT01. Likewise, Smith would do the same thing for his PSB (MANUFACT) but as member INT02.
Jones logs on to IMS/VS. He enters:
/SET TRAN INT01A
He then enters his FORMAT and data to execute his transaction. He can enter as many transactions as he likes. When he is done, he may either log off of IMS/VS or do a VTAM switch. He then logs on to TSO to start his test session. On the Execution Control panel under EXECUTION PARAMETERS he enters the following:
PARM ==> BMP,PAYROLL,INT01,INT01A,,N00003,,2,,,0002,,,IMST
When he has ended the application, he can log back on to IMS/VS and view any output messages that his application generated to his LTERM. Once he has viewed all of the IMS/VS output screens, he enters the following command before logging off IMS/VS:
/RESET.
Smith logs on to IMS/VS. He enters the following command:
/SET TRAN INT02A
He then enters his FORMAT and data to execute his transaction. He can enter as many transactions as he likes. When he is done, he can either log off IMS/VS or do a VTAM switch. He then logs on to TSO to start his test session. On the Execution Control panel under EXECUTION PARAMETERS he enters the following:
PARM==> BMP,MANUFACT,INT02,INT02,,N00003,,2,,,0002,,,IMST
When he has ended the application, he can log back on to IMS/VS and view any output messages that his application sent to his LTERM. Once he has viewed all of the IMS/VS output screens, he enters the following command before logging off IMS/VS:
/RESET
Since IMS/VS sees the program with a trancode other than the trancode of the program being tested, different users may schedule the program into multiple IMS/VS regions.
Testing an IMS/VS application whose input messages are placed on the message queue by another IMS/VS program requires a modification to the procedure outlined in the section Testing Your Application. Remember that you use the /SET TRAN trancode command on your IMS/VS terminal to direct IMS to queue all transactions entered from your LTERM to the trancode specified in the SET command. Therefore, your application running as BMP transaction trancode is able to retrieve any messages on the queue destined for your application.
Note: The suggested method for testing IMS applications is using Option 5, Batch Link.
Unfortunately, any messages inserted to the message queue destined for another program will not be tagged with the BMP trancode. There is a way to work around this situation, as follows:
Like an IMS batch application, a DB/DC application executed using BTS is not the first program executed. The module BTSTSOST is the first module executed. It in turn attaches the IMS region controller, DFSRRC00, which attaches the application program to be executed. To facilitate testing of IMS applications with both CA InterTest™ Batch and BTS, create a CLIST to allocate IMS, BTS, and CA InterTest™ Batch‑related data sets. If you need help in creating the CLIST, ask your technical support staff for assistance.
The CLIST allocations are given as follows:
IMS‑related:
DFSRESLB IMS IEFRDER DFSVSAMP
Note: On the ddname DFSRESLB, the IMS RESLIB data set is concatenated to itself. This is necessary to prevent a dynamic allocation to the ddname. If the IMS RESLIB data set is not concatenated to itself under the ddname DFSRESLB, a USER 0684 abend, and other unpredictable user abends can occur.
BTS‑related:
BTSIN BTSOUT BTSPUNCH BTSSNAP QIOPCB QALTPCB QALTRAN TASKLIB
CA InterTest™ Batch‑related:
INT1PARM INT1LOAD INT1PNNL INT1PROF INT1MSGL INT1CLOG INT1CLIB INT1REPT
Note: For additional information on CA InterTest™ Batch‑related CLISTs, see the appendix “Basic Foreground Demo Session.”
Replace Step 5 in the section Preparation for Test Execution with the following step:
The execution parameters are the same parameters that are specified to BTS. Generally, the parameter specified is DLI,,,. If you specify the program member name, the psbname, or both, as you would to test a batch IMS program, a USER 0642 abend can occur (parm exceeds maximum length). The programs and the PSBnames to be tested are identified on ./T cards in the BTSIN data set.
Note: The dynamic STEPLIB function is performed by the BTS Tasklib option. Do not specify a TASKLIB ddname on the Execution Control panel, or BTS will believe that TASKLIB ddname is not allocated and terminate. Allocate the ddname TASKLIB in the CLIST to invoke the application. The load libraries containing the modules to be tested must be allocated to the ddname TASKLIB.
The following screen is a sample Execution Control panel for BTS Execution:
-------------- CA InterTest™ Batch EXECUTION CONTROL Panel --------------------- COMMAND ===> ------------------------------ Allocations ------------------------------------ ALIB Dsname ===> Member ===> EXEC Job Step ===> Proc Step ===> -------------------------- Execution Overrides -------------------------------- PGM ===> BTSTSOST Initial Commands ===> PARM ===> DLI,,, or Number of Linkage Parameters ===> Task Libraries ===> DSNAME ===> or ===> (DDNAME) ===> ===>
The following screen is a sample Monitor Control panel for an IMS online application:
---------------- CA InterTest™ Batch MONITOR CONTROL Panel --------------------- COMMAND ===> Monitor PL/I ==> N --------------------Monitored Programs ----------------------------- ==> DLIPGM1 ==> SUBPGM1 ==> SUBPGM2 ==> SUBPGM3 ==> DLIPGM2 ==> ==> ==> ==> ==> ==> ==> ==> ==> ==> ==> ==> ==> ==> ==> ==> ==> ==> ==> ==> ==> ==> ==> ==> ==> ----------Symbolic (PROTYSM) Files ----------------Endevor Auto Populate ----------------- ==> 'USER01.PROTSYM' ==> Y |Always | ==> ==> |Auto-Populate | ==> ==> |Non-LE-Enabled | ==> ==> |Assembler? | ==> ==> |==> Y (Y/N) | ==> ==> ----------------- ==> ==>
Use the Monitor Control panel to identify the programs that have their execution controlled by the application. Identify only the programs that you wish to debug. Also, provide the PROTSYM files that contain the symbolic information for the programs that you would like to debug.
After you have entered the Execution Control panel and the Monitor Control panel, BTS begins execution by reading the BTSIN data set. A BTS0007I message and images of the BTS input commands are displayed on the terminal. BTS will request a BTS command, a /FORMAT statement, or a /*. The /FOR modname causes BTS to display a formatted IMS screen for input. Once the data has been input, BTS attaches the application program. CA InterTest™ Batch gains control. When the application program calls CBLTDLI, BTS again has control until the IMS language interface module passes control back to the calling program. As a result, the BTS displays are interleaved with the Intercept panels.
If the BTS session ends prematurely and there was no BTS error message displayed on the terminal, review the BTSOUT data set. The BTSOUT data set will often contain data that does not appear on the terminal.
Note: The application intercepts all keyed PA1s during the BTS testing session.
Message switching is when an IMS application program inserts a message to the message queue that is either an output message to another IMS terminal or an input message to another transaction. If the message is an input message to another transaction, then BTS schedules another program to process the input message. To set breakpoints in the IMS program that processes the message inserted into the message queue, perform the following steps:
If this message should occur while testing in a BTS environment, make sure the BTSEXT parameter has been added to the PARMLIB member used to invoke the application. For more information, see Screen Handling Solution for the Message BTS0067I in the chapter "Installation" of the Installation Guide.
When using these verbs in a BTS message switching environment, make sure the BTSSYSO parameter has been added to the PARMLIB member used to invoke the application. For more information, see Applications Using Message Switching and DISPLAY or Figure Verbs in the Installation Guide. Without this option, abends 0C4 and/or 0C1 can occur.
Use this product to test COBOL programs that run under an ADF shell. The recommended procedure for doing this is the same as for testing COBOL programs under BTS. A programmer specifies BTSTSOST on the Execution Control panel as shown in the previous section and the names of the COBOL programs to be tested on the Monitor Control panel. Both of these panels are shown in the previous section Preparation for Test Execution - BTS. Specify the four‑character ID of the ADF SIGN‑ON screen on the /FOR statement. All of the functions of the application are available while testing the specified COBOL programs.
Although this application does not display or intercept code written in the ADF Audit Language, some users use the application facilities to help debug their ADF code. One way is to insert a call to a dummy COBOL program at whatever point in the ADF code they want to intercept execution. Once in the Breakpoint Intercept panel, you can use the Option 2: CORE to display ADF work areas and tables. This requires a good knowledge of ADF. The best source for this information is the IBM IMS ADF II Manuals.
|
Copyright © 2013 CA.
All rights reserved.
|
|