Re: Odd backup corruption
- From: "David Weatherall" <nospam@xxxxxxxxxxxxxxx>
- Date: 1 May 2008 07:50:33 GMT
Tom Wade wrote:
Greetings,
I've seen the following bizarre situation with BACKUP on an Alpha PS
433au.
OpenVMS7.3-2 with UPDATE 12 (which includes BACKUP 7).
$ copy temp-input.ps temp-copy.ps
$ diff temp-input.ps temp-copy.ps
Number of difference sections found: 0
Number of difference records found: 0
DIFFERENCES /IGNORE=()/MERGED=1-
DKA0:[TEMP]TEMP-INPUT.PS;1-
DKA0:[TEMP]TEMP-COPY.PS;2
SO far so good. Similar result for CONVERT. Now for BACKUP
$ backup temp-input.ps temp-backup.ps
$ diff temp-input.ps temp-backup.ps
File DKA0:[TEMP]TEMP-INPUT.PS;1
119 GetPageDeviceName @ type @/nametype ne ~/stringtype ne
and{!/none}if(.)5 120 -1 1{^ length add}for string 6 1 $ 5 ^ 5{~ 1
^ cvs length 1 ^ length 1 ^ ******
File DKA0:[TEMP]TEMP-BACKUP.PS;1
119 GetPageD @/nametype ne ~/stringtype ne and{!/none}if(.)5
120 -1 1{^ length add}for string 6 1 $ 5 ^ 5{~ 1 ^ cvs length 1 ^
length 1 ^ ************
************
File DKA0:[TEMP]TEMP-INPUT.PS;1
300 ex cy flipXY -1 eq {exch} if itransform pop
301 x2 sub /eShift exch def
******
File DKA0:[TEMP]TEMP-BACKUP.PS;1
300 eeviceName @ typeq {exch} if itransform pop
301 x2 sub /eShift exch def
************
%DIFF-F-READERR, error reading DKA0:[TEMP]TEMP-BACKUP.PS;1
-RMS-W-RTB, 26988 byte record too large for user's buffer
The file produced is the same size, and has the same RMS attributes
File Organization: sequential
Record Format: variable
Record Attributes: carriage-return
Maximum Record Size: 0
Longest Record: 153
Blocks Allocated: 600, Default Extend Size: 0
End-of-File VBN: 542, Offset: %X'008A'
File Monitoring: disabled
File Length Hint (Record Count): -1 (invalid)
File Length Hint (Data Byte Count): -1 (invalid)
Global Buffer Count: 0
However, the file is corrupted.
I also noticed the following:
1. The problem arises when trying to copy a file (as above), or
extracting a file from a Backup saveset. Writing a backup saveset is
OK, as I can move the newly created saveset to another machine, and
unpack the file successfully there.
2. The problem occurs irrespective of which disk (there are two) is
used.
3. I tried copying over the BACKUP.EXE and BACKUPSHR.EXE from
another 7.3-2 machine (with UPDATE 4) and the same thing happens.
The problem does not occur on this second machine (I remembered to
INSTALL REPLACE).
4. SHOW ERROR produces NOERRORS (no device errors found).
I am somewhat perplexed. Silent corruption from BACKUP is not
something I would have expected.
Has anyone seen anything like this ?
I'm not sure this isn't more of a problem with DIFF. If BACK /COMP
shows not problem then try DIFF /MOD=HEX. If there are differences this
will give you the record/ block numbers where it starts.
ISTR that there is/was a problem with overly long LF-stream records
still not being accepted by DIFF /MODE=HEX and led me to think of a
suggestion I might have had for Guy if he were still there, i.e. ignore
the record structure with :-
$ DIFF /BLOCK
with similar qualifiers to DUMP for display in BYTE, WORD, LONG etc.
would save the DUMP and subsequent DIFF On the DMP files.
Cheers - Dave.
--
.
- Prev by Date: VAX 6310 Free to a good home
- Next by Date: Re: Encompass - Endeavour
- Previous by thread: VAX 6310 Free to a good home
- Next by thread: Re: Odd backup corruption
- Index(es):
Relevant Pages
|
