IBM Mainframe Forum

We had a situation where we performed a NEWCOPY, but the program didn't refresh.

There are 2 TOR's under an AOR, so we used CRTE to get to the AOR. We did a NEWCOPY and it looked successful, there were no errors and usecount & rescount were both 0. It appeared that the new version of code was executing fine in one of the TOR's, but not the second. The abend generated by the tran in the second TOR showed a DB2 consistency token from the old version of the program, so it was still executing the old load module. After a CICS bounce the next day, everything was fine (as we expected).

We've had this happen twice in a production region and can't replicate it in test, which makes it hard to do much further digging. We won't move this program to prod again for over a year, but would like to understand the issue.

Does anybody have any ideas what would cause this and how we can get around it? I've read quite a bit about PHASEIN, but it didn't look like the pgm was in use at the time, nor did NEWCOPY return any errors. Any ideas / suggestions are much appreciated!

Thanks in advance,
Pat

PatZ wrote:We had a situation where we performed a NEWCOPY, but the program didn't refresh.

As you say below, yes, it did refresh.

There are 2 TOR's under an AOR, so we used CRTE to get to the AOR. We did a NEWCOPY and it looked successful, there were no errors and usecount & rescount were both 0.

Did the byte count change too (assuming the new module was changed enough to be a different length)?

It appeared that the new version of code was executing fine in one of the TOR's, but not the second.

Either the executable code resides in the second TOR or that TOR is pointing to another AOR.

The abend generated by the tran in the second TOR showed a DB2 consistency token from the old version of the program, so it was still executing the old load module. After a CICS bounce the next day, everything was fine (as we expected).

That would be expected if the AOR/TOR that holds the other copy got restarted.

Debug mode:
Next time this occurs, cedf the failing version and once into the non-refreshed version, CECI, load the module, get the load address, view that storaage for the compiler imbedded timestamp to confirm that it is still the old module.
Then try a CECI ASSIGN SYSID to see which system the CEDF on the unrefreshed module n(and hopefully the module itself) is running/residing in.

Thanks for the quick response.

We verified that both TOR's are under the same AOR, but that was a good thing to check and something we were taking for granted (never a good idea). I'm still hung up on how there can be 2 different load modules executing in the same AOR (the new version executing in TOR1, the old executing in TOR2).

I don't remember whether the pgm length changed when newcopied, but I assume it did, because as you mention, the new version did get copied into the region because TOR1 worked fine. Why TOR2 was somehow hanging onto the old copy is still a mystery.

Thanks much for the debug ideas, we'll try that next time we run into this.

Pat

PatZ wrote:I'm still hung up on how there can be 2 different load modules executing in the same AOR (the new version executing in TOR1, the old executing in TOR2).

Based upon your previous description, it can't.

Why TOR2 was somehow hanging onto the old copy is still a mystery.

Have you checked both TORs with a CEMT I PROG?

When in the TOR, CEMT returns no info for pgms \(because I think they're executing in the AOR. We have to CRTE to the AOR in order for CEMT to do anything.