Bill,
Are you using the production DMCL your unload/reload, or did you create a
new DMCL and segment just for the unload/reload?
The extended area in the new segment would need to be created using the old
page range and then be extended, otherwise it will just be a larger area.
Tommy Petersen
""William M.
Allen, jr.""
<archcons@BELLSOU To
TH.NET>
IDMS-L@LISTSERV.IUASSN.COM
Sent by: IDMS cc
Public Discussion
Forum Subject
<IDMS-L@LISTSERV. Duplicate SR7 records in an index
IUASSN.COM>
10/04/2009 10:15
PM
Please respond to
archcons@bellsout
h.net
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: Looking for SUBSCHEMA-RECNAMES
"There are a variety of COPY IDMS ..... options, each of which will copy mor=
e or less of the communication areas required to access an IDMS database. T=
he areas required are listed below:
SUBSCHEMA-CTRL: the primary communication control block with DBMS, contains=
run-time call parameters, current DBKEY, ERROR-STATUS and so forth. This a=
ctually exists as an IDMS record - there are different version depending on=
the PROTOCOL being used. The ERROR-STATUS field has a predefined set of 88=
levels for convenient error condition checks (you don't need to remember t=
he numeric codes). I have seen some shops modify this record to include new=
88 levels for error conditions that are commonly tested for at those shops=
. COPY IDMS forms that include this data area:
SUBSCHEMA-DESCRIPTION, SUBSCHEMA-CONTROL, SUBSCHEMA-CTRL.
SUBSCHEMA-SSNAME: the 8 character literal containing the subschema name - u=
sed in the Run Unit BIND but that is the only CALL that it is required for=
. COPY IDMS forms that include this data area:
SUBSCHEMA-DESCRIPTION, SUBSCHEMA-CONTROL, SUBSCHEMA-SSNAME.
SUBSCHEMA-RECNAMES: copies the literal names of all database records includ=
ed in the subschema. The actual data name (if you need to reference it) is =
SRnnnn, where the nnnn is the schema assigned Schema Record ID (SRID). The =
literal itself contains the record name associated with the given SRID. COP=
Y IDMS forms that include this data area:
SUBSCHEMA-DESCRIPTION, SUBSCHEMA-CONTROL, SUBSCHEMA-NAMES, SUBSCEHMA-RECNAM=
ES.
SUBSCHAMA-AREANAMES: copies the literal names of all database areas include=
d in the subschema. The actual data name (if you need to reference it) is t=
he same as the AREA Name. The literal itself contains the area name. COPY I=
DMS forms that include this data area:
SUBSCHEMA-DESCRIPTION, SUBSCHEMA-CONTROL, SUBSCHEMA-NAMES, SUBSCHEMA-AREANA=
MES.
SUBSCHAMA-SETNAMES: copies the literal names of all database sets included =
in the subschema. The actual data name (if you need to reference it) is the=
same as the SET Name. The literal itself contains the set name. COPY IDMS =
forms that include this data area:
SUBSCHEMA-DESCRIPTION, SUBSCHEMA-CONTROL, SUBSCHEMA-NAMES, SUBSCHEMA-SETNAM=
ES.
SUBSCHEMA-RECORDS: copies the (IDD Record Synonym) descriptions of all reco=
rds contained in the subschema
Too look at it another way - here is what is copied by various ""cumulative""=
forms of the COPY command:
SUBSCHEMA-DESCRIPTION copies SUBSCHEMA-SSNAME, SUBSCHEMA-CTRL, SUBSCHEMA-RE=
CNAMES, SUBSCHEMA-SETNAMES, SUBSCHEMA-AREANAMES, SUBSCHEMA-RECORDS.
SUBSCHEMA-CONTROL copies SUBSCHEMA-SSNAME, SUBSCHEMA-CTRL, SUBSCHEMA-RECNA=
MES, SUBSCHEMA-SETNAMES, SUBSCHEMA-AREANAMES.
SUBSCHEMA-NAMES copies SUBSCHEMA-SSNAME, SUBSCHEMA-RECNAMES, SUBSCHEMA-SETN=
AMES, SUBSCHEMA-AREANAMES.
Which form of the COPY statement you use depends on how much control of whe=
re you want the different areas copied into - some into Working Storage and=
some into Linkage Storage for example!
Do not forget the COPY IDMS SUBSCHEMA-BINDS - this will initialise PROGRAM-=
NAME in SUBSCHEMA-CTRL, create a BIND RUN UNIT statement and will create BI=
ND RECORD statements either for all records in the subschema, or if PROTOCO=
L .... MANUAL ... has been specified will create Record BIND statements onl=
y for the explicitly copied IDMS Records (with the COPY IDMS SUBSCHEMA-REC=
ORD statements).
Sections 4.4 and 4.5 of the CA-IDMS Reference - Cobol manual restates all o=
f this, slightly differently, again.
HTH - cheers - Gary
Gary Cherlet
Justice Technology Services
Department of Justice, SA Government
"""""""" Telephone +61 (0)8 8226 5199
@@ Facsimile +61 (0)8 8226 5311
> Mobile +61 (0)41 333 1613
\/ MailTo:
gary.cherlet@sa.gov.au
Murphy says:
1. ""Everything is a system.""
2. ""Everything is part of a larger system.""
3. ""The universe is infinitely systematized both upward (larger systems) an=
d downward (smaller systems).""
4. ""All systems are infinitely complex (the illusion of simplicity comes fr=
om focusing attention on one or a few variables).""
This e-mail message and any attachments are qualified as follows: Addressin=
g: If you have received this e-mail in error, please advise by reply e-mai=
l to the sender. Please also destroy the original transmission and its con=
tents. Confidentiality: This e-mail may contain confidential information w=
hich also may be legally privileged. Only the intended recipient(s) may ac=
cess, use, distribute or copy this e-mail. Individual Views: Unless otherw=
ise indicated, the views expressed are those of the sender, not Justice Tec=
hnology Services. Computer Viruses: It is the recipient's responsibility t=
o check the e-mail and any attached files for viruses.