Finding a new Entry Point signature for use with IN25UEXI
Article ID: 27730
Updated On:
Products
Issue/Introduction
INTRODUCTION:
This document describes what do when one is in an InterTest CICS session and receives the message "an attempt to change an area that does not belong to this task. Possible system damage has been prevented" on a CALL instruction of the type BALR 14,15.
INSTRUCTIONS:
Does this look familiar?
<Please see attached file for image>
As seen, this automatic breakpoint has resulted from a call to DB2. Programs make these kinds of calls all the time, so why is Intertest stopping execution? A possible reason is that this program is making a call to a version of DSNHLI that is not defined to an Intertest program named IN25UEXI. IN25UEXI is called every time an application program branches to another program that is linked in with it - a static call. When a static call is made, the instruction executing the branch to the sub-routine or program is a BALR 14,15 (or 05EF). The 05EF triggers Intertest to call IN25UEXI.
IN25UEXI is nothing more than a table of entry points to different modules for various software packages included in a default IN25UEXI provided with Intertest. These entry points are compared to the code being executed at the address pointed to by register 15. If a match is found, then Intertest will suspend monitoring on the application program, allow the processing to be done after the call to the external software (DB2 in this case), and resume monitoring when control is returned to the next instruction within the application program.
If a match is not found, then Intertest will continue monitoring the code executed after the branch. In this case, Intertest is actually monitoring DB2 itself. Since DB2 may access storage that the application program doesn't own, Intertest is stopping execution due to a perceived storage violation. This mismatch might simply be caused by a new release of DB2 that has been installed on the CICS region, included in the link edit step of the application program but this new DSNHLI's entry point isn't found in IN25UEXI. Thus, Intertest continues monitoring.
The key to fixing this problem is to find out what the code looks like at R15 at the time of the BALR. You can do this using the following procedure:
- Abend the task currently at the automatic breakpoint. Enter "abend" on the command line at the top of the display. Press enter and type in xxxx at the prompt for an abend code on the next display. PF3 will get you out.
- Redisplay the source code and set an unconditional breakpoint at the line of code causing the breakpoint. In this case it is statement 1647.
- Re execute the transaction and stop at the unconditional breakpoint.
<Please see attached file for image>
4. Since you need to find out what the code is at the BALR 14,15, the source code listing display needs to be changed to display the register contents. Press PF4 to display the Profile and change the first option, Display Titles, to an "R".
<Please see attached file for image>
5. Press enter to return to the breakpoint display. Note that the PF keys and Options have been replaced by the contents of registers 0 - 15. Now you need to set up a breakpoint to stop at the BALR 14,15 (05EF) at the branch into DSNHLI. To do this, set a conditional breakpoint on the command line to stop execution when the current instruction is a 05EF. Use the command.
CNTL=ON*,CBP=.ANY,IF=CURR.EQ.X'05EF'
To analyze this command, the CNTL=ON* is a shorthand way to set the conditional breakpoint for this program, it replaces the normal CNTL=ON,PROG=IN61146C. CBP=.ANY, sets the conditional breakpoint at any offset within the program that meets the criteria which is when the current instruction (CURR) is equal to a BALR 14,15.
<Please see attached file for image>
6. Pressing PF5 will continue program execution, stopping at the conditional breakpoint set for the BALR 14,15. Register 15 is pointing to address 20A179A0 which is the entry point to DSNHLI.
<Please see attached file for image>
7. The address in R15 is above the line and can be displayed directly by entering a % over the first digit of the address. For, addresses below the line, substitute an @ for the %.
<Please see attached file for image>
8. Pressing enter displays the address. Notice the command generated and displayed in the lower left, CORE=%R15.
<Please see attached file for image>
9. The code at the entry point used for the comparison begins at +0 of the display above. To see the entry point(s) for DSNHLI contained in IN25UEXI, enter the command CORE=PGM=IN25PGM2@18%4. This displays the version of IN25UEXI in use. When Intertest starts, the address of IN25UEXI is copied into IN25PGM2, the main monitoring module. At +18 within IN25PGM2 is a pointer to a table of the addresses of different Intertest modules. The second address in this table (+4) is the address of IN25UEXI.
The command tells Intertest to go to this address and display it. In this case, IN25UEXI begins at 06A000.
<Please see attached file for image>
10. Pressing PF8 to advance through IN25UEXI's list of entry points displays the entry points for the different DB2 modules on Page 4 at beginning at offset +4C4 within IN25UEXI.
<Please see attached file for image>
11. To make things a bit easier to follow, adding the offset of the DSNCLI literal (+4C4) to the core command will bring the literal DSNCLI to +0 on the display.
<Please see attached file for image>
12. Now that DSNCLI is at +0, the format of each IN25UEXI entry can be covered in detail. The first 8 bytes make up the entry name, in this case DSNCLI. Please note, the literals can be any valid csect name and don't have to match the name generated in the call statement. The 3E at +8 means that this entry number is number 62 in the list of csect names contained in IN25UEXI, followed by the comparison value length (17 hex, 24 decimal) of the code at the entry point. The 0000 means that the comparison will start at +0 of the entry point, and the last 4 bytes contain the address of the entry point code stored in IN25UEXI - 06A9F0. The CORE command can now be changed to display what is at that address.
<Please see attached file for image>
13. The code at that address is very similar, but not quite the same as what R15 was pointing to. Note that the code from R15's address has a 021A at +4 while IN25UEXI shows a 021C at that same offset. To test if this is the difference and the cause of the breakpoint, the CORE transaction can be used to change the code here to match that at the address pointed to by R15. Simply overtype the 021C with a 021A and press enter. If prompted for a password, the default is MAIN.
<Please see attached file for image>
14. Now, return to the breakpoint screen and (press clear) set a U at statement 1648 and press PF5.
<Please see attached file for image>
15. We have successfully bypassed the automatic breakpoint!
<Please see attached file for image>
16. The default values for the DB2 entry points contained in IN25UEXI are found in Intertest Samplib member (UEXIDB2).
<Please see attached file for image>
17. What needs to be done is to add the necessary change to the list of current entry points. Again, since the literal can be any valid csect name, DSNCLIA has been used along with the code found at R15 at the point of the call in the application program.
<Please see attached file for image>
18. There are instructions in the Intertest Getting Started Guide, along with sample JCL to reassemble IN25UEXI. The copybooks used to create the default version sent with the base Intertest product are found in Samplib member IN25UEXI which can be used as the input to the Assembly.
19. Once the module is reassembled and linked, in order to install the new version
a. Stop Intertest (CNTL=END)
b. CEMT S (IN25UEXI,IN25PGM2) NEW <- = This must be done in this order to ensure that the new version is picked up. When Intertest is started, IN25PGM2 is loaded resident and contains the address of IN25UEXI. If not done as shown, the new version of IN25UEXI will not be picked up.
c. Restart Intertest (CNTL=START or CNTL then PF3).
d. At this point, you may want to issue the CORE=PGM=IN25PGM2@18%4 command to see if your new version is picked up. You should see the new DSNCLIA literal.
Please note that the entry point string containing the 18F15810021A literal doesn't really exist. That string, pointed to by R15, at the call to DSNHLI was changed using the CORE transaction before executing the program to intentionally cause the automatic breakpoint for illustrative purposes.
Environment
Component:
Attachments
Feedback
