ca.portal.admin

Re:Re: [IDMSVENDOR-L] Duplicate SR7 records in an index

Discussion created by ca.portal.admin on Oct 4, 2009
this is all conjecture on my part:

did you specify the index area as an area to unload? or just the data
area?
if you specified the index area - it would have done an area sweep - and
since the index name is not stored on a sr7 or sr8 - all of them would
have been picked up - only to have no data records pointing to them in the
reload steps - this is the same problem that can occur in DBANS - if you
run a dban against an area with multiple sr7s/sr8s - you must specify all
the sets using the indexes - else dban will not know which sr7-8 belongs
to what set as it pulls the area off the database

if you did NOT specify the index area - but rather allowed the index
entries to be picked up from the member records - would you have had the
same results - i would have thought not - but if it dies ana rea sweep
anyhow - then you might have had the same incident

but how did this happen - a set dropped from the Schema byt not first
deleted from the data? or (even worse) - are there two (or more)
independent schemas that include the area - with different set/record
definitions - please do not laugh - i have seen it done (but i didnt do it
- not me - that's my story and i am sticking to it !!!)


Chris Hoelscher
Senior IDMS & DB2 Database Administrator
Humana Inc
502-476-2538
choelscher@humana.com

you only need to test the programs that you want to work correctly






From:
""William M. Allen, jr."" <archcons@BELLSOUTH.NET>
To:
IDMSVENDOR-L@LISTSERV.IUASSN.COM
Date:
10/04/2009 10:14 PM
Subject:
[IDMSVENDOR-L] Duplicate SR7 records in an index
Sent by:
IDMS 3rd-party providers forum <IDMSVENDOR-L@LISTSERV.IUASSN.COM>



Hello All:



Has anyone experienced this situation? When performing an unload/reload
this
weekend I received a 0711 in DBL3 on a system owned index on the records
stored in the area that was unloaded. Only the data area was unloaded.



I also received 900,000 UT008010 & UT008011 messages from the DBLX step.



I knew the index would be part of the maintenance but I did not anticipate
the index area being full during the U/R.



I then ran a print space on the index area and found two SR7 Records in
the
index area. The schema definition only had one index stored in the area.



So I formatted the index files and did an index rebuild from ALLROWS, it
ran
fine and the index area had 64% space available and only one SR7 record in
the index area and about 400,000 less SR8 Records.



I then re-executed the Unload/Reload and it executed successfully without
the 900,000 error messages and no space problems. I think the error
messages
were caused because there were two sets of indexes (SR7 & SR8) in the
index
area. The U/R does an area sweep and only one of the index sets were
actually pointing from the index structure to the member records?



After the U/R out of curiosity I ran another print space on the index
again
and once again it had two SR7 records?



The IDMS release is 15.0 SP2, soon to be 17.0 SP1.



So once again I formatted the index files and did an index rebuild, all is
well at this time.



I can find nothing on support connect regarding this issue, there is
absolutely nothing strange about the Schema or Subschema, but the previous
DBA did an extend space on the Index Area and added a second file.



This is repeatable; it will do it every time. I repeated the maintenance
on
a TEST LPAR and it did exactly the same thing. I have never seen this
before
and I believe that it may have something to do with the EXTEND SPACE on
the
index area?



DIS AREA CASSCHEM.CAS-IXPODIS-AREA;

*+ Status = 0        SQLSTATE = 00000

*+   CREATE

*+   PHYSICAL AREA CASSCHEM.CAS-IXPODIS-AREA

*+       CREATED 1998-06-10-10.48.59.128023   BY USMST07

*+       LAST UPDATED 2004-10-06-16.11.34.271494   BY UMCTS17

*+       LAST CRITICAL CHANGE 2004-10-06-16.11.34.271494

*+       FOR NONSQL

*+       PAGE GROUP 0

*+       PRIMARY SPACE 11550 PAGES  FROM PAGE 4765001

+       ** PRIMARY SPACE HAS BEEN EXTENDED ***

*+       ORIGINAL PRIMARY SPACE 5775 PAGES

*+       MAXIMUM SPACE 11550 PAGES

*+       PAGE SIZE 3860 CHARACTERS

*+       WITHIN FILE CAS13F56

*+           FROM 1 FOR 5775 BLOCKS

*+           MAP TO PAGES 4765001 THRU 4770775

*+       WITHIN FILE CAS13F67

*+           FROM 1 FOR 5775 BLOCKS

*+           MAP TO PAGES 4770776 THRU 4776550

*+       ;



Bill Allen

ARCH Consulting Associates, LTD.

(704) 641-0296



The information transmitted is intended only for the person or entity to
which it is addressed and may contain CONFIDENTIAL material. If you receive
this material/information in error, please contact the sender and delete or
destroy the material/information.
"
IDMS Public Discussion Forum
IDMS-L@LISTSERV.IUASSN.COM
SMTP
IDMS-L@LISTSERV.IUASSN.COM
IDMS-L@LISTSERV.IUASSN.COM
SMTP








Normal

Normal
this is a test
"Testing the IDMS-L interface.

Bob Wiklund
IUA Board

Tiburon Technologies
623 594-6022
"
IDMS Public Discussion Forum
IDMS-L@LISTSERV.IUASSN.COM
SMTP
IDMS-L@LISTSERV.IUASSN.COM
IDMS-L@LISTSERV.IUASSN.COM
SMTP








Normal

Normal
XA REENTRANT PROGRAM POOL
"Hello All:



Does anyone out there have an XA REEENTRANT PROGRAM POOL larger that 32760?



If so how large is yours and have you seen any repercussions from this large
a pool especially on the Operating System?



William M. Allen, Jr.

ARCH Consulting Associates, Ltd.

(704) 641-0296
"
IDMS Public Discussion Forum
IDMS-L@LISTSERV.IUASSN.COM
SMTP
IDMS-L@LISTSERV.IUASSN.COM
IDMS-L@LISTSERV.IUASSN.COM
SMTP








Normal

Normal
Re: XA REENTRANT PROGRAM POOL
"No, my largest is 29868K:

I've never seen with ""DCMT DISPLAY ACTIVE REENTRANT PROGRAMS"",=20
Loads overlaying program not in use 0 0% of loads=20
Loads overlaying program in use 0 0% of loads
Not being zero's.

Outcomes