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!


2 responses to “I Can’t NEWCOPY My Program!

  1. Hi Steve, This is a very good explanation for program new copy. But I have question here, I usually cross verify the length of the program to verify that the program has been new copied or not from the change in the length. Is there an another way to check the program has been new copied?

  2. Hi. Excellent question! Yes, I myself will often do a CEMT INQ PROG and issue a NEWCOPY from there, so I can see the size change. But, if the new copy of the program is the same size as the previous version, or if you are wanting to find out if someone else or an automated process NEWCOPY’d the program, CEMT will not tell you. I like to use Russ Evans’ free storage display utility; if you browse the storage for a COBOL program, it is fairly trivial to find the compile date/time stamp. Hope this helps!

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s