Re: DB2 CF Lock Structure DSNDP3G_LOCK1
Shane wrote on 07/09/2006 12:32:46 +1000 As a general statement, if the structure owner chooses to use async rather than sync, why would you care ???. If none are actually being converted, pat yourself on the back for a job well done, and go find a real problem to worry about. Don't be so quick to believe it wasn't converted. If a CF has consistently bad performance issues it quits trying to send sync requests and converts them to async without reporting it as changed. I could not find where this is documented but I know it is true from experience with a test system that had 2 CF's - one of which consistently had performance issues because it was in a remote location. There were very few requests reported by RMF as having been changed but all structures allocated in that CF that were generally sync type requests were converted to async. The similar type structures in the other good CF were not converted and were reported as having been sync request. We lived with it because it was just a test system. If and when we had a need to test without the request being converted we favored the good CF by ensuring the structure would be allocated in that CF. Maybe one of the IBMers on the list can provide a pointer to the doc that describes this behavior. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: DB2 CF Lock Structure DSNDP3G_LOCK1 Performance
Your comments are exactly what I am searching for. Shane asked 'why wwould I be concerned' and the answer is that the Async requests to the DB2 lock structure seem to happen around the times of application timeouts. I do hope that others, including IBM'ers, will join in with their comments and suggestions as to how to more clearly identify the RMF data fields and possible the causes of such a CF condition. Thanks. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: DB2 CF Lock Structure DSNDP3G_LOCK1 Performance
Neil, And, for additional information concerning DB2-related lock structures, you might consider cross-posting to the DB2-L ListServ. Lock Lyon Compuware Corp Neil Ervin [EMAIL PROTECTED] Sent by: IBM Mainframe Discussion List IBM-MAIN@BAMA.UA.EDU 09/07/2006 10:50 AM Please respond to IBM Mainframe Discussion List IBM-MAIN@BAMA.UA.EDU To IBM-MAIN@BAMA.UA.EDU cc Subject Re: DB2 CF Lock Structure DSNDP3G_LOCK1 Performance Your comments are exactly what I am searching for. Shane asked 'why wwould I be concerned' and the answer is that the Async requests to the DB2 lock structure seem to happen around the times of application timeouts. I do hope that others, including IBM'ers, will join in with their comments and suggestions as to how to more clearly identify the RMF data fields and possible the causes of such a CF condition. Thanks. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: DB2 CF Lock Structure DSNDP3G_LOCK1
Neil wrote on 07/09/2006 08:37:16 AM: Under what conditions might there be Async requests for this DB2 lock structure? The RMF 'Sync changed to Async' value is 0 during the intervals containing Async requests 0. The Async requests occur infrequently but I'm wondering if they might cause sync requests to suffer, or might be the result of suffering sync requests. As a general statement, if the structure owner chooses to use async rather than sync, why would you care ???. If none are actually being converted, pat yourself on the back for a job well done, and go find a real problem to worry about. However I do appreciate that the DB2 developers seem to have a peculiar view of the world. I can offer no help there. Shane ... -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
