Using Backup/Encrypt - Saveset Corruption with no warning.

[P Muralidhar Kini]

Hi Dave,

Images in your V83-1H1 system -
>> Image name: BACKUP
>> Link Date/Time: 30-AUG-2007 10:53:53.65

>> Image name: BACKUPSHR
>> Link Date/Time: 30-AUG-2007 10:53:06.56

V83-1H1 Images with fix -
>> BACKUP.EXE;1
>> 30-NOV-2007 14:24:47.18

>> BACKUPSHR.EXE;1
>> 30-NOV-2007 14:23:56.75

Looks like you dont have the fix image installed in your system.
You need to install the above mentioned BACKUP images and that should solve the problem.

Regards,
Murali

[Shriniketan Bhagwat · Accepted solution]

Hi Dave,

Please install the VMS831H1I_BACKUP-V0100 kit. This kit contains the latest BACKUP image of 18-SEP-2009.

=============================
SYSEXE]BACKUP.EXE (new image)

Image Identification Information

Image name: "BACKUP"
Image file identification: "V8.3-1H1"
Image build identification: "0090090011"
linker identification: "Linker T02-28"
Link Date/Time: 18-SEP-2009 17:52:21.95
Overall Image Checksum: 53FA54FC

[SYSLIB]BACKUPSHR.EXE (new image)

Image Identification Information

Image name: "BACKUPSHR"
Image file identification: "V8.3-1H1"
Image build identification: "0090090011"
linker identification: "Linker T02-28"
Link Date/Time: 18-SEP-2009 17:50:06.60
Overall Image Checksum: D638B667
=============================


This kit contains the fix but the fix is not documented in the ECO Cover Letter. Please install the kit and let me know if it resolves the problem.


Regards,
Ketan

[Shriniketan Bhagwat]

Hi Dave,

Cause for this issue.

During the save operation, BACKUP copies the datakey which is encrypted in BSR(BACKUP summary record) for the encrypted savesets. While listing or restoring the encrypted savesets, BACKUP first searches for datakey stored in BSR. When it finds this datakey, it compares this value with -1 (.i.e. Hexadecimal FF) to check whether it had found a key. There are chances that this datakey may contain the value "FF" which was generated during encryption, resulting in BACKUP reporting ENCBSRNOT error message. This does not cause any data loss or corruption. Even though the BACKUP fails during restore, data in the saveset is intact. Nothing to worry about the data.

Regards,
Ketan

[Craig A]

Hi Dave

I didn't know /SAVE_SET was the default for tape drives and I've been working with VMS since 1987. Yikes! You learn somethign new every day.

I always add use it in the BACKUP command when writing to tapes - for completeness.

Ketan said:

>This does not cause any data loss or >corruption. Even though the BACKUP fails >during restore, data in the saveset is >intact. Nothing to worry about the data.

Was this your experience? i.e. Did you manage to restore data from the saveset?

Craig

[Shriniketan Bhagwat]

Hi Dave,

I have verified the source code listing of the BACKUP images which were built on 18-SEP-2009 (which are part of VMS831H1I_BACKUP-V0100 kit). The source code listing contains the modification which fixes the issue. You will be all set after installing VMS831H1I_BACKUP-V0100 kit.

Regards,
Ketan

[Shriniketan Bhagwat]

Hi,

>> Was this your experience? i.e. Did you manage to restore data from the saveset?

My update was with respect to this particular issue which is discussed in this thread. Yes I have seen other customers facing the same issue and resolved it after using this fix.


Regards,
Ketan

[Hoff]

Personally, I always specify /SAVE_SET on the BACKUP parameter that I think contains the saveset, and regardless of what else is going on, as I'd rather not have a surprise.

Backup is wonky enough, and if I mess up with a BACKUP or a MOUNT command (or for those occasional cases where BACKUP goes into the weeds), having /SAVE_SET on the saveset is an extra measure of don't-gronk-my-disks.

[Shriniketan Bhagwat]

Hi,

/SAVE_SET qualifier is not mandatory for tape operations. It could be save operation or listing from the tape or restore from tape. It is good /no harm in using it. I personally use this qualifier every time where the saveset is involved.

Regards,
Ketan

[Robert Gezelter]

Dave,

I agree with Hoff on the use of /SAVE_SET. It is easy to use the default when explicitly referencing a tape drive. It is more dangerous to do when using a logical name or symbol substitution.

I have seen mishaps when people salvaged code without sufficient care and then walked into problems. For that reason, I always recommend explicitly using the qualifier.

On /CRC, it is admittedly not as useful as it was on open-reel tape, but overall, I tend to use /CRC and the redundancy groups. I have seen cases where a saveset was corrupted as it was copied across a network, and the /CRC and redundancy group identified and corrected the problem.

I originally encountered this danger shortly after BACKUP was released, when I was copying files between a VAX-11/780 and a PDP-11/34 over a DMC-11-based DECnet link. The DMC-11 had a timing problem that would occasionally drop bytes caused by a mishandling of Bus Grant Late on the VAX-11/780 UNIBUS. Getting the "unrecoverable error, data recovered" message on a network file access was an unexpected experience.

- Bob Gezelter, http://www.rlgsc.com

[P Muralidhar Kini]

Hi,

>> I didn't know /SAVE_SET was the default for tape drives
Yes, /SAVE_SET is the default for the tape drives.
But then i always prefer to use /SAVE_SET when dealing with savesets.

Regards,
Murali