On Unix a project VOC file can be set to 0 bytes by running a ExecSH in a After routine of a job with a rm command. What happened to us is the rm command was used with a job parameter, rm #filename, where the default value for #filename was ???.
You Unix gurus might know that ??? is a regular expression where each ? represents zero or one character in a pattern. If you go to your Project directory and issue the command "ls ???" you will get VOC as a return.
I will post tomorrow how to recover the project's VOC file if you do not have access to a backup.
How a project VOC file can be destroyed.
Moderators: chulett, rschirm, roy
How a project VOC file can be destroyed.
Leroy Gharis
Dallas, TX
Dallas, TX
-
ray.wurlod
- Participant
- Posts: 54607
- Joined: Wed Oct 23, 2002 10:52 pm
- Location: Sydney, Australia
- Contact:
Erk.
Recovering the VOC file is not as simple as just recovering the VOC file.
None of your routines will be cataloged, for example. You might try running Multi Job Compile (and include Routines) after restoring the physical VOC file.
Any commands you may have saved from the Administrator client's Command window will no longer be there.
Recovering the VOC file is not as simple as just recovering the VOC file.
None of your routines will be cataloged, for example. You might try running Multi Job Compile (and include Routines) after restoring the physical VOC file.
Any commands you may have saved from the Administrator client's Command window will no longer be there.
IBM Software Services Group
Any contribution to this forum is my own opinion and does not necessarily reflect any position that IBM may hold.
Any contribution to this forum is my own opinion and does not necessarily reflect any position that IBM may hold.
Steps to recover VOC file for project A if it is destroyed. This works if the VOC file is the only file that is affected. I cannot attest to how successful this is if other files are affected.
1. Create a new project(B).
2. Copy the VOC file from the new project dir(B) to the old project dir(A).
3. You can now connect to the old project(A) with the clients. You should be able to export the jobs from project A. If not, then you will need to issue a CLEAN.ACCOUNT command on the old project. I recommend you do not let CLEAN.ACCOUNT remove any entries. It should create entries for the jobs, etc.
4. You will note that the DS Administrator now points to the directory of the new project(B) when you select the old project(A) in the list. This is because the path is in the VOC.
5. If you delete the old project(A) in DS Administrator it will delete the directory(B) for the new project. You now have the new project name(B) in the Administrator list of projects and the old project directory(A). The path in the administrator for the project B does not exist.
6. Logon to the Unix server and rename the old project directory(A) to the new project directory(B).
7. At this point you may be able to use this project B. I wanted to have the old project name (A) back, so I created the old project name(A) again and imported the jobs, table definitions and routines back into it. This is probably safer anyway.
8. You should be good to go at this point. What you do with the project with the new name (B) is up to you. You may want to keep it for a period of time just in case.
I understand about the routines. I actually exported jobs, table definitions and routines and imported them back into the project A after I recreated it. Since the jobs were not compiled I think the routines would get cataloged again.
Not much can be done for the commands that were saved. I usually don't use that feature much.
1. Create a new project(B).
2. Copy the VOC file from the new project dir(B) to the old project dir(A).
3. You can now connect to the old project(A) with the clients. You should be able to export the jobs from project A. If not, then you will need to issue a CLEAN.ACCOUNT command on the old project. I recommend you do not let CLEAN.ACCOUNT remove any entries. It should create entries for the jobs, etc.
4. You will note that the DS Administrator now points to the directory of the new project(B) when you select the old project(A) in the list. This is because the path is in the VOC.
5. If you delete the old project(A) in DS Administrator it will delete the directory(B) for the new project. You now have the new project name(B) in the Administrator list of projects and the old project directory(A). The path in the administrator for the project B does not exist.
6. Logon to the Unix server and rename the old project directory(A) to the new project directory(B).
7. At this point you may be able to use this project B. I wanted to have the old project name (A) back, so I created the old project name(A) again and imported the jobs, table definitions and routines back into it. This is probably safer anyway.
8. You should be good to go at this point. What you do with the project with the new name (B) is up to you. You may want to keep it for a period of time just in case.
I understand about the routines. I actually exported jobs, table definitions and routines and imported them back into the project A after I recreated it. Since the jobs were not compiled I think the routines would get cataloged again.
Not much can be done for the commands that were saved. I usually don't use that feature much.
Leroy Gharis
Dallas, TX
Dallas, TX