ca.portal.admin

Re:Looking for SUBSCHEMA-RECNAMES

Discussion created by ca.portal.admin on Oct 2, 2009
Hi all,

We have a number of DC-COBOL programs that include in their Working Storage section lines such as COPY IDMS SUBSCHEMA-RECNAMES or COPY IDMS SUBSCHEMA-SSNAME

The DMLC pre-compiler expands these quite happily, so obviously they exist in some dictionary. However, I cannot find them using IDD or IDMSDDDL DIS REC SUBSCHEMA-RECNAMES V HIGH. I have searched all of the usual places: our default secondary dictionary, SYSDIRL, APPLDICT, SYSTEM.

Does anybody have any idea where these puppies are hiding?

Thanks,

Jim Ritterbusch
Database Administrator
GE Capital
83 Wooster Heights Rd
5th Floor South
Danbury, CT 06810
T (203) 546 4370
"
IDMS Public Discussion Forum
IDMS-L@LISTSERV.IUASSN.COM
SMTP
IDMS-L@LISTSERV.IUASSN.COM
IDMS-L@LISTSERV.IUASSN.COM
SMTP








Normal

Normal
Change Dbname when coming from CICS.
"We have been working on a problem of trying to change the dbname when
coming from a certain CICS region. It appears that the UCF interface get
handled differently than other transactions. We tried using Exit23 but
it does not appear to work all the time. We have Exit04 working that can
detect the particular CICS region we want but Exit04 cannot put in a new
dbname that we can see. We have multiple CICS regions going into the
same CV, each CICS region has it's own identifier which is how we can
detect the region.

In addition to normal users signing onto IDMS from CICS, we have
transactions that call the IDMS interface and get data so there is no
explicit signon to trap. We have the same users and same transactions
coming from different CICS regions.

Anyone have any ideas on how to detect and change the dbname so the any
transactions can be routed to a new environment?

Will Hathcock
Sempra Energy Utilities
Database Administrator
(719) 495-6177

Never let reality get in the way of your perception
"
IDMS 3rd-party providers forum
IDMSVENDOR-L@LISTSERV.IUASSN.COM
SMTP
IDMSVENDOR-L@LISTSERV.IUASSN.COM
IDMSVENDOR-L@LISTSERV.IUASSN.COM
SMTP








Normal

Normal
Change Dbname when coming from CICS.
"We have been working on a problem of trying to change the dbname when
coming from a certain CICS region. It appears that the UCF interface get
handled differently than other transactions. We tried using Exit23 but
it does not appear to work all the time. We have Exit04 working that can
detect the particular CICS region we want but Exit04 cannot put in a new
dbname that we can see. We have multiple CICS regions going into the
same CV, each CICS region has it's own identifier which is how we can
detect the region.

In addition to normal users signing onto IDMS from CICS, we have
transactions that call the IDMS interface and get data so there is no
explicit signon to trap. We have the same users and same transactions
coming from different CICS regions.

Anyone have any ideas on how to detect and change the dbname so the any
transactions can be routed to a new environment?

Will Hathcock
Sempra Energy Utilities
Database Administrator
(719) 495-6177

Never let reality get in the way of your perception
"
IDMS Public Discussion Forum
IDMS-L@LISTSERV.IUASSN.COM
SMTP
IDMS-L@LISTSERV.IUASSN.COM
IDMS-L@LISTSERV.IUASSN.COM
SMTP








Normal

Normal
Re: Change Dbname when coming from CICS.
"Hi Will,

We are using Exit 23 for the last 20 years and have not detected a failure.=
I'm convinced it does get called on every BIND RU. But, then again, who =
knows?

So, unless you did the following, you may want to check the Exit 23 coding =
one more time to detect a logic flow allowing passage through the code with=
no DBNAME change. You can verify it is or is not being called with memory=
writes of debugging info to locations available after execution or SNAPS (=
I don't remember if they are allowed in EXIT code, but I don't see why you =
couldn't).


Take Care,
Bruce
NAVSISA - (717) 605-2019 DSN 430-2019
Cell - (610) 468-9506



From: Hathcock, Will
Sent: Sun 10/4/2009 1:12 AM
To: IDMS-L@LISTSERV.IUASSN.COM
Subject: Change Dbname when coming from CICS.


We have been working on a problem of trying to change the dbname when
coming from a certain CICS region. It appears that the UCF interface get
handled differently than other transactions. We tried using Exit23 but
it does not appear to work all the time. We have Exit04 working that can
detect the particular CICS region we want but Exit04 cannot put in a new
dbname that we can see. We have multiple CICS regions going into the
same CV, each CICS region has it's own identifier which is how we can
detect the region.

In addition to normal users signing onto IDMS from CICS, we have
transactions that call the IDMS interface and get data so there is no
explicit signon to trap. We have the same users and same transactions
coming from different CICS regions.

Anyone have any ideas on how to detect and change the dbname so the any
transactions can be routed to a new environment?

Will Hathcock
Sempra Energy Utilities
Database Administrator
(719) 495-6177

Never let reality get in the way of your perception
"
IDMS 3rd-party providers forum
IDMSVENDOR-L@LISTSERV.IUASSN.COM
SMTP
IDMSVENDOR-L@LISTSERV.IUASSN.COM
IDMSVENDOR-L@LISTSERV.IUASSN.COM
SMTP








Normal

Normal
Re: Change Dbname when coming from CICS.
"Hi Will,

We are using Exit 23 for the last 20 years and have not detected a failure. I'm convinced it does get called on every BIND RU. But, then again, who knows?

So, unless you did the following, you may want to check the Exit 23 coding one more time to detect a logic flow allowing passage through the code with no DBNAME change. You can verify it is or is not being called with memory writes of debugging info to locations available after execution or SNAPS (I don't remember if they are allowed in EXIT code, but I don't see why you couldn't).


Take Care,
Bruce
NAVSISA - (717) 605-2019 DSN 430-2019
Cell - (610) 468-9506



From: Hathcock, Will
Sent: Sun 10/4/2009 1:12 AM
To: IDMS-L@LISTSERV.IUASSN.COM
Subject: Change Dbname when coming from CICS.


We have been working on a problem of trying to change the dbname when
coming from a certain CICS region. It appears that the UCF interface get
handled differently than other transactions. We tried using Exit23 but
it does not appear to work all the time. We have Exit04 working that can
detect the particular CICS region we want but Exit04 cannot put in a new
dbname that we can see. We have multiple CICS regions going into the
same CV, each CICS region has it's own identifier which is how we can
detect the region.

In addition to normal users signing onto IDMS from CICS, we have
transactions that call the IDMS interface and get data so there is no
explicit signon to trap. We have the same users and same transactions
coming from different CICS regions.

Anyone have any ideas on how to detect and change the dbname so the any
transactions can be routed to a new environment?

Will Hathcock
Sempra Energy Utilities
Database Administrator
(719) 495-6177

Never let reality get in the way of your perception
"
IDMS Public Discussion Forum
IDMS-L@LISTSERV.IUASSN.COM
SMTP
IDMS-L@LISTSERV.IUASSN.COM
IDMS-L@LISTSERV.IUASSN.COM
SMTP








Normal

Normal
Re: Change Dbname when coming from CICS.
"here is an exit23 we use to change a dbname based on subschema name
I am not a cics expert, but if you can walk memory t5o find the name of
the originating CICS region, you whould be able to change the DBNAME

TITLE 'EXIT 23 - PRE BIND EXIT'
UT23EXIT #MOPT ENV=SYS,AMODE=31,RMODE=ANY
UT23EXIT CSECT
UT23EP1 #START MPMODE=ANY
USING CSA,R10
L R2,4(,R1) R2 ==> 40 BYTE DATA AREA
USING PARMAREA,R2
TEST1 CLC PSSCNAM,=CL8'SSTGHRT ' IS THIS FOR DEV SPC RETRIEVAL?
BNE TEST2 NO! TRY QA/PROD
MVC PDBNAME,=CL8'SCDGHRT ' OVERRIDE DBNAME
B RETURN EXIT
TEST2 CLC PSSCNAM,=CL8'SSPGHRT ' IS THIS FOR QA/PRD SPC RETR
BNE RETURN NO! JUST EXIT
MVC PDBNAME,=CL8'SCPGHRT ' OVERRIDE DBNAME
RETURN #RTN RETURN TO CALLER
LTORG
COPY #CSADS
PARMAREA DSECT
PSSCNAM DS CL8 SSC NAME
PDBNODE DS CL8 DATABASE NODE
PDBNAME DS CL8 DATABASE NAME
PDICNOD DS CL8 DICTIONARY NODE
PDICNAM DS CL8 DICTIONARY NAME
END


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:
""Hathcock, Will"" <WHathcock@SEMPRAUTILITIES.COM>
To:
IDMSVENDOR-L@LISTSERV.IUASSN.COM
Date:
10/04/2009 01:15 AM
Subject:
[IDMSVENDOR-L] Change Dbname when coming from CICS.
Sent by:
IDMS 3rd-party providers forum <IDMSVENDOR-L@LISTSERV.IUASSN.COM>



We have been working on a problem of trying to change the dbname when
coming from a certain CICS region. It appears that the UCF interface get
handled differently than other transactions. We tried using Exit23 but
it does not appear to work all the time. We have Exit04 working that can
detect the particular CICS region we want but Exit04 cannot put in a new
dbname that we can see. We have multiple CICS regions going into the
same CV, each CICS region has it's own identifier which is how we can
detect the region.

In addition to normal users signing onto IDMS from CICS, we have
transactions that call the IDMS interface and get data so there is no
explicit signon to trap. We have the same users and same transactions
coming from different CICS regions.

Anyone have any ideas on how to detect and change the dbname so the any
transactions can be routed to a new environment?

Will Hathcock
Sempra Energy Utilities
Database Administrator
(719) 495-6177

Never let reality get in the way of your perception



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 3rd-party providers forum
IDMSVENDOR-L@LISTSERV.IUASSN.COM
SMTP
IDMSVENDOR-L@LISTSERV.IUASSN.COM
IDMSVENDOR-L@LISTSERV.IUASSN.COM
SMTP








Normal

Normal
Re: [IDMSVENDOR-L] Change Dbname when coming from CICS.
"here is an exit23 we use to change a dbname based on subschema name
I am not a cics expert, but if you can walk memory t5o find the name of
the originating CICS region, you whould be able to change the DBNAME

TITLE 'EXIT 23 - PRE BIND EXIT'
UT23EXIT #MOPT ENV=SYS,AMODE=31,RMODE=ANY
UT23EXIT CSECT
UT23EP1 #START MPMODE=ANY
USING CSA,R10
L R2,4(,R1) R2 ==> 40 BYTE DATA AREA
USING PARMAREA,R2
TEST1 CLC PSSCNAM,=CL8'SSTGHRT ' IS THIS FOR DEV SPC RETRIEVAL?
BNE TEST2 NO! TRY QA/PROD
MVC PDBNAME,=CL8'SCDGHRT ' OVERRIDE DBNAME
B RETURN EXIT
TEST2 CLC PSSCNAM,=CL8'SSPGHRT ' IS THIS FOR QA/PRD SPC RETR
BNE RETURN NO! JUST EXIT
MVC PDBNAME,=CL8'SCPGHRT ' OVERRIDE DBNAME
RETURN #RTN RETURN TO CALLER
LTORG
COPY #CSADS
PARMAREA DSECT
PSSCNAM DS CL8 SSC NAME
PDBNODE DS CL8 DATABASE NODE
PDBNAME DS CL8 DATABASE NAME
PDICNOD DS CL8 DICTIONARY NODE
PDICNAM DS CL8 DICTIONARY NAME
END


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:
""Hathcock, Will"" <WHathcock@SEMPRAUTILITIES.COM>
To:
IDMSVENDOR-L@LISTSERV.IUASSN.COM
Date:
10/04/2009 01:15 AM
Subject:
[IDMSVENDOR-L] Change Dbname when coming from CICS.
Sent by:
IDMS 3rd-party providers forum <IDMSVENDOR-L@LISTSERV.IUASSN.COM>



We have been working on a problem of trying to change the dbname when
coming from a certain CICS region. It appears that the UCF interface get
handled differently than other transactions. We tried using Exit23 but
it does not appear to work all the time. We have Exit04 working that can
detect the particular CICS region we want but Exit04 cannot put in a new
dbname that we can see. We have multiple CICS regions going into the
same CV, each CICS region has it's own identifier which is how we can
detect the region.

In addition to normal users signing onto IDMS from CICS, we have
transactions that call the IDMS interface and get data so there is no
explicit signon to trap. We have the same users and same transactions
coming from different CICS regions.

Anyone have any ideas on how to detect and change the dbname so the any
transactions can be routed to a new environment?

Will Hathcock
Sempra Energy Utilities
Database Administrator
(719) 495-6177

Never let reality get in the way of your perception



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
Duplicate SR7 records in an index
"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
"
IDMS 3rd-party providers forum
IDMSVENDOR-L@LISTSERV.IUASSN.COM
SMTP
IDMSVENDOR-L@LISTSERV.IUASSN.COM
IDMSVENDOR-L@LISTSERV.IUASSN.COM
SMTP








Normal

Normal
Duplicate SR7 records in an index
"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
"
IDMS Public Discussion Forum
IDMS-L@LISTSERV.IUASSN.COM
SMTP
IDMS-L@LISTSERV.IUASSN.COM
IDMS-L@LISTSERV.IUASSN.COM
SMTP








Normal

Normal
Re: Duplicate SR7 records in an index
"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 3rd-party providers forum
IDMSVENDOR-L@LISTSERV.IUASSN.COM
SMTP
IDMSVENDOR-L@LISTSERV.IUASSN.COM
IDMSVENDOR-L@LISTSERV.IUASSN.COM
SMTP








Normal

Normal
Re: [IDMSVENDOR-L] Duplicate SR7 records in an index
"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
Duplicate SR7 records in an index
"Hello Chris:

I unloaded the data area only. The index name is in the SR7, the SR7 is a
CALC record and the CALC key is the set name. I reviewed the Schema and
there was only one (1) set with the index structure stored in the index
area. I even re-compiled the Subschema and examined it with IDMSLOOK. Plus
remember that I rebuilt the index using the exact same subschema as the U/R.
After the index rebuild there was one SR7, then I immediately followed up
the index rebuild with the U/R and immediately after the U/R there were two
(2) SR7 records again in the index area.

I think that it has something to do with the EXTEND SPACE and the fact that
an SR7 is a CALC record? I have never had an index area that was EXTENDED
before; this is a first for me. I should have fixed it before the index
rebuild.

William M. Allen, Jr.
ARCH Consulting Associates, Ltd.
(704) 641-0296

Outcomes