Tag Archives: xpediter

Problem Enabling REXX for CICS in CICS/TS 3.2

When enabling REXX for CICS in a CICS/TS 3.2 environment, I got an REX1 abend when trying to format the RFS pools. I couldn’t find that abend code documented in CMAC, and didn’t have any luck finding anything relevant in SIS, so I ran it through CEDF. CEDF reported that the real abend was an ASRA at offset x’03CA8E’ in CICREXD. Again, I had no luck finding this abend documented, so I opened an ETR with IBM CICS support. After I provided them with a system dump, they were able to tell me that the abend was actually ocurring in module DBUGDZST, which is an Xpediter module. Turning off storage monitoring for the REXX transaction allowed the process to run successfully.

Advertisements

I Can’t NEWCOPY My Program!

Why can’t I NEWCOPY the program I just compiled? The answer is almost always, “Because it’s in use.” Occasionally, for new programs, the answer may be that the compile or link edit was not successful. It’s possible that there is a problem with the PDS containing the load module. It’s conceivable that the person trying to issue the NEWCOPY does not have security to do so. But just about every time I’ve been asked to help answer this question, the reason has been that the program is in use.

The key to resolving such an issue is to find out what is using the program. I usually start by issuing a CEMT INQ PROG(yourpgm), and looking at the RES field (resource use count). If it is greater than 0, then the program is currently in use. I’ll hit enter several times, watching to see if the use count is varying, or staying at the same number. If it happens to be 0, then it’s possible that whatever had the program in use earlier has released it, and a NEWCOPY now will be successful.

If the RES field is varying, then I ask, “Is the module one that is invoked often?” If so, you may not be lucky enough to hit it when it is not being invoked. In that situation, issue CEMT SET PROGRAM (your-pgm) PHASEIN. This will bring in a new copy on the next invocation, even if it is currently in use.

If the RES field is staying at the same value (typically at “1”), then chances are good that a debug facility has it held. It could be held by someone running through CEDF, or a product such as Xpediter. It should be obvious from a CEMT INQ TAS command what has it held. What to do next in this situation depends on the debug product. If CEDF, then contact whoever has it (you should be able to identify the person running the CEDF transaction from the terminal id shown in the CEMT display). If Xpediter, use XPSP (System Facilities, then Resource Summary) to release Xpediter’s hold on the program. I’m sure each debug product has its own way of releasing its hold on a program in a similar fashion.

As a last resort, try issuing a CECI REL PROG(yourpgm) to release the program.

One of these methods has always worked in my experience. It is best to try to learn what the situation is rather than just start canceling tasks or issuing the CECI REL command – otherwise, you may be affecting somone else’s testing!