Damaged member in Physical file

40 pts.
Tags:
AS/400 errors
AS400 Data Definitions
AS400 physical file
Physical File
Any way to tell if the file was damaged is due to OS issue or application related issue?

Answer Wiki

Thanks. We'll let you know when a new response is added.

Unless your OS crashed or your storage device crashed, you can almost be certain the error causing the corruption occurred during processing; batch or online. I don’t know that I have ever experienced data corruption caused by the OS.

Discuss This Question: 3  Replies

 
There was an error processing your information. Please try again later.
Thanks. We'll let you know when a new response is added.
Send me notifications when members answer or reply to this question.

REGISTER or login:

Forgot Password?
By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy
  • TomLiotta
    Generally, you can tell the difference in this way -- If "Damage" is reported against a file, it is a system issue. Otherwise it's an application issue. Note that object "Damage" is very different from application data corruption. That is, application programming can certainly be the cause of damage. I might run a major RGZPFM over a file of a few hundred GBs in some job when some application runs an immediate PWRDWNSYS at the wrong moment; I wouldn't be surprised if damage resulted. Or an app might go into an infinite loop and exhaust all available DASD; other jobs might be interrupted at the wrong moments and suffer damaged objects. However, causing file/member object damage through application code is difficult to do. I don't doubt that it's possible. I just haven't seen an example of how to do it. Tom
    125,585 pointsBadges:
    report
  • Leokoh
    Hi, I tried to retrieve the day where the incident happened, but the history log was only kept a day. What actually happening was this member object was damaged after our EOD processing. That’s to say, the file during the before EOD backup was still ok (no damaged object was found from the backup joblog) and EOD processing certain process I am sure it did require to access to this damaged file. However, we realised it only during the Post EOD backup. From pre-EOD backup to Post EOD backup this time intervals, there was no any harddisk or any abormality happen. I have requested the Application team to review those EOD joblog that accessing to this ‘damaged file’ if there is any error on each of the joblog. In your view, likely it was caused by OS or Application? Today is already 3 days after this incident and so far so good. The application team did a clear of physical file or ChgPF I believe. We just worry it may cause again and no one is aware of the root cause. I can understand, it is not an easy task to trace the cause.....let hope everything goes fine. Thanks
    40 pointsBadges:
    report
  • TomLiotta
    If the history logs are gone, it will be much harder to reconstruct what happened. One day is a very short time to keep history logs unless you can restore them from daily backups. A production system should keep history logs available at least for a full monthly cycle. Keeping them in backup form should be okay. As mentioned, it is certainly possible for application code to cause damage -- I just have never seen an example. (And that is different from general corruption of data.) Your best possibility might be to enter System Service Tools and then take option 1=Start a service tool. From the Start a Service Tool menu, take option 7=Hardware service manager. From the Hardware Service Manager menu, take option 6=Work with service action log. (I don't know if your version has slight changes.) In the service action log, select the timeframe from the known good backup through the time when damage was reported. If any entries appear, learn everything about them. The entries in the service action log in that timeframe might not be easy to interpret, but they will show if anything unusual happened. Still, if you can't restore the QHST* files for the time, it will be tricky getting a timeline established. Looking at a joblog will only show what happened in processes inside of that job. You might be lucky if a cause is visible there. It won't be surprising if resulting effects are found there. The EOD and post-EOD joblogs definitely need review. Any evidence will at least provide information for building the timeline. When a related event is found, you know that you don't need to look at later times as much as you should look earlier. It is reasonable (perhaps probable) that you will find an error condition that was not handled correctly in your EOD or post-EOD job. It might not have been handled at all. That's about all I can say unless and until you can narrow it down with some specific events. Post more if you find anything. Good luck. Tom
    125,585 pointsBadges:
    report

Forgot Password

No problem! Submit your e-mail address below. We'll send you an e-mail containing your password.

Your password has been sent to:

To follow this tag...

There was an error processing your information. Please try again later.

REGISTER or login:

Forgot Password?
By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy

Thanks! We'll email you when relevant content is added and updated.

Following