Was /CRC always in OpenVMS BACKUP command?

[David Jones_21]

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.

[Tom O'Toole]

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.

[Jan van den Ende]

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

[Uwe Zessin]

> 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]

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

[Uwe Zessin]

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

Well, that _is_ the argument. No WHL in the SCSI devices and the existing VMS software could not do mini-merges.

Compaq even spent time to implement history logging in the HSG controller's firmware, but when it was almost ready for release the product became End-Of-Life.

[Robert Brooks_1]

Uwe wrote . . .

Compaq even spent time to implement history logging in the HSG controller's firmware, but when it was almost ready for release the product became End-Of-Life.

----

Not quite correct. The HSG80-with-WHL capability was never "almost ready for release". At the time when that project was
halted, we were at least 9-12 months away from shipping a finished product. Before that development effort was scrubbed, the HSG80 had already been declared at end-of-life, but we were still planning on releasing the HSG80 firmware change *after*
the EOL designation.

The WHL implementation on the HSG80 differed
significantly from the WLG implementation
on the MSCP-speaking controllers. A key difference is that the write history logging
was kept on the members of the shadow set itself, not inside the controller. We discovered rather late in the development of WHL that this created some theoretical synchronisation issues that were nearly impossible to solve.

After an extensive review of the WHL design,
we decided to start from scratch with HBMM.

Given that WHL would not have ever been extended to any of the new controllers (EVA, etc...), we are pleased that the HBMM
solution is controller-independent!


-- Rob

[Uwe Zessin]

Now, that is interesting, because:

take a look at document EK-G80CL-RA.B01 (HSG80 Array Controller V8.7 Command Line Interface Reference Guide) - for example: on page 54, which describes the "ADD UNIT" command:
""WRITE_LOG
NOWRITE_LOG (default)

Marks the defined unit as an OpenVMS Host Based Volume Shadowing shadow set member.

IMPORTANT: This switch is only supported with ACS version 8.7R or version 8.7W code. NOTE: The specified unit is only marked and not enabled.

To enable a unit as an OpenVMS Host Based Volume Shadowing shadow set member, a single controller or both controllers of a dual redundant pair must be restarted. During the restart, the additional memory structures required for GWHL are allocated and initialized. Once enabled, the unit can only be disabled as an OpenVMS Host Based Volume Shadowing shadow set member by use of the NOWRITE_LOG command. When the log unit is disabled, it is not necessary to restart the controllers - this needs to be done only when a log unit is enabled. Log units can be JBODs, stripesets, RAIDsets, or mirrorsets. However, this unit cannot be a member of a Snapshot or Remote Copy set.
...""

To me, that looked like the product was almost ready ;-)
Thanks for the update, anyway.

[Robert Brooks_1]

To me, that looked like the product was almost ready ;-)

----

Oh yes, I agree -- the ACS software was certainly near release. It was the work within the shadowing driver that still had a long way to go.

-- Rob