iSeries CPD3E3E message still present in V5R3

0 pts.
Tags:
AS/400
DataCenter
I was looking for an answer on what to do to solve the appearance of message CPD3E3E in the QSYSOPR message queue. Where I have found some information, it gets me back to 2002 with the application of some SF66490 PTF included in cumulative packages for versions older than V5R3. Never saw anything more recent by these years, and the message keeps popping up with reason code 13, which does not have a Recovery action. Has someone finally put an end to this? As I said, I have not seen any recent replies in other forums where this problem has already been solved. Thanks.
ASKED: November 10, 2006  12:12 PM
UPDATED: December 25, 2009  4:48 AM

Answer Wiki

Thanks. We'll let you know when a new response is added.

Here is a search result from System I Support site about CPD3E3E:

Message CPD3E3E RC13 – What does it mean?
Technote

This messages indicates that some threads from the previous job usage have been left open; however, QRWTSRVR prestart job are still recycled.

If this message is bothersome, analyze your applications to determine where these threads are left hanging. Because this is an informational message, it is not handled by system code. Work Management code does not drop these threads at recycle time. If the user is not concerned about performance, the user can change the MAXUSE parameter value to 1 for the prestart jobs using the CHGPJ E command. This ensures that the jobs are not recycled and all threads are ended when the job ends.

CHGPJE SBSD(QUSRWRK) PGM(QRWTSRVR) MAXUSE(1)

HTH.

Rich

=============================================================

This doesn’t seem to be a PTF issue. It had some PTFable aspects long ago, but those may be long gone. It’s more likely an issue with some non-IBM programs in your system.

These might be exit programs attached to the DDM exit point. The exit program(s) starts threads that are perhaps intended to stay active for as long as a QRWTSRVR instance stays active. That’s probably a good thing if the alternative is start and end the thread(s) for every single transaction. It’s similar to leaving files open in case the program iscalled again.

Or maybe they’re related to triggers. A file update activates a trigger that spawns additional threads under some circumstances. Perhaps for a similar reason an exit program would — to have an active structure waiting for the next transaction.

Or maybe SBMRMTCMD is invoking a program that’s spawning threads or performing threaded activities against a file system or…

In any case, a thread isn’t terminating. Display the QRWTSRVR job that’s throwing the message and look at its thread info. That should tell you where the problem is.

…if it is a problem at all. It might be a normal and desirable case.

Tom

Discuss This Question:  

 
There was an error processing your information. Please try again later.
Thanks. We'll let you know when a new response is added.
Send me notifications when members answer or reply to this question.

REGISTER or login:

Forgot Password?
By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy

Forgot Password

No problem! Submit your e-mail address below. We'll send you an e-mail containing your password.

Your password has been sent to:

To follow this tag...

There was an error processing your information. Please try again later.

REGISTER or login:

Forgot Password?
By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy

Thanks! We'll email you when relevant content is added and updated.

Following