Operating System - OpenVMS
cancel
Showing results for 
Search instead for 
Did you mean: 

Was /CRC always in OpenVMS BACKUP command?

SOLVED
Go to solution
Cass Witkowski
Trusted Contributor

Was /CRC always in OpenVMS BACKUP command?

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

Thanks

Cass
28 REPLIES
Hein van den Heuvel
Honored Contributor

Re: Was /CRC always in OpenVMS BACKUP command?

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.
Honored Contributor

Re: Was /CRC always in OpenVMS BACKUP command?

note for some versions of VMS /CRC is not the default.
____________________
Purely Personal Opinion
Wim Van den Wyngaert
Honored Contributor

Re: Was /CRC always in OpenVMS BACKUP command?

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

Wim
Wim
Galen Tackett
Valued Contributor

Re: Was /CRC always in OpenVMS BACKUP command?

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
Honored Contributor

Re: Was /CRC always in OpenVMS BACKUP command?

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
Wim
Robert Gezelter
Honored Contributor

Re: Was /CRC always in OpenVMS BACKUP command?

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
Trusted Contributor

Re: Was /CRC always in OpenVMS BACKUP command?

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.
I'm looking for marbles all day long.
Jan van den Ende
Honored Contributor

Re: Was /CRC always in OpenVMS BACKUP command?

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
Don't rust yours pelled jacker to fine doll missed aches.
Robert Gezelter
Honored Contributor

Re: Was /CRC always in OpenVMS BACKUP command?

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
Uwe Zessin
Honored Contributor

Re: Was /CRC always in OpenVMS BACKUP command?

> I can personally testify that I have seen /CRC recover a saveset in real situations,

Not possible. The CRC is stored in a longword in BACKUP's meta data. Redundancy group will provide the necessary 'overhead' to enable recovery.

Again, /CRC is usefull as an end-to-end check, because it covers the whole data path. Hey, I have even seen BACKUP creating corrupted save sets when the destination was on a remote DECnet node.
.
Cass Witkowski
Trusted Contributor

Re: Was /CRC always in OpenVMS BACKUP command?

I was orginally asking of the /CRC qualifier was always in the BACKUP command. I was hoping that some one had access to old documentation or remembered this fact.

I'm also curious what error message you receive when BACKUP detects an error when checking it's CRC error versus when the tape drive finds a parity error. Is there a different message?

As someone stated earlier the /CRC only detect erros it won't correct them.


Using DLT and newer tape drives has anyone experienced where the BACKUP CRC actually detected an error but the hardware did not?

Cass
Uwe Zessin
Honored Contributor
Solution

Re: Was /CRC always in OpenVMS BACKUP command?

HDRCRC, software header CRC error

Facility: BACKUP, Backup Utility

Explanation: An incorrect value occurred in the header CRC field
.
Robert Gezelter
Honored Contributor

Re: Was /CRC always in OpenVMS BACKUP command?

Uwe,

Concur. The correction is done using the Redundancy Groups. One of the ways in which an error is detected is throught the CRC (my phrasing may not have been clear).

- Bob Gezelter, http://www.rlgsc.com
Sheldon Smith
Honored Contributor

Re: Was /CRC always in OpenVMS BACKUP command?

I *do* remember.

The /CRC qualifier has always been there. We were excited when Backup finally came out. And, "Oh my god, look at these cool options!"
As mentioned earlier, the VAX had a CRC hardware instruction. And the developers were quite proud of that instruction! :)

Note: While I work for Hewlett Packard Enterprise, all of my comments (whether noted or not), are my own and are not any official representation of the company.
----------
If my post was useful, click on my KUDOS! thumb below!
Uwe Zessin
Honored Contributor

Re: Was /CRC always in OpenVMS BACKUP command?

I was excited, too ;-)

After the upgrade to VAX/VMS V3.0 on the night from friday to saturday, I stumbled over a bug in the tape ACP. A simple
$ initialize MTA0: label
$ mount MTA0: label
$ copy file.1 MTA0:file.1

resulted in a fatal bugcheck :-(
On monday, our system manager (I worked on PCB designs back then) told me about BACKUP, so we regained the ability to transfer files between systems.
.
Robert_Boyd
Respected Contributor

Re: Was /CRC always in OpenVMS BACKUP command?

I don't recall BACKUP being available on V3.0 -- unless I actually started with V2.x systems. I first managed a VAX 11/780 in 1981 and it was running the latest available. I remember in the early days I was still having to use the RSX compatibility mode disk backup utility before BACKUP came out. It was fairly soon after that when BACKUP came out ... much to my relief.

Robert
Master you were right about 1 thing -- the negotiations were SHORT!
Cass Witkowski
Trusted Contributor

Re: Was /CRC always in OpenVMS BACKUP command?

Ok I got the first two questions answered as to when /CRC appear in the BACKUP command and what is the error message generated when the CRC does detect an error.

My thanks to all who responded.

Now has anyone ever received this error using DLT, SDLT, or ULTRIUM tape drives?

Cass
Jan van den Ende
Honored Contributor

Re: Was /CRC always in OpenVMS BACKUP command?

Re: Robert,

That would pretty much pinpoint the timing:

I started at V3.2 in 1982 and it DEFINITELY was there then!

Proost.

Have one on me.

jpe
Don't rust yours pelled jacker to fine doll missed aches.
Galen Tackett
Valued Contributor

Re: Was /CRC always in OpenVMS BACKUP command?

Though I don't have my VAX Architecture Reference Manual [Sites, 1998; chapter 4] handy as an authoritative source, I'm quite confident that the CRC instruction belonged to one of the architecture subsets omitted from the early MicroVAX systems least the MicroVAX I and II.

Just out of curiosity, does anybody know if any of the MicroVAX/VAXstation family ever did implement any of the subsets that weren't present in the early members of the family?
David Jones_21
Trusted Contributor

Re: Was /CRC always in OpenVMS BACKUP command?

Having to emulate the CRC instruction for backup is probably what led them to the realization that the microcode version in the VAX firmware was really slow. Library implementations of the CRC calculation are much faster than what can be acheived with the 'native' CRC instruction on machines that have it.
I'm looking for marbles all day long.
Tom O'Toole
Respected Contributor

Re: Was /CRC always in OpenVMS BACKUP command?


Cass,

I have never seen the error on DLT,SDLT,ULTRIUM drives. As mentioned in this thread, a CRC error would normally result in a fatal error returned from these types of drives and a completely unreadable tape from the point of failure. It has been discussed here that this could be considered a pretty serious bug that backup cannot perform its error recovery logic, but nobody from HP has ever addressed this, as far as I know.

Used to have CRC errors corrected by redundancy group routinely when using 9-track 800/1600/6250 bpi tape for backups. Seems like this could be thought of as an early implementation of RAID5 - VMS way ahead of most other systems once again.
Can you imagine if we used PCs to manage our enterprise systems? ... oops.
Jan van den Ende
Honored Contributor

Re: Was /CRC always in OpenVMS BACKUP command?

Yes, Tom.

That brings back memories of a site I was working at in about 1990.
They had IBM, Bull, & Vaxes.
The needed LOTS of tape reels, and those were altogether not THAT cheap.
Even before I got there, they found out that tapes refused by IBM or Bull were still perfectly useable on Vax, although there was an 'occasional' recoverable error.
New tapes went to 'the others', there fefuse went to Vax.
I remember my plan to set a limit for "excessive" errors.
I suggested hitting double-digits (PER Backup-run PER tape !) but that would have involved so much disqualifying that we would run short of stock. Rather than buying new tapes, the limit was set to 50, and even then about 10% was considered gone. (vague memory about the exact percentage, but I seem to remember that max percentage was the reason to decide on what limit!)

Nowadays of course VMS is as picky as IBM & Bull were back then.

And my true concern is NOT the write-past-error, but especially the READ that is rendered impossible by a single parity error.


Maybe sometime Engeneering wikk find a way to re-enable this marvellous functionality. After all, it took over 10 years to enable mini-merge for SCSI but they DID do it.


Proost.

Have one on me.

jpe
Don't rust yours pelled jacker to fine doll missed aches.
Uwe Zessin
Honored Contributor

Re: Was /CRC always in OpenVMS BACKUP command?

> After all, it took over 10 years to enable mini-merge for SCSI but they DID do it.

SCSI devices still don't have write history logging. It is not that engineering flipped a bit somewhere - the implementation/ workaround was new code in the OpenVMS operating system.


My experience with 'bad'/degraded tapes was just the opposite: when I could not read one on the VAX-attached tape drives (TU77, TU78, a SystemIndustries one), I went to the IBM operators and asked them to make a copy on their tape stations.

But if the tape drive doesn't let anyone get behind the bad spot, how do you expect VMS to get at the data?
.
Jan van den Ende
Honored Contributor

Re: Was /CRC always in OpenVMS BACKUP command?

Uwe,


SCSI devices still don't have write history logging.

That looks a lot like the argument I have been getting for about 10 years on minimerge'


It is not that engineering flipped a bit somewhere - the implementation/ workaround was new code in the OpenVMS operating system.

I realese very well that if it were simple we had have had both pretty quickly. I just hope (pray!) that they can somehow realise a "workaround" here too!

But I won't stay awake waiting for it! :-(

Proost.

Have one on me.

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