IDMS

Expand all | Collapse all

Backing out an extend area

  • 1.  Backing out an extend area

    Posted Dec 05, 2018 10:25 AM

    I'm sure this wont be fun but have to back out or undo an extend area because of broken chain problems.  This area has system index and problems. 

     

    I was thinking of unload / load using the same DMCL that has the NEW page range(done during the extend space) loading into a NEW file with the increased DASD space.

     

    I had to do a ALTER when I did the original extend space.  I'm not sure how to change the below statement to point to the NEW file?

    ALTER PHYSICAL AREA IASCHEMA.AR-EIEMPL-ADUSER
     EXTEND SPACE 225 PAGES
     WITHIN FILE X331001x
     FROM 1 FOR all BLOCKS
     ; 

    Vary area offline or stop the CV.  Is there a way to vary the area offline if the dsn is in the CV startup JCL?

    I will have to rename the current file to ***.old.

    I will have to create, format, rename(to original name) the new file.

    I will have to do a DMCL newcopy.

     

    What else am I missing?  Is there a better way to do this?

     

    Mike



  • 2.  Re: Backing out an extend area

    Posted Dec 05, 2018 10:56 AM

    Mike,

    I have to say that it seems to me that you are doing things here that you really don't have the experience or training to do. We can only provide so much guidance in this forums. Also, it wouldn't hurt if you posted some resolution to your issues. You ask for help and then don't tell us what the final solution/issue was. That can help others who might run into the same problem, but it is also a polite thing to do for the people who tried to help you.

     

    I am not sure you are going to be able to unload/reload a database with broken chains. Unload/reload is not designed to fix broken chains. You can try, but I would not be surprised if it fails. It will depend on exactly what is broken though.

     

    I usually drop and re-add an area that has been extended. It just tends to be the best way to get it back cleanly. 

     

    You should be able to issue a DCMT VARY FILE segment.file DEALLOCATE to deallocate the file from a running CV so that you can rename your file (vary area offline first of course). Though I am not 100% sure if that works when the files are in the startup JCL. You should really consider converting to dynamic allocation, it makes life so much easier.

     

    As for a better way? It's really hard to say without knowing more details on what chains are broken and maybe how they got broken. Like I said, unload/reload is possibly not going to help. If it is just a system index that is broken, maybe you just need to rebuild the index?

     

    Regards,

    Steve



  • 3.  Re: Backing out an extend area

    Posted Dec 05, 2018 11:03 AM

    To follow up – I wouldn’t do anything until you know how you got broken chains in the first place

     

    Chris Hoelscher

    Technology Architect, Database Infrastructure Services

    Technology Solution Services

    Humana Inc.

    123 East Main Street

    Louisville, KY 40202

    Humana.com

    (502) 476-2538 or 407-7266



  • 4.  Re: Backing out an extend area

    Posted Dec 05, 2018 11:26 AM

    Steve,

    Thanks for the guidance.  I will post a resolution when I have one.  We've been fighting this fire for 3 weeks or so.  I finding out now all this issues I posted here are related to this extend area problem.  This is the only forum I'm able to use since my customer is running a self-service release.  A appreciate any input and hopefully I can piece together input from this forum to create a viable solution.  Thanks again for the input.  Mike B.    



  • 5.  Re: Backing out an extend area

    Posted Dec 05, 2018 10:59 AM

    You can’t directly ??? you simply can’t drop the area definition – you would lose the rows in the extended file

     

    If you can, you need to unload all rows from the area into an area without the extend – recreate the area without the extend – then unload/load BACK TO THE original area

     

     

    Chris Hoelscher

    Technology Architect, Database Infrastructure Services

    Technology Solution Services

    Humana Inc.

    123 East Main Street

    Louisville, KY 40202

    Humana.com

    (502) 476-2538 or 407-7266



  • 6.  Re: Backing out an extend area

    Posted Dec 05, 2018 11:27 AM

    Chris,  I was able to unload the area but haven't tried to load.  Thanks for the input.  Mike B.



  • 7.  Re: Backing out an extend area

    Posted Dec 05, 2018 03:13 PM

    I ran the reload and it finished with RC4 and below errors :

    UT008010 MAPPING ERROR ON CHAINED SET IX-EIEMPL-ADUSER                                    

    UT008011    OWNER DBKEY FFFFFFFF, OLD MEMBER DBKEY 0D1F6202, NEW MEMBER DBKEY 0D1F6202    

    UT008010 MAPPING ERROR ON CHAINED SET IX-EIEMPL-ADUSER                                    

    UT008011    OWNER DBKEY FFFFFFFF, OLD MEMBER DBKEY 0D1F624A, NEW MEMBER DBKEY 0D1F624A    

    UT008010 MAPPING ERROR ON CHAINED SET IX-EIEMPL-ADUSER                                    

    UT008011    OWNER DBKEY FFFFFFFF, OLD MEMBER DBKEY 0D1F6922, NEW MEMBER DBKEY 0D1F6922    

    UT008010 MAPPING ERROR ON CHAINED SET IX-EIEMPL-ADUSER                                    

    UT008011    OWNER DBKEY FFFFFFFF, OLD MEMBER DBKEY 0D1F6A02, NEW MEMBER DBKEY 0D1F6A02    

    I guess the reload doesn't fix chained sets.  Learning every day

     

    Mike

     



  • 8.  Re: Backing out an extend area

    Posted Dec 05, 2018 03:19 PM

    The customer and I thinking about trying the below.  I'll let you know if we do it and results.  Thanks, Mike

     

    DROP AREA IASCHEMA.AR-EIEMPL-ADUSER  ;                    

    DROP FILE IASCHEMA.X3310001; 

    CREATE PHYSICAL AREA IASCHEMA.AR-EIEMPL-ADUSER                        

    PRIMARY SPACE 450 PAGES  FROM PAGE 870001                  

             MAXIMUM SPACE 450 PAGES                                    

             PAGE SIZE 2676 CHARACTERS                                  

             WITHIN FILE X3310001                                       

                 FROM 1 FOR ALL BLOCKS ;                                 

     

    CREATE

     FILE IASCHEMA.X3310001

    ASSIGN TO X3310001

    DSNAME 'IDOT.CV01.X3310001'

     NONVSAM

     ;  

    RENAME FILE IDOT.CV01.X3310001.newxxx  TO IDOT.CV01.X3310001 

    FORMAT FILE IASCHEMA.X3310001    IDOT.CV01.X3310001 

    RENAME IDOT.CV01.DBALOAD(IDMSDMCL) TO DMCL8888    

    CREATE PUNCH LINK  NEW  DMCL     

    DCMT V DMCL NC

     

    There are only 2 indexes in that area.  IX-EIEMPL-ADUSER and IX-EISLRT-NAME.  IX-EIEMPL-ADUSER is optional manual and we can write a program to disconnect all members.  We’ll write another program to reconnect the members after the change is made.  IX-EISLRT-NAME is mandatory automatic but it is the only index on the EISLRT record which has no connected records.  My plan for that one is to write a program to write all of the EISLRTs to a file and delete all of the records.  When the change is made, run a program to reload the EISLRTs.  I think this will allow us to reset the file and format the AR-EIEMPL-ADUSER area . 



  • 9.  Re: Backing out an extend area

    Posted Dec 05, 2018 03:29 PM

    It may not be that "easy". If the indexes are broken, you might find the DML to DISCONNECT or ERASE the members will fail. You may need to do some FIX PAGE's to fix the broken chains first. 



  • 10.  Re: Backing out an extend area

    Posted Dec 05, 2018 03:48 PM

    ok I forward that info to the customer.  Thank you



  • 11.  Re: Backing out an extend area

    Posted Dec 06, 2018 12:53 PM

    I received the following messages doing a OCF DROP :

    DROP FILE IASCHEMA.X3310001;                                               
    *+ Status = 1        SQLSTATE = 01000        Messages follow:              
    *+ DB004081 T445 C1M6016: FILE IASCHEMA.X3310001 dropped from DMCL IDMSDMCL


    DROP FILE IASCHEMA.X331001X ;         
    *+ Status = 0        SQLSTATE = 00000 

     

    The first file is the original file associated with original area.  The second file was part of the extend space process for the area.  Both files looked normal in the DMCL and seem to process normal.  I'm wondering why I didn't receive the DB004081 drop msg for the second file.  Does anyone know why?

    Mike



  • 12.  Re: Backing out an extend area

    Posted Dec 06, 2018 02:07 PM

    I believe it is because there was an file specification override for file X3310001 in IDMSDMCL and there was not one for X331001X.

     

    Steve



  • 13.  Re: Backing out an extend area

    Posted Dec 07, 2018 09:23 AM

    Thanks Steve.  We moving this to production next Tuesday,  I will provide an update with the results next week.   



  • 14.  Re: Backing out an extend area

    Posted Dec 13, 2018 11:05 AM

    Last Tuesday(2 days ago) we updated production using the above procedure I mentioned with the addition of a MAINTAIN INDEX process.  So far, everything seems to be working normal.  Still monitoring.  Thanks to everyone for their input.  Mike