ca.portal.admin

Re: HYPER Q075370

Discussion created by ca.portal.admin on Sep 13, 2006
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 =3D SR8-VALART
013000 AND DSAL-JB-VALNR =3D SR8-VALNR
013100 AND DSAL-LAGER-ART =3D SR8-LAGER-ART
013200 AND DSAL-BESTAND =3D 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 =3D ' PAGE9 '-' LINE9
014300 DISPLAY 'SR8 KEY=3D' SR8-VALART SR8-VALNR
014400 SR8-LAGER-ART SR8-BESTAND
014500 DISPLAY 'REC KEY=3D' 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 =3D '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=FCssen
------------------------------------------------------------------------
---=
-----------
Chris Trayler, IXD
Bank Julius B=E4r & 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
priv= ileged information. You must delete and not use it if you are not
the inten= ded recipient. It may not be secure or error-free. All e-mail
communication= s to and from the Julius Baer Group may be monitored.
Processing of incomin= g e-mails cannot be guaranteed. Any views
expressed in this message are tho= se of the individual sender. This
message is for information purposes only.= All liability of the Julius
Baer Group and its entities for any damages re= sulting from e-mail use
is excluded. US persons are kindly requested to rea= d the important
legal information presented at following URL: http://www.ju=
liusbaer.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
Printing via CICS
"We route all of our IDMS prints to CICS. Sometimes a printer gets
disconnected on the IDMS side. Sometimes we can fix it by doing the
following. I don't know why this works. Can anyone explain it to me?

1) Cancel print task on CICS

2) DCMT VARY PTE Gnnn DISC
DCMT VARY PTE Gnnn OFF
DCMT VARY LTE GnnnLTRM DISC

DCMT VARY PTE Gnnn ONL
DCMT VARY LTE GnnnLTRM TO Gnnn

3) Start print task on CICS

Kay Rozeboom
State of Iowa
Information Technology Enterprise
Department of Administrative Services
Telephone: 515.281.6139 Fax: 515.281.6137
Email: Kay.Rozeboom@Iowa.Gov
"
IDMS Public Discussion Forum
IDMS-L@LISTSERV.IUASSN.COM
SMTP
IDMS-L@LISTSERV.IUASSN.COM
IDMS-L@LISTSERV.IUASSN.COM
SMTP








Normal

Normal
Changing calc key.
"We have a need to change a calc key from a 9(6) to an X(6).
Just want to confirm that a unload/reload is not required.

Thanks for your opinions.

Outcomes