ca.portal.admin

HYPER Q075370

Discussion created by ca.portal.admin on Sep 13, 2006
This fixed the following problem:

""Indexes where compression of index keys has been defined can be
corrupted during the insertion of a
record into the SR8. This is most likely to occur when adjacent records
share a significant number of
equal leading positions.""

But existing indexes may still need to be rebuilt, if they prove to be
corrupted.

We've identified several indexes on our databases which potentially have
this problem. Rather than simply rebuild the index,
which could take too long, we plan on writing a generalised program to
check if any of our indexes are corrupted.

Before we start on writing this, has anyone else written code to do
this, which they'd be prepared to share?

Iain Robertson

British Telecom
iain.dk.robertson@bt.com
"
IDMS Public Discussion Forum
IDMS-L@LISTSERV.IUASSN.COM
SMTP
IDMS-L@LISTSERV.IUASSN.COM
IDMS-L@LISTSERV.IUASSN.COM
SMTP








Normal

Normal
HYPER Q075370
"This fixed the following problem:

""Indexes where compression of index keys has been defined can be corrupted during the insertion of a
record into the SR8. This is most likely to occur when adjacent records share a significant number of
equal leading positions.""

But existing indexes may still need to be rebuilt, if they prove to be corrupted.

We've identified several indexes on our databases which potentially have this problem. Rather than simply rebuild the index,
which could take too long, we plan on writing a generalised program to check if any of our indexes are corrupted.

Before we start on writing this, has anyone else written code to do this, which they'd be prepared to share?

Iain Robertson

British Telecom
iain.dk.robertson@bt.com
"
IDMS Public Discussion Forum
IDMS-L@LISTSERV.IUASSN.COM
SMTP
IDMS-L@LISTSERV.IUASSN.COM
IDMS-L@LISTSERV.IUASSN.COM
SMTP








Normal

Normal
Re: HYPER Q075370
"Hi Iain

That is a fix generated by an issue which I raised at 2:00 AM on
13/10/2005. I remember the carnage very well.

In order to analyse it and prove the problem to CA I wrote a quick COBOL
program to check it out. My ISPF statistics tell me that I finished the
program at 3:45AM so it can't be that hard.

Basically I defined a structure that looks like the key should. in this
particular case the record is called DSAL and the index is DSAL-INDX2. And
its key looks like this.

002900 *
003000 * WORK FIELDS
003100 *
003200 01 KEYS.
003300 02 SR8-KEY.
003400 03 SR8-VALART PIC 9.
003500 03 SR8-VALNR PIC 9(6).
003600 03 SR8-LAGER-ART PIC X.
003700 03 SR8-BESTAND PIC S9(11)V9(6) COMP-3.

In the actual main bit of the code I did this:

012300 RETURN W-DBKEY FROM DSAL-INDX2 FIRST
012400 KEY INTO SR8-KEY
012500 PERFORM UNTIL ANY-ERROR-STATUS
012600 ADD 1 TO DSAL-READ-CNT READ-SINCE-DISPLAY
012700 OBTAIN DB-KEY W-DBKEY
012800 PERFORM IDMS-STATUS
012900 IF DSAL-JB-VALART = SR8-VALART
013000 AND DSAL-JB-VALNR = SR8-VALNR
013100 AND DSAL-LAGER-ART = SR8-LAGER-ART
013200 AND DSAL-BESTAND = SR8-BESTAND
013300 THEN
013400 ADD 1 TO DSAL-OK
013500 ELSE
013600 ADD 1 TO DSAL-NOT-OK
013700 DISPLAY 'DSAL NOT OK'
013800 MOVE 0 TO PAGE9
013900 MOVE DBKEYX(1:3) TO PAGEX(2:3)
014000 MOVE 0 TO LINE9
014100 MOVE DBKEYX(4:1) TO LINEX(2:1)
014200 DISPLAY 'DBKEY = ' PAGE9 '-' LINE9
014300 DISPLAY 'SR8 KEY=' SR8-VALART SR8-VALNR
014400 SR8-LAGER-ART SR8-BESTAND
014500 DISPLAY 'REC KEY=' DSAL-JB-VALART DSAL-JB-VALNR
014600 DSAL-LAGER-ART DSAL-BESTAND
014700 END-IF
014800 IF READ-SINCE-DISPLAY > 9999
014900 THEN
015000 PERFORM PRINT-STATS
015100 END-IF
015200 RETURN W-DBKEY FROM DSAL-INDX2 NEXT
015300 KEY INTO SR8-KEY
015400 END-PERFORM
015500 IF ERROR-STATUS NOT = '1707'
015600 THEN
015700 PERFORM IDMS-STATUS
015800 END-IF.


So basically I pull the key out of the SR8. Then I use the DBkey from the
SR8 to pull out the real record and then I compare the key from the SR8
with the key in the record.

This works fine. As you can see, at 3 in the morning I don't waste a lot
of time with comments.

For the non German speakers amongst you - LAGER - is a store and not a
yellow bubbly drink which makes you fall down. That is called Stella -
Pete Charles taught me that.

I also wrote a program to do all the indexes here by reading the index
definitions from the schema and generating the code automatically but that
is a bit more complicated. But you can have it if you want.


Mit freundlichen Grüssen
--------------------------------------------------------------------------------------
Chris Trayler, IXD
Bank Julius Bär & Co. AG
Hohlstrasse 602, CH-8010 Zurich, Switzerland
Telephone +41 (0) 58 887 43 32
Christopher.Trayler@juliusbaer.com, www.juliusbaer.com
--------------------------------------------------------------------------------------



iain.dk.robertson@BT.COM
Sent by: IDMS Public Discussion Forum <IDMS-L@LISTSERV.IUASSN.COM>
13.09.2006 13:41
Please respond to
IDMS Public Discussion Forum <IDMS-L@LISTSERV.IUASSN.COM>


To
IDMS-L@LISTSERV.IUASSN.COM
cc

Subject
HYPER Q075370






This fixed the following problem:

""Indexes where compression of index keys has been defined can be corrupted
during the insertion of a
record into the SR8. This is most likely to occur when adjacent records
share a significant number of
equal leading positions.""

But existing indexes may still need to be rebuilt, if they prove to be
corrupted.

We've identified several indexes on our databases which potentially have
this problem. Rather than simply rebuild the index,
which could take too long, we plan on writing a generalised program to
check if any of our indexes are corrupted.

Before we start on writing this, has anyone else written code to do this,
which they'd be prepared to share?

Iain Robertson
British Telecom
iain.dk.robertson@bt.com




*****Disclaimer*****
This message is for the addressee only and may contain confidential or privileged information. You must delete and not use it if you are not the intended recipient. It may not be secure or error-free. All e-mail communications to and from the Julius Baer Group may be monitored. Processing of incoming e-mails cannot be guaranteed. Any views expressed in this message are those of the individual sender. This message is for information purposes only. All liability of the Julius Baer Group and its entities for any damages resulting from e-mail use is excluded. US persons are kindly requested to read the important legal information presented at following URL: http://www.juliusbaer.com/maildisclaimer
"
IDMS Public Discussion Forum
IDMS-L@LISTSERV.IUASSN.COM
SMTP
IDMS-L@LISTSERV.IUASSN.COM
IDMS-L@LISTSERV.IUASSN.COM
SMTP








Normal

Normal
Re: HYPER Q075370
"Chris,
Having meet before with Pete Charles during non-business hours, I have a
question. Did he teach you that LAGER is a store, or how to drink a
yellow bubbly drink that makes you fall down?

BTW, thanks for the example of the COBOL code.


Dan Hall
GE
Capital Solutions
Danbury, CT

T 513.217.5060
E dan.hall@ge.com
http://www.ge.com/capitalsolutions/

Outcomes