IDMS Backup and recovery

[Vairamuthu Vadivel]

Hi, 

We would like to know the best practices followed in IDMS entire CV recovery.

Anyone faced any issue in IDMS database  which eventually ended up with the CV recovery. 
What are the possibilities we might end up with CV recovery? 

Also we should have defined all the area file datasets under one usercat?  Also usercat also should be backed up and restored from volume snap.

if the dictionary is shared across multiple cv's during the single CV recovery is possible? suppose few areas are shared across multiple cv's, it will be in update mode in one CV and read only in rest of the Cv's means if you are recovering single CV among multiple, whether i should handle the shared area recovery?   Shared files/dictionary amoung multiple CV's is a standard practice?  

Please help me to understand how the CV recovery works.

------------------------------
Thanks
Vairam
------------------------------

[Denise Basore]

Hi - Basically, how you recover depends greatly on why you need to recover. 

I'll talk about a couple of things that I see most often. 

1. Long running update jobs with no commits.

Job1 starts running and the after images are happily writing to JournalA. 

JournalA fills up. 

The system automatically switches to JournalB, offloads any committed images to tape and pushes the uncommitted images from Job1 to the front of JournalA.

Let's say for simplicity that your system only has 2 disk journals. 

JournalB fills up.   

The system switches back to JournalA, offloads what it can and pushes uncommitted images to the front of JournalB.

JournalA fills up quick this time because it still has images for Job1.

The system continues like this until all the space on the journals is filled with uncommitted images. 

Then the system comes to a halt because it has no more room to store images.

Eventually, Job1 times out and the system starts the undo process. 

You can plan for the undo process to take about as long as the job was running in the first place.

This is where people start to get impatient and cause themselves headaches. 

IDMS is really good at recovering on it's own if you give it time. But, what some people do is get impatient and cancel the CV. 

Then they bring up the CV but the CV then starts the undo process again (warmstart). So, the impatient people cancel this too and reformat the journals to eliminate the lengthy warmstart. 

Now, your database is broken and everything is locked - databases, dictionaries, catalogs - everything. 

2. Partial restores after a Local mode job that abended (or was cancelled)

In most shops, local mode jobs are not journaled. 

The only safe way to recover after a local mode update job has abended is to restore every piece of the database that is touched directly or indirectly through set connections.

I've seen people do this piecemeal and end up with a broken database. 

Whether or not the dictionary is shared only matters if you manage to break the dictionary. This doesn't happen very often. 

As far as your usercat is concerned, I would need further clarification. It's typical to have one system catalog and (maybe) multiple user catalogs depending on their purpose.

I hope it helps. 

If you want to talk about this further, you can PM me at [e-mail]

Denise