HPE Community read-only access December 15, 2018
This is a maintenance upgrade. You will be able to read articles and posts, but not post or reply.
Hours:
Dec 15, 4:00 am to 10:00 am UTC
Dec 14, 10:00 pm CST to Dec 15, 4:00 am CST
Dec 14, 8:00 pm PST to Dec 15, 2:00 am PST
Operating System - OpenVMS
cancel
Showing results for 
Search instead for 
Did you mean: 

%BACKUP-E-READATTR error - need some guidance

 
SOLVED
Go to solution
Neil Ashworth_1
Occasional Advisor

%BACKUP-E-READATTR error - need some guidance

Hi, we had this error in last nights backup, and not sure how much of an error this is:

%BACKUP-E-READATTR, error reading attributes for DSA703:[APPLICATION]APPFILE.DAT;2
-SYSTEM-W-NOSUCHFILE, no such file
%BACKUP-W-READATTRRETRY, 2 READATTR errors occurred reading DSA703:[APPLICATION]APPFILE.DAT;2

The file is there as I can do a dir/full on it, and anal/disk is clean. Unfortunately the file is in use, so cannot do anal/rms.

OpenVMS 7.3-2 on AlphaServer GS1280 with patch kit BACKUP V4 installed.

What do you think - is the file corrupt?
3 REPLIES
Kris Clippeleyr
Honored Contributor
Solution

Re: %BACKUP-E-READATTR error - need some guidance

Neil,

From the release notes of a patchkit for BACKUP, we can learn.


BACKUP attempts recovery (retry) from a READATTR error, when a "no such file" error is returned from the XQP when reading an extension header, with open, fragmented files (/IGN=INTERLOCK is used).

The fix is to retry the same extension header 3 times. If any of those access attempts are successful, continue to move forward through the file while logging the number of attempts. If the retry count is exhausted the file is no longer considered a target and the READATTR/NOSUCHFILE error will be reported. A new message has been added that reports the retry count.

Following are a few examples of possible message sequences:

o Success example 1: Recovered from the first and only error.

%BACKUP-W-READATTRRETRY, 1 READATTR error occurred reading $4$DKA310:[READATTR]1XQPXR_FRAGMENT.DAT;1

o Success example 2: 17 retries to save the file, though it was saved successfully.

%BACKUP-W-READATTRRETRY, 17 READATTR errors occurred reading $4$DKA310:[READATTR]1XQPXR_FRAGMENT.DAT;1

o Failure, example 1: A failing sequence where no successful retries occurred before eventually failing on the same extheader 3 times.

%BACKUP-E-READATTR, error reading attributes for $4$DKA310:[READATTR]1XQPXR_FRAGMENT.DAT;1
-SYSTEM-W-NOSUCHFILE, no such file
%BACKUP-W-READATTRRETRY, 1 READATTR error occurred reading $4$DKA310:[READATTR]1XQPXR_FRAGMENT.DAT;1

o Failure Example 2: A failing sequence of 3 successful retries while moving forward through the file on different EXTHDRS, but eventually, unable to recover from the fourth READATTR detected.

%BACKUP-E-READATTR, error reading attributes for $4$DKA310:[READATTR]2XQPXR_FRAGMENT.DAT;1
-SYSTEM-W-NOSUCHFILE, no such file
%BACKUP-W-READATTRRETRY, 4 READATTR errors occurred reading $4$DKA310:[READATTR]2XQPXR_FRAGMENT.DAT;1

The larger th size, more fragmented and interactive the open file, the lesser the chance of success. Use of /IGNORE=INTERLOCK implies open files are to be processed. If messages for files are paired (both READATTR/READATTRRETRY are reported) then the file did not get saved completely. Success is a READATTRRETRY message only.


So, to summarize, that file has extensions, is probably open, and could not be completely saved by BACKUP.
If the data in the file is important to you (and/or tgo your customers), make sure the file is closed before taking the backup; /IGNORE=INTERLOCK is not such a good idea, since it (might) result(s) in corrupt data on the backup medium.

Regards,
Kris (aka Qkcl)

I'm gonna hit the highway like a battering ram on a silver-black phantom bike...
Upstate Rob
Occasional Advisor

Re: %BACKUP-E-READATTR error - need some guidance

I doubt the file is corrupt, but until you close it, you know nothing. Make a backup (or even a backup copy of the file) when it is not being used in any way. I think you will have no problem doing that (and then backing up the COPY of the file to tape, not the always-in-use original). Then, as a test, restore that COPY (rename the real one) and start the users up again and see if all is well. Open files, especially Databases, cannot truly be backed up while in use ... period. It is not the status of the original file that is in danger, it is the status of the backup you get (as noted by the previous reply).
Another Simple Solution to a Complex Problem
Jan van den Ende
Honored Contributor

Re: %BACKUP-E-READATTR error - need some guidance

Neil,

Except for closing the file (not always an option) the ONLY way to get CONSISTENT info in your backup is to do a
$ CONVERT/SHARE to a backup version of the file just before the actual BACKUP.
After restoring the backup, rebuild your actual file from that. (CONV/FDL, or simple COPY or RENAME for sequential files).

hth,

Proost.

Have one on me.

jpe
Don't rust yours pelled jacker to fine doll missed aches.