damage file

[Guest.Visitor]

Tiki, Been there, had this problem. Here's what I did, 1. CPYF the file to another name and location 2. Deleted ALL Lf's. 3. Deleted the PF. 4. CPYF "Back to the original" file 5. Recreated all lf's. This after 3 hours of being down, and alot of try this try that. good luck!

[David Abramowitz]

Run, do not walk, to the RCLSTG command. This message indicates that there is a problem. RCLSTG will either solve it for you, or tell you that it is worse than you think it is. You may have a bad area on disk. Copying the files leaves that area open to future writes, which may result in the same error in more files. Dave

[Guest.Visitor]

Tiki, the following is why I would be VERY careful before using the RCLSTG command. If the command warns you before deleting the unrecoverable object, I guess that would be ok. Sometimes, it's better to crawl not RUN. This is from the HELP panel. Reclaim Storage - Help The Reclaim Storage (RCLSTG) command corrects, where possible, objects that were incompletely updated (such as database files, libraries, device descriptions, directories and stream files) and user profiles containing incorrectly recorded object ownership information. Any unusable objects or fragments are deleted. this is from a V5R2 machine.

[dacust]

Tiki, I think Bentley is right, and so is David. I'd do the copy like Bentley suggests. Then delete the old object. Immediately after I'd do the RCLSTG.

[Guest.Visitor]

I PLAN TO RUN RCLSTG AFTER OUR MONTH END JOB, WHAT WILL BE THE PARAMETERS I WILL USE AND WHAT ARE MY EXPECTATIONS. WE ARE IN V5R1, AND RUNNING 58% ASP. THE PROBLEM WE HAVE BEFORE WAS THAT OUR SYSTEM USAGE WENT UP 95% WHEN WE FIRST ENCOUNTER THIS PARTIAL DAMAGED ON FILE, THEN WENT BACK TO NORMAL AFTER WE IPL. THEN FOLLOWING YOUR ADVISED, I COPY AND DELETE THE FILE AND REBUILT LOGICAL FILES AND IT FIXED THE PROBLEM. DO I REALLY NEED TO RUN RCLSTG. THANKS, TIKI

[Guest.Visitor]

Tiki, NO WARRANTIES EXPRESSED OR IMPLIED IN THE FOLLOWING: USE AT YOUR OWN RISK !! No that the disclaimer is outta the way... You probably won't get a definitive answer on "How long will RCLSTG take?" since it's all dependent upon your particular system...how many objects you got, what kind they are, are they damaged - how many are damaged, how much total disk you have, how full it is...etc, etc, etc... But I can offer you my personal experiences with RCLSTG which I ran just this past weekend (Saturday, 5/22/2004). We have V4R2, 53% ASP used (only 1 ASP & it is 34.3Gig), 1 gig of RAM. I would guess that we have had at least 4 hard crashes (from power failures & the UPS (we found out) was faulty) in the past couple of years. We have had this machine since late 1998 & I know that RCLSTG has NEVER been run on it before, because I've been here all that time & I'm the only one who'd run it. Anyway, I ran RCLSTG & it ran for about 1.5 hours. It runs interactively & you have to bring the system to a restricted state before you run it. It gives you updates periodically (in my case at least every 5 minutes) on how complete it is as a percentage of objects checked. Upon completion, I immediately did a PWRDWNSYS OPTION(*IMMED) RESTART(*YES). This was kinda scary as it kept the same SRC code for literally 5 to 10 minutes (D6000298) but then it proceeded with the IPL, came back up & all was well ! IN ANY EVENT, READ THE DOCUMENTATION FOR YOUR RELEASE OF OS/400 ON THE RCLSTG COMMAND IN ITS ENTIRETY FOR ALL CONSIDERATIONS. Other than that, I'd allocate as much free time as possible when the system can be unavailable to all users. Also, if you have a much larger system than mine, you might contact IBM & ask them if you can interrupt the RCLSTG once it is started. For my release (V4R2) RCLSTG only has 2 parameters SELECT & OMIT. I took the defaults for both SELECT(*ALL) OMIT(*NONE); this makes the command perform as much checking as possible, I believe. Finally, the QHST log will have messages on what was deleted, etc as well as the QSYSOPR job queue. The help for RCLSTG states that the # of objects reported deleted by RCLSTG when it finishes may not add up to the # of deleted object messages in QSYSOPR / QHST, some are internal objects that you cant see anyway. Anyway, I'll restate my disclaimer: NO WARRANTIES EXPRESSED OR IMPLIED IN THE PRECEEDING: USE AT YOUR OWN RISK !! and say Good luck ! Regards, Martin

[Guest.Visitor]

Thanks for sharing me you experience. I will probably get some help from IBM to do this to avoid unnecessary fall back. Tiki

[asheesh_ks@infosys.com]

I faced similar situation in last one week in test box. We had to restore from production. Does anyone what all could cause it? We have lots and lots of constraints (unique as well as referential). For test purpose we keep deleting the data and then restore from save file. Does any one know if restore could damage the files (if the restore did not happen propeprly)? Its quite annoying. I would appreciate if anyone could help me on this.

[David Abramowitz]

AK400 asked: Does anyone what all could cause it? Any system on the planet, including an iseries could at any time be plagued with disk problems. The most severe situation is a head crash, but a problem might manifest as a slight disk imperfection. Unless the area on disk is marked as bad and unusable, the machine code will still attempt to use the bad area, resulting in a damaged file. AFAIK, one aspect of RCLSTG is to mark bad areas of disk space as unusable, avoiding future problems. Dave

[Guest.Visitor]

Create a library called QRCL before running the RCLSTG command. When you run the RCLSTG command it will put the damaged objects into this library but will not delete the library afterwards and you will not have to search through the job log looking for the file names of objects. Definitely change your job to log CL commands and save this job log on the system before you sign off and IPL the system.

---

Code