Peoplesoft Reports Struck in Posting Status - The service PostReport could not be sent because of a blocking condition within Tuxedo on the client

There are multiple issues/scenario for Posting issue. Below post is specific to Error below
===============================================================
PSPRCSRV.4360 (0) [11/26/13 23:59:31](1) (NET.333): The service PostReport could not be sent because of a blocking condition within Tuxedo on the client.  
PSPRCSRV.4360 (0) [11/26/13 23:59:31](1) (NET.333): The service PostReport could not be sent because of a blocking condition within Tuxedo on the client.  
PSPRCSRV.4360 (0) [11/26/13 23:59:31](1) (NET.333): The service PostReport could not be sent because of a blocking condition within Tuxedo on the client.  
PSPRCSRV.4360 (0) [11/26/13 23:59:31](1) (NET.333): The service PostReport could not be sent because of a blocking condition within Tuxedo on the client.  
PSPRCSRV.4360 (0) [11/26/13 23:59:31](1) (NET.333): The service PostReport could not be sent because of a blocking condition within Tuxedo on the client.  
PSPRCSRV.4360 (0) [11/26/13 23:59:31](1) (NET.333): The service PostReport could not be sent because of a blocking condition within Tuxedo on the client.  
PSPRCSRV.4360 (0) [11/26/13 23:59:31](1) (NET.333): The service PostReport could not be sent because of a blocking condition within Tuxedo on the client.  
PSPRCSRV.4360 (0) [11/26/13 23:59:31](1) (NET.333): The service PostReport could not be sent because of a blocking condition within Tuxedo on the client.  
PSPRCSRV.4360 (0) [11/26/13 23:59:31](1) (NET.333): The service PostReport could not be sent because of a blocking condition within Tuxedo on the client. 



Reference from the Oracle Support only but i have verified it and worked well for my issue: 

Case 1:

To remove a Tuxedo POSTREPORT blocking condition (without having to recreate the Process Scheduler);

1. Bring down the affected Process Scheduler(s).

2. Identify the report that is causing the blocking condition by running the following queries:

A) SELECT * from PS_CDM_TRANSFER where TRANSFERINSTANCE = 'lowest transferinstance value'.
B) SELECT * from PS_CDM_LIST where TRANSFERINSTANCE = 'value from (A)' [this will give you the process instance number or PRCSINSTANCE].

C) Go to Process Monitor and verify this process instance is still in a POSTING status.

D) From sql B, take note of the CONTENTID value.

E) Go to the Report Repository location and search for a directory named [CONTENTID from above].

If this directory exists, it means the output has already been posted.

F) Issue a DELETE FROM PS_CDM_TRANSFER where TRANSFERINSTANCE='value from A'

G) UPDATE PS_CDM_LIST SET DISTSTATUS = '4' where TRANSFERINSTANCE = '###'

H) 
Tools 8.4x -8.43

UPDATE PSPRCSRQST SET RUNSTATUS '12' where PRCSINSTANCE = '###'

Tools 8.44 and above

UPDATE PSPRCSRQST SET DISTSTATUS ='4' where PRCSINSTANCE = '###'

I)
Tools 8.4x -8.43

UPDATE PSPRCSQUE SET RUNSTATUS = '12' where PRCSINSTANCE = '###'

Tools 8.44 and above

UPDATE PSPRCSQUE SET DISTSTATUS = '4' where PRCSINSTANCE = '###'

J) On the affected Process Scheduler machine, go to the PSHOME/appserv/prcs/<domain>/log_output directory. If there is a directory for the process instance number from step B, delete the directory.

3. Restart the Process Scheduler(s),

Note: You may need to repeat this series of events depending upon the nature of the blocking condition.  Meaning, there could be multiple instances causing the blocking, so it's best to make these changes one instance at a time.

Case 2:

There are more entries in PS_CDM_TRANSFER and so many reports struck in posting ..

Have deleted all the entries from PS_CDM_TRANSFER and set the reports to not posted. Then Manually resend the reports solved the issue.

DELETE FROM PS_CDM_TRANSFER;
UPDATE PSPRCSRQST SET DISTSTATUS=4 WHERE DISTSTATUS=7;
UPDATE PSPRCSQUE SET DISTSTATUS=4 WHERE DISTSTATUS=7;

UPDATE PS_CDM_LIST SET DISTSTATUS=4 WHERE DISTSTATUS=7;

If this is repeating and want to avoid in future. Tuxedo message parameters need to be tuned.

To help avoid this issue in the future:

1.  Increase Max Instance number of distribution agents for the Process Scheduler.  The following setting can be set to a maximum value of 5 in psprcs.cfg.

Values for config section - PSDSTSRV
    Max Instances =1
    Recycle Count=0
    Allowed Consec Service Failures=0
    Max Fetch Size=0

2.  Increase the default 'Maximum Message Queue Size' for Tuxedo.

Generally, this blocking condition in Tuxedo occurs when the IPC Resource are insufficient on the server. This problem has been tracked primarily to the value of "Maximum Message Queue Size" parameter. The default on Windows for this is 65536, which is the maximum size of a queue (in bytes). This parameter and others can be tuned through the Settings->Control Panel ->BEA Tuxedo Administration. Other Tuxedo parameters that might be tuned are "Number of Message Segments" and "Size of Message Segment". The corresponding UNIX kernal parameters are MSGMNB, MSGSEG, MSGSSZ.

Refer: http://psoftdba.blogspot.sg/2013/11/peoplesoft-reports-posting-issuetuning.html


IPC_PARAMETERS Reference: 

UNIX MESSAGE Queue Reference

Rest Next :-)