CA IDMS IUA EIUA

Expand all | Collapse all

Duplicate SR7 records in an index

  • 1.  Duplicate SR7 records in an index

    Posted 10-04-2009 05:37 PM
    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


  • 2.  Re:Duplicate SR7 records in an index

    Posted 10-04-2009 05:37 PM
    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


  • 3.  RE: Duplicate SR7 records in an index

    Posted 10-05-2009 06:39 AM
    It looks to me like you have a problem with your reload DMCL, a different
    set of page ranges are being fed into the CALC algorithm. I would check
    this our

    Dennis Robock
    Alberta Department of Energy
    Canada


  • 4.  Re:RE: Duplicate SR7 records in an index

    Posted 10-05-2009 06:39 AM
    It looks to me like you have a problem with your reload DMCL, a different
    set of page ranges are being fed into the CALC algorithm. I would check
    this our

    Dennis Robock
    Alberta Department of Energy
    Canada


  • 5.  Re:Re: Duplicate SR7 records in an index

    Posted 10-05-2009 10:46 AM
    It looks to me like you have a problem with your reload DMCL, a
    different set of page ranges for the index area are being fed into the
    CALC algorithm. I would check this out

    Dennis Robock
    Alberta Department of Energy
    Canada


  • 6.  Re: Duplicate SR7 records in an index

    Posted 10-05-2009 10:46 AM
    It looks to me like you have a problem with your reload DMCL, a
    different set of page ranges for the index area are being fed into the
    CALC algorithm. I would check this out

    Dennis Robock
    Alberta Department of Energy
    Canada=20


  • 7.  Re: Duplicate SR7 records in an index

    Posted 10-05-2009 11:22 AM
    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 3rd-party providers forum
    IDMSVENDOR-L@LISTSERV.IUASSN.COM
    SMTP
    IDMSVENDOR-L@LISTSERV.IUASSN.COM
    IDMSVENDOR-L@LISTSERV.IUASSN.COM
    SMTP








    Normal

    Normal
    Re: Duplicate SR7 records in an index
    "Hello Tommy:

    That is the problem. I created a new DMCL and segment for the U/R by
    punching the DMCL to source and the segment to source, changing their names
    changing the page range of the area that I was unloading and added them
    back. As you can see in the new segment the EXTEND SPACE was lost and that
    is why the U/R created a new SR7.

    Thanks so much for your time and support. Wow EXTEND SPACE is very
    dangerous.

    CREATE
    PHYSICAL AREA ARCHSEGM.CAS-IXPODIS-AREA
    PRIMARY SPACE 11550 PAGES FROM PAGE 4765001
    MAXIMUM SPACE 11550 PAGES
    PAGE SIZE 3860 CHARACTERS
    WITHIN FILE CAS13F56
    FROM 1 FOR 5775 BLOCKS
    WITHIN FILE CAS13F67
    FROM 1 FOR 5775 BLOCKS
    ;

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


  • 8.  Re:Re: Duplicate SR7 records in an index

    Posted 10-05-2009 11:22 AM
    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.