View previous topic :: View next topic |
Author |
Message |
ayashp Beginner
Joined: 20 Dec 2005 Posts: 9 Topics: 3
|
Posted: Mon Jun 12, 2006 4:47 am Post subject: Use of DB-STATISTICS in IDMS |
|
|
Hi,
Can anyone tell me what is the function of DB-STATISTICS and how it is used in IDMS ?
Thanks in advance,
Ayash |
|
Back to top |
|
|
shiv_swami Beginner
Joined: 29 Nov 2003 Posts: 68 Topics: 14
|
Posted: Mon Jun 12, 2006 2:50 pm Post subject: DATABASE STATISTICS |
|
|
From the Fine Manual:-
The ACCEPT DATABASE STATISTICS statement copies system run-time statistics located in the program's IDMS statistics block to program variable storage. This statement can be issued any number of times during the execution of a run unit. For example, you might request database statistics after storing a variable-length record to determine whether the entire record was stored in one place or if fragments were placed in an overflow area.
The ACCEPT DATABASE STATISTICS statement does not reset any of the statistics fields to zero; resetting of IDMS statistics block fields occurs only upon issuing a FINISH command.
Some fields like task id, locks requested/held are specific to CV mode programs. These filed will not be available for local mode programs. _________________ Regards,
Shivprakash |
|
Back to top |
|
|
ayashp Beginner
Joined: 20 Dec 2005 Posts: 9 Topics: 3
|
Posted: Tue Jun 13, 2006 8:17 am Post subject: |
|
|
Hi Shiv,
Thanks alot for your help now and also for earlier times . Actually I had the scenario in which my job was abending at a particular step i.e. in a particular program due to deadlock error while updating a particular record type i.e. using CV mode. I think my deadlock is occuring at page level i.e my program reads a particular record in a page and places a lock on the page and if it happens to update the very next record in that page then I can have the scenario of a deadlock. So by keeping an eye on DB-STATISTICS, i can revisit my COMMIT logic so that I can avoid deadlock. Is my thought process in the right direction. Please advice. And alos if you can give me any material or links for page level locking then it will be of great help.
Thanks,
Ayash |
|
Back to top |
|
|
shiv_swami Beginner
Joined: 29 Nov 2003 Posts: 68 Topics: 14
|
Posted: Fri Aug 11, 2006 9:27 am Post subject: Deadlock analysis |
|
|
If you are having deadlocks, and your program is victim of deadlock (being kicked out by a competing transaction/program), you can check the CV logs for the transaction details of deadlocks.
Let's look at following example:-
DC001000 Vnnn T13 T:000074294 task1 P:PROGM001 C:DEAD WAITING ON R:LTXNLOCK 000C0008 23E57603
DC001000 Vnnn T13 T:000074292 task2 P:PROGM002 C:DEAD WAITING ON R:LTXNLOCK 000C0008 243DAD01
DC001002 Vnnn T13 T:000074292 task2 P:PROGM002 C:DEAD DEADLOCKED ON R:LTXNLOCK 000C0008 243DAD01
Here transaction with IDs 000074294 & 000074292 are vying for record and are in status "DEAD WAITING ".
After a system defined deadlock interval (mostly of 120sec) one of the transaction is kicked out. In this case 000074292 is DEADLOCKEd. .i.e It is victim of the deadlock and the other transaction gets the record it wanted (gets its own way!)
You can look at the LTXNLOCK details. Suggest you to look for the DBKEY involved... Covert it to Decimal..check the page range ..Check area name...Boil down to the record type in the area and then THE occurrence. !!!
Hope this helps.. _________________ Regards,
Shivprakash |
|
Back to top |
|
|
|
|