Was /CRC always in OpenVMS BACKUP command?

[Cass Witkowski]

Was the /CRC qualifier always part of the BACKUP command from day one or was it added?

Thanks

Cass

[Hein van den Heuvel]

BACKUP/CRC has been there 'forever', but the default may have changed over releases.

Google group search for +backup +"/crc" shows articles back to the 1980's

http://groups.google.com/group/comp.os.vms/search?group=comp.os.vms&q=%2Bbackup+%2B%22%2Fcrc%22&qt_g=1

----------------------------------------
1998:

1. Veli Korkko, +358-40-5017097
Jul 6 1998, 2:00 am show options

Newsgroups: comp.os.vms
From: kor...@juhani.decus.fi (Veli Korkko, +358-40-5017097) - Find messages by this author
Date: 1998/07/06
Subject: BACKUP and /CRC on OpenVMS V7.1

It used to be that BACKUP/CRC is same as BACKUP. I.e. /CRC is
default. In fact, V7.1 help says it stlll is. So appears to
say also BACKUP .CLD file.

In reality, things seem to be little different. If I do

$ backup/log mystuff.txt test.bck/save
$ backup/list/analyze test.bck/save

this will reveal that BACKUP did not include any CRC info into saveset.

Do that on a V6.1 or V6.2 OpenVMS system and CRC stuff will be there.

-------------------------------------
1987

2. MCGUIRE
Jun 2 1987, 7:42 pm show options

Newsgroups: comp.os.vms
Date: Tue, 2-Jun-87 20:42:00 EDT
Subject: RE: 6250 tape backup

> Date: Mon, 1 Jun 87 09:30 CDT
> From: DNEIMAN%CARLETON....@RELAY.CS.NET
> Subject: 6250 tape backup

> We have a 3-vax cluster (two 750's and a 780), all running VMS 4.5,
> connected to a single HSC-50 (v300), and 5 RA-81's. Currently, we have two
> TU-80 tape drives with which we do our regular backup procedures.


> We are considering the purchase of a 6250 bpi tape drive, which will
> replace either or both of our current tape drives. My questions:


> Is is possible from the above information to determine whether and how much
> the 6250 tape drive will speed up backup (Is the bottle neck tape
> throughput, disk i/o, or cpu?).


> More info: This drive may or may not be placed on the HSC; it may go on
> one of the other machines. Is a 750 a reasonable place for a 6250 bpi
> drive? How about a 780? What are the performance tradeoffs?


> Currently, backup is done on both tape drives simultaneously, performing
> incremental backups on different disks. Backup is usually done in the
> evening, when the administrative machines are less loaded. We may purchase
> a sixth RA-80, which will be backed up identically as the others. Will the
> use of a single 6250 bpi tape drive make backup slower overall? How much
> will it compensate for the simultaneous use (on different cpu's) of two
> 1600 bpi drives?



I can give you some educated guesses.

If you are computing checksums as part of your backup (i.e. you are using
BACKUP/CRC, the default), and performing the backup from an 11/750, then
the CPU is a bottleneck. That is, increasing the CPU to an 11/780 will
improve performance.

[Ian Miller.]

note for some versions of VMS /CRC is not the default.

[Wim Van den Wyngaert]

And I wonder if the CRC error ever arrives on VMS.

Wim

[Galen Tackett]

Wim,

As you seem to imply the crc error is probably almost never seen when using recent tape technology. If newer tape technology runs into anything serious enough to cause such an error, there's probably a lot more wrong than just a bad CRC--very likely, the drive would report a fatal error (and the tape would probably be unreadable beyond the point of error.)

Perhaps it's an even more remote likelihood that a saveset stored on disk would suddenly have a single block (or a scattered few) go bad, but if it did /CRC might make recovery possible.

Of course, if you saved a backup saveset to a card punch, you might find /CRC more likely to be useful. :-D

[Wim Van den Wyngaert]

DLT drives have some raid like error recovery. A bad "block" on tape would cause it to be calculated. I think.

Should have someone of Quantum on the forum ...

Wim

[Robert Gezelter]

Cass,

I can personally testify that I have seen /CRC recover a saveset in real situations, particularly involving disk and network errors. One of these cases involved a network adapter (DMC-11) which could, under certain circumstances (Bus Grant Late), actually lose data.

Some tape drives are problematical, in that they loose position tracking when they get an error, making it impossible to continue the sequence of read operations. This was not so on open-reel tape, where as in one classic demonstration, a piece of the oxide covering was actually scrapped off.

The situation where CRC is problematical is on a media format which cannot recover from an error on the media, why bother? After my experiences, the answer is that there are many steps to and from the saveset, and CRC guarantees the integrity of the data for many of them (e.g. media, device silos, bus transfers).

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

[David Jones_21]

Since the original VAX had a CRC instruction, I'm pretty sure BACKUP used it from close to day one. CRC checksums on the data are used to detect errors, not correct them. While modern media has its own sophisticated error detection, still like using /CRC as an 'end-to-end' check of data integrity.

[Jan van den Ende]

Cass,

in my experience BACKUP _always_ recovered from DSA-compliant devices, like 880bpi-tape
"35xxx Recoverable Errors encountered" (yes, that restore took long, and was compute-intensive, and the tape unit was filled with tape-coating scrapings afterward).

But, with the introduction of SCSI even 1 parity error is ABSOLUTELY FATAL.

Don't tell me it is all to do with placement issues:
Way back when we had a SCSI-TK70 which was FATAL on a restore attempt.
Luckily we were located only several KM from a DEC location.
We took our tape there, and a DSSI-TK70 restored it with 1 (ONE) recoverable error.

Pity there are no non-SCSI DLT units, AFAIK :-(

Proost.

Have one on me.

jpe

[Robert Gezelter]

David,

WADU (with all due respect), and I have not had a chance to check my Digital Technical Journal archive, but it is possible that the CRC was one of the instructions removed when the original VAX architecture was subsetted in the VLSI implementations.

Also, the problem with error recovery is related to the drive (TK and others) and not the interconnect (SCSI). Error recovery from errors in disk data works on all disk devices.

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