OpenVMS 8.4 alpha "backup" Problems

[Ralf Folkerts]

Hi,

wanted to Update my Hobbyist-AS255/233 from OpenVMS 8.3. to 8.4 -
and tried to create a stand-alone backup using the 8.4 CD to Tape
before that.

However, backup showed lot of missing blocks during verify. That made
me slightly nervous, so I checked SCSI-Termination, Disk-Drive, Tape
Drive, Cabled, tried w/ another Tape, ... However, the Problem
persisted. Then used the 8.3 CD, as I used to use that to create a
stand-alone backup. Strangely, that backup succeeded w/o any problems :(

Now, I don't really need 8.4 for my hobbyist-system at all. However,
does anyone have an Idea what might be going on?

Will paste a transcript from a 8.3 boot/backup and a 8.4 boot/backup
below. Both are from the same system, even the same Tape is being
used... I cancelled the 8.4 verify, as it took ~3 times the time the
complete backup/verify took with the 8.3 system...

mka500.5.0.6.0 MKA500 Quantum DLT4000 CD4B
dka0.0.0.6.0 DKA0 IBM DNES-309170 SAH0

Cheers,
_ralf_

>>>b dka400
(boot dka400.4.0.6.0 -flags 0,0)
block 0 of dka400.4.0.6.0 is a valid boot block
reading 1226 blocks from dka400.4.0.6.0
bootstrap code read in
base = 1f2000, image_start = 0, image_bytes = 99400
initializing HWRPB at 2000
initializing page table at 1e4000
initializing machine state
setting affinity to the primary CPU
jumping to bootstrap code


OpenVMS (TM) Alpha Operating System, Version V8.3
Copyright 1976-2006 Hewlett-Packard Development Company, L.P.


Please enter date and time (DD-MMM-YYYY HH:MM) 01-MAY-2013 12:15



Installing required known files...

Configuring devices...
%EWA0, Auto-negotiation mode set by console
%EWB0, Twisted-Pair mode set by console
%EWA0, Auto-negotiation (internal) starting
%EWA0, Full Duplex 100baseTX connection selected
%EWA0, Link state: UP
%EWA0, Auto-negotiation (internal) starting
%EWA0, Link state: DOWN
%EWA0, Full Duplex 100baseTX connection selected
%EWA0, Link state: UP


****************************************************************

You can install or upgrade the OpenVMS ALPHA operating system
or you can install or upgrade layered products that are included
on the OpenVMS ALPHA distribution media (CD/DVD).

You can also execute DCL commands and procedures to perform
"standalone" tasks, such as backing up the system disk.

Please choose one of the following:

1) Upgrade, install or reconfigure OpenVMS ALPHA Version V8.3
2) Display layered products that this procedure can install
3) Install or upgrade layered products
4) Show installed products
5) Reconfigure installed products
6) Remove installed products
7) Find, Install or Undo patches; Show or Delete Recovery Data
8) Execute DCL commands and procedures
9) Shut down this system

Enter CHOICE or ? for help: (1/2/3/4/5/6/7/8/9/?) 8



WARNING --

The normal OpenVMS startup procedure has not executed.
Some commands and utilities will not work as documented.
HP does not support PRODUCT INSTALL and other
PRODUCT operations in this environment.


Enter DCL commands -- Enter "LOGOUT" when done.
When you enter "LOGOUT" a message will be displayed saying
"Process SA_STARTUP_DCL logged out at <date> <time>",
and you will be returned to the menu.

$$$ mount/foreigm mka500:
%MOUNT-I-MOUNTED, IBACKU mounted on _MKA500:
$$$ mount dka0: tricksys
%MOUNT-I-MOUNTED, TRICKSYS mounted on _DKA0:
$$$ backup/rewind/image/verify dka0: mka500:ibacku/save
%BACKUP-I-NOBACKUP, DKA0:[SYS0.SYSEXE]PAGEFILE.SYS;1 data not copied,
file marked NOBACKUP
%BACKUP-I-NOBACKUP, DKA0:[SYS0.SYSEXE]SWAPFILE.SYS;1 data not copied,
file marked NOBACKUP
%BACKUP-I-NOBACKUP, DKA0:[SYS0.SYSEXE]SYS$ERRLOG.DMP;2 data not copied,
file marked NOBACKUP
%BACKUP-I-NOBACKUP, DKA0:[SYS0.SYSEXE]SYS$ERRLOG.DMP;1 data not copied,
file marked NOBACKUP
%BACKUP-I-NOBACKUP, DKA0:[SYS0.SYSEXE]SYSDUMP.DMP;1 data not copied,
file marked NOBACKUP
%BACKUP-I-STARTVERIFY, starting verification pass at 1-MAY-2013
12:29:25.54
$$$ lo


>>>b dka400
(boot dka400.4.0.6.0 -flags 0,0)
block 0 of dka400.4.0.6.0 is a valid boot block
reading 1230 blocks from dka400.4.0.6.0
bootstrap code read in
base = 1f2000, image_start = 0, image_bytes = 99c00
initializing HWRPB at 2000
initializing page table at 1e4000
initializing machine state
setting affinity to the primary CPU
jumping to bootstrap code


OpenVMS (TM) Alpha Operating System, Version V8.4
Copyright 1976-2010 Hewlett-Packard Development Company, L.P.





Installing required known files...

Configuring devices...

%EWA0, Auto-negotiation mode set by console
%EWA0, Auto-negotiation (internal) starting
%EWB0, Twisted-Pair mode set by console
%EWA0, Full Duplex 100baseTX connection selected
%EWA0, Link state: UP
%EWA0, Auto-negotiation (internal) starting
%EWA0, Link state: DOWN
%EWA0, Full Duplex 100baseTX connection selected
%EWA0, Link state: UP


****************************************************************

You can install or upgrade the OpenVMS ALPHA operating system
or you can install or upgrade layered products that are included
on the OpenVMS ALPHA distribution media (CD/DVD).

You can also execute DCL commands and procedures to perform
"standalone" tasks, such as backing up the system disk.

Please choose one of the following:

1) Upgrade, install or reconfigure OpenVMS ALPHA Version V8.4
2) Display layered products that this procedure can install
3) Install or upgrade layered products
4) Show installed products
5) Reconfigure installed products
6) Remove installed products
7) Find, Install or Undo patches; Show or Delete Recovery Data
8) Execute DCL commands and procedures
9) Shut down this system

Enter CHOICE or ? for help: (1/2/3/4/5/6/7/8/9/?) 8



WARNING --

The normal OpenVMS startup procedure has not executed.
Some commands and utilities will not work as documented.
HP does not support PRODUCT INSTALL and other
PRODUCT operations in this environment.


Enter DCL commands -- Enter "LOGOUT" when done.
When you enter "LOGOUT" a message will be displayed saying
"Process SA_STARTUP_DCL logged out at <date> <time>",
and you will be returned to the menu.

$$$ mount/foreign mka500:
%MOUNT-I-MOUNTED, IBACKU mounted on _MKA500:
$$$ mount dka0: tricksys
%MOUNT-I-MOUNTED, TRICKSYS mounted on _DKA0:
$$$ backup/rewind/image/verify dka0: mka500:ibacku/save
%BACKUP-I-NOBACKUP, DKA0:[SYS0.SYSEXE]PAGEFILE.SYS;1 data not copied,
file marked NOBACKUP
%BACKUP-I-NOBACKUP, DKA0:[SYS0.SYSEXE]SWAPFILE.SYS;1 data not copied,
file marked NOBACKUP
%BACKUP-I-NOBACKUP, DKA0:[SYS0.SYSEXE]SYS$ERRLOG.DMP;2 data not copied,
file marked NOBACKUP
%BACKUP-I-NOBACKUP, DKA0:[SYS0.SYSEXE]SYS$ERRLOG.DMP;1 data not copied,
file marked NOBACKUP
%BACKUP-I-NOBACKUP, DKA0:[SYS0.SYSEXE]SYSDUMP.DMP;1 data not copied,
file marked NOBACKUP
%BACKUP-I-STARTVERIFY, starting verification pass at 1-MAY-2013
13:05:34.12
%BACKUP-E-BLOCKLOST, block of MKA500:[]IBACKU.; lost due to
unrecoverable error
-BACKUP-E-HDRCRC, software header CRC error
%BACKUP-E-EOFMISMATCH, end-of-file position mismatch for DKA0:
[VMS$COMMON.CDSA.REGISTRY.HKEY_LOCAL_MACHINE.SOFTWARE.MDS]MANIFEST.;1
%BACKUP-E-VBNMISSING, DKA0:
[VMS$COMMON.CDSA.REGISTRY.HKEY_LOCAL_MACHINE.SOFTWARE.MDS]MANIFEST.;1
has missing blocks 1 through 8
%BACKUP-E-BLOCKLOST, block of MKA500:[]IBACKU.; lost due to
unrecoverable error
-BACKUP-E-HDRCRC, software header CRC error
%BACKUP-E-BLOCKLOST, block of MKA500:[]IBACKU.; lost due to
unrecoverable error
-BACKUP-E-HDRCRC, software header CRC error
%BACKUP-E-VBNMISSING, DKA0:
[VMS$COMMON.DECW$DEFAULTS.SYSTEM]XNL_IT_CH.UID;1 has missing blocks 17
through 24
%BACKUP-E-EOFMISMATCH, end-of-file position mismatch for DKA0:
[VMS$COMMON.DECW$DEFAULTS.SYSTEM]XNL_IT_IT.UID;1
%BACKUP-E-VBNMISSING, DKA0:
[VMS$COMMON.DECW$DEFAULTS.SYSTEM]XNL_IT_IT.UID;1 has missing blocks 1
through 6
%BACKUP-E-BLOCKLOST, block of MKA500:[]IBACKU.; lost due to
unrecoverable error
-BACKUP-E-HDRCRC, software header CRC error
%BACKUP-E-BLOCKLOST, block of MKA500:[]IBACKU.; lost due to
unrecoverable error
-BACKUP-E-HDRCRC, software header CRC error
%BACKUP-E-VBNMISSING, DKA0:[VMS$COMMON.KERBEROS.DOC]ADMIN-GUIDE.PS;1 has
missing blocks 372 through 386
%BACKUP-E-BLOCKLOST, block of MKA500:[]IBACKU.; lost due to
unrecoverable error
-BACKUP-E-HDRCRC, software header CRC error
%BACKUP-E-BLOCKLOST, block of MKA500:[]IBACKU.; lost due to
unrecoverable error
-BACKUP-E-HDRCRC, software header CRC error
%BACKUP-E-VBNMISSING, DKA0:[VMS$COMMON.SSL.ALPHA_EXE]SSL_TASK.EXE;1 has
missing blocks 770 through 784
%BACKUP-E-BLOCKLOST, block of MKA500:[]IBACKU.; lost due to
unrecoverable error
-BACKUP-E-HDRCRC, software header CRC error
%BACKUP-E-BLOCKLOST, block of MKA500:[]IBACKU.; lost due to
unrecoverable error
-BACKUP-E-HDRCRC, software header CRC error
%BACKUP-E-VBNMISSING, DKA0:[VMS$COMMON.SSL.TEST]EVP_TEST.EXE;1 has
missing blocks 239 through 253
%BACKUP-E-BLOCKLOST, block of MKA500:[]IBACKU.; lost due to
unrecoverable error
-BACKUP-E-HDRCRC, software header CRC error
%BACKUP-E-VBNMISSING, DKA0:[VMS$COMMON.SSL.TEST]RSA_TEST.EXE;1 has
missing blocks 200 through 214
%BACKUP-E-INVSTRUCT, invalid structure level in save set
%BACKUP-E-BLOCKLOST, block of MKA500:[]IBACKU.; lost due to
unrecoverable error
-BACKUP-E-HDRCRC, software header CRC error
%BACKUP-E-VBNMISSING, DKA0:
[VMS$COMMON.SYS$KEYMAP.XKB.SYMBOLS.DIGITAL]RUSSIAN.;1 has missing blocks
6 through 20
%BACKUP-E-BLOCKLOST, block of MKA500:[]IBACKU.; lost due to
unrecoverable error
-BACKUP-E-HDRCRC, software header CRC error
%BACKUP-E-BLOCKLOST, block of MKA500:[]IBACKU.; lost due to
unrecoverable error
-BACKUP-E-HDRCRC, software header CRC error
%BACKUP-E-VBNMISSING, DKA0:[VMS$COMMON.SYS$LDR]ISCSI$SYMBOLS.STB;1 has
missing blocks 450 through 464
%BACKUP-E-BLOCKLOST, block of MKA500:[]IBACKU.; lost due to
unrecoverable error
-BACKUP-E-HDRCRC, software header CRC error
%BACKUP-E-BLOCKLOST, block of MKA500:[]IBACKU.; lost due to
unrecoverable error
-BACKUP-E-HDRCRC, software header CRC error
%BACKUP-E-VBNMISSING, DKA0:[VMS$COMMON.SYS$LDR]NET$TRANSPORT_OSI.EXE;1
has missing blocks 1112 through 1126
%BACKUP-E-BLOCKLOST, block of MKA500:[]IBACKU.; lost due to
unrecoverable error
-BACKUP-E-HDRCRC, software header CRC error
%BACKUP-E-BLOCKLOST, block of MKA500:[]IBACKU.; lost due to
unrecoverable error
-BACKUP-E-HDRCRC, software header CRC error
%BACKUP-E-VBNMISSING, DKA0:[VMS$COMMON.SYS$LDR]SHELL8K.STB;1 has missing
blocks 41 through 41
%BACKUP-E-VBNMISSING, DKA0:[VMS$COMMON.SYS$LDR]SPL$DEBUG.EXE;1 has
missing blocks 1 through 13
%BACKUP-E-BLOCKLOST, block of MKA500:[]IBACKU.; lost due to
unrecoverable error
-BACKUP-E-HDRCRC, software header CRC error
%BACKUP-E-BLOCKLOST, block of MKA500:[]IBACKU.; lost due to
unrecoverable error
-BACKUP-E-HDRCRC, software header CRC error
%BACKUP-E-VBNMISSING, DKA0:[VMS$COMMON.SYS$LDR]SYS$DEDRIVER.EXE;1 has
missing blocks 208 through 222
%BACKUP-E-BLOCKLOST, block of MKA500:[]IBACKU.; lost due to
unrecoverable error
-BACKUP-E-HDRCRC, software header CRC error
%BACKUP-E-BLOCKLOST, block of MKA500:[]IBACKU.; lost due to
unrecoverable error
-BACKUP-E-HDRCRC, software header CRC error
%BACKUP-E-VBNMISSING, DKA0:[VMS$COMMON.SYS$LDR]SYS$IPC_SERVICES.EXE;1
has missing blocks 273 through 287
%BACKUP-E-BLOCKLOST, block of MKA500:[]IBACKU.; lost due to
unrecoverable error
-BACKUP-E-HDRCRC, software header CRC error
%BACKUP-E-BLOCKLOST, block of MKA500:[]IBACKU.; lost due to
unrecoverable error
-BACKUP-E-HDRCRC, software header CRC error
%BACKUP-E-VBNMISSING, DKA0:[VMS$COMMON.SYS$LDR]SYS$PCADRIVER.EXE;1 has
missing blocks 112 through 126
%BACKUP-E-BLOCKLOST, block of MKA500:[]IBACKU.; lost due to
unrecoverable error
-BACKUP-E-HDRCRC, software header CRC error
%BACKUP-E-BLOCKLOST, block of MKA500:[]IBACKU.; lost due to
unrecoverable error
-BACKUP-E-HDRCRC, software header CRC error
%BACKUP-E-VBNMISSING, DKA0:[VMS$COMMON.SYS$LDR]SYS$SHDRIVER.EXE;1 has
missing blocks 773 through 787
%BACKUP-E-BLOCKLOST, block of MKA500:[]IBACKU.; lost due to
unrecoverable error
-BACKUP-E-HDRCRC, software header CRC error
%BACKUP-E-BLOCKLOST, block of MKA500:[]IBACKU.; lost due to
unrecoverable error
-BACKUP-E-HDRCRC, software header CRC error
%BACKUP-E-VBNMISSING, DKA0:[VMS$COMMON.SYS$LDR]SYSTEM_PRIMITIVES.EXE;1
has missing blocks 417 through 431
%BACKUP-E-BLOCKLOST, block of MKA500:[]IBACKU.; lost due to
unrecoverable error
-BACKUP-E-HDRCRC, software header CRC error
%BACKUP-E-VBNMISSING, DKA0:[VMS$COMMON.SYS$LDR]TCPIP$NET_GLOBALS.STB;1
has missing blocks 292 through 306
%BACKUP-E-INVSTRUCT, invalid structure level in save set
%BACKUP-E-BLOCKLOST, block of MKA500:[]IBACKU.; lost due to
unrecoverable error
-BACKUP-E-HDRCRC, software header CRC error
%BACKUP-E-VBNMISSING, DKA0:[VMS$COMMON.SYSCBI.DECW$CBI]DECW00100.CBI;1
has missing blocks 4 through 18
%BACKUP-E-BLOCKLOST, block of MKA500:[]IBACKU.; lost due to
unrecoverable error
-BACKUP-E-HDRCRC, software header CRC error
%BACKUP-E-BLOCKLOST, block of MKA500:[]IBACKU.; lost due to
unrecoverable error
-BACKUP-E-HDRCRC, software header CRC error
%BACKUP-E-VBNMISSING, DKA0:[VMS$COMMON.SYSEXE]ALPHA_MACRO.EXE;1 has
missing blocks 8175 through 8189
%BACKUP-E-BLOCKLOST, block of MKA500:[]IBACKU.; lost due to
unrecoverable error
-BACKUP-E-HDRCRC, software header CRC error
%BACKUP-E-BLOCKLOST, block of MKA500:[]IBACKU.; lost due to
unrecoverable error
-BACKUP-E-HDRCRC, software header CRC error
%BACKUP-E-VBNMISSING, DKA0:[VMS$COMMON.SYSEXE]CDSA$SIGN.EXE;1 has
missing blocks 1098 through 1112
%BACKUP-E-BLOCKLOST, block of MKA500:[]IBACKU.; lost due to
unrecoverable error
-BACKUP-E-HDRCRC, software header CRC error
%BACKUP-E-BLOCKLOST, block of MKA500:[]IBACKU.; lost due to
unrecoverable error
-BACKUP-E-HDRCRC, software header CRC error
%BACKUP-E-VBNMISSING, DKA0:[VMS$COMMON.SYSEXE]COBOL.EXE;1 has missing
blocks 7734 through 7748
%BACKUP-E-BLOCKLOST, block of MKA500:[]IBACKU.; lost due to
unrecoverable error
-BACKUP-E-HDRCRC, software header CRC error
%BACKUP-E-BLOCKLOST, block of MKA500:[]IBACKU.; lost due to
unrecoverable error
-BACKUP-E-HDRCRC, software header CRC error
%BACKUP-E-VBNMISSING, DKA0:[VMS$COMMON.SYSEXE]CTF$UI.EXE;1 has missing
blocks 234 through 248
%BACKUP-E-BLOCKLOST, block of MKA500:[]IBACKU.; lost due to
unrecoverable error
-BACKUP-E-HDRCRC, software header CRC error
%BACKUP-E-BLOCKLOST, block of MKA500:[]IBACKU.; lost due to
unrecoverable error
-BACKUP-E-HDRCRC, software header CRC error
%BACKUP-E-VBNMISSING, DKA0:[VMS$COMMON.SYSEXE]DEC-AXPVMS-DWMOTIF-
V0106.PCSI$DATABASE;1 has missing blocks 561 through 575
%BACKUP-E-BLOCKLOST, block of MKA500:[]IBACKU.; lost due to
unrecoverable error
-BACKUP-E-HDRCRC, software header CRC error
%BACKUP-E-BLOCKLOST, block of MKA500:[]IBACKU.; lost due to
unrecoverable error
-BACKUP-E-HDRCRC, software header CRC error
%BACKUP-E-VBNMISSING, DKA0:[VMS$COMMON.SYSEXE]DECW$CBI.EXE;1 has missing
blocks 184 through 198
%BACKUP-E-BLOCKLOST, block of MKA500:[]IBACKU.; lost due to
unrecoverable error
-BACKUP-E-HDRCRC, software header CRC error
%BACKUP-E-BLOCKLOST, block of MKA500:[]IBACKU.; lost due to
unrecoverable error
-BACKUP-E-HDRCRC, software header CRC error
%BACKUP-E-VBNMISSING, DKA0:[VMS$COMMON.SYSEXE]DECW$XKBEVD.EXE;1 has
missing blocks 104 through 118
%BACKUP-E-BLOCKLOST, block of MKA500:[]IBACKU.; lost due to
unrecoverable error
-BACKUP-E-HDRCRC, software header CRC error
%BACKUP-E-BLOCKLOST, block of MKA500:[]IBACKU.; lost due to
unrecoverable error
-BACKUP-E-HDRCRC, software header CRC error
%BACKUP-E-VBNMISSING, DKA0:[VMS$COMMON.SYSEXE]DXDTMSCREDIT.EXE;1 has
missing blocks 643 through 657
%BACKUP-E-BLOCKLOST, block of MKA500:[]IBACKU.; lost due to
unrecoverable error
-BACKUP-E-HDRCRC, software header CRC error
%BACKUP-E-VBNMISSING, DKA0:[VMS$COMMON.SYSEXE]GCU.EXE;1 has missing
blocks 1140 through 1154
%BACKUP-E-INVSTRUCT, invalid structure level in save set
%BACKUP-E-BLOCKLOST, block of MKA500:[]IBACKU.; lost due to
unrecoverable error
-BACKUP-E-HDRCRC, software header CRC error
%BACKUP-E-VBNMISSING, DKA0:[VMS$COMMON.SYSEXE]KRB$KTUTIL.EXE;1 has
missing blocks 46 through 60
%BACKUP-E-BLOCKLOST, block of MKA500:[]IBACKU.; lost due to
unrecoverable error
-BACKUP-E-HDRCRC, software header CRC error
%BACKUP-E-BLOCKLOST, block of MKA500:[]IBACKU.; lost due to
unrecoverable error
-BACKUP-E-HDRCRC, software header CRC error
%BACKUP-E-VBNMISSING, DKA0:[VMS$COMMON.SYSEXE]MACRO.EXE;1 has missing
blocks 2684 through 2698
%BACKUP-E-BLOCKLOST, block of MKA500:[]IBACKU.; lost due to
unrecoverable error
-BACKUP-E-HDRCRC, software header CRC error
%BACKUP-E-BLOCKLOST, block of MKA500:[]IBACKU.; lost due to
unrecoverable error
-BACKUP-E-HDRCRC, software header CRC error
%BACKUP-E-VBNMISSING, DKA0:[VMS$COMMON.SYSEXE]MACRO.EXE;1 has missing
blocks 12419 through 12433
Interrupt

$$$

[abrsvc]

Since the verify pass appeared to work, it would suggest that the tape is good. Try simply running a cleaning tape through the drive. Attempt the restore again and let us know the results.

Dan

[Jan-Erik Soderholm]

You got it all wrong...
The errors appeared duing BACKUP, not RESTORE.
The clips was with 8.3 and 8.4.

[Johnny Billquist]

On 2013-05-01 15:14, abrsvc wrote:
> Since the verify pass appeared to work, it would suggest that the tape is good. Try simply running a cleaning tape through the drive. Attempt the restore again and let us know the results.

Me thinks you only read part of the mail, and only looked at the 8.3
part of the transcript, which worked just fine. Read the whole post. :-)

Johnny

--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: b...@softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol

[Stephen Hoffman]

On 2013-05-01 12:59:59 +0000, Ralf Folkerts said:

> Now, I don't really need 8.4 for my hobbyist-system at all. However,
> does anyone have an Idea what might be going on?

It appears BACKUP has detected tape errors during the verification
pass. That's not uncommon with these linear rust-based storage
technologies, either.

Potential triggers: Dirty tape heads, dirty or bad tape cartridge,
buggy software, or a bad cable or bad termination or a bad controller,
from easiest to "worst".

Potential remediation: Cleaning cartridge, try different media and
preferably from a different batch, start testing with different
versions of the software, load the current SCSI and BACKUP and UPDATE
and PCSI kits, check the cables and swap the drive, from easiest to
"worst".

[Jan-Erik Soderholm]

Of course...

But why only with 8.4 and not with 8.3?
Is 8.4 BACKUP *that* better in detecting
tape errors then 8.3 BACKUP is?

Jan-Erik.

[abrsvc]

Yep, I read the second pass incorrectly. The same "solution" does apply however. These errors are common with tapes when the heads get dirty.

Also, turn on compaction if the drive supports it. I believe that SA backup supports it as well. (/media=compact)

This should speed up the task, and use less tape maybe get it all in on the good part...

Dan

[Stephen Hoffman]

On 2013-05-01 14:49:49 +0000, Jan-Erik Soderholm said:

> But why only with 8.4 and not with 8.3?

All I've seen so far in this thread is that BACKUP operations
apparently stopped working somewhere between testing on V8.3 and
testing on V8.4.

Why?

The problem could be due to a big o' wad of rust dropping off the
substrate and clog up the heads. Or maybe some cat fur relocated into
the tape path during its visit. Or, well, who knows?

It's a tape drive, it's particularly an old tape drive, and probably
also with old media.

Not sure there are any other reasons needed.

> Is 8.4 BACKUP *that* better in detecting tape errors then 8.3 BACKUP is?

If y'all want to rule in or rule out the differences, try some more
tests with different versions. It wasn't (and isn't) clear to me if
the V8.3 configuration was re-tested with the same cartridge and drive,
for instance.

This problem may be software, or it may have nothing to do with the
software version, and everything to do with the usual "It's a tape
drive, they clog and they stretch and they fail" sorts of hardware
problems. When a tape drive goes weird, it's usually clogged tape
heads, bad meda, or a failed tape drive. Can it be the software?
Sure. But as with any troubleshooting, run some tests. Clean some
heads. Test and swap some parts.



--
Pure Personal Opinion | HoffmanLabs LLC

[Rob Brown]

On 2013-05-01, Stephen Hoffman <seao...@hoffmanlabs.invalid> wrote:
> On 2013-05-01 14:49:49 +0000, Jan-Erik Soderholm said:
>
>> But why only with 8.4 and not with 8.3?
>
> All I've seen so far in this thread is that BACKUP operations
> apparently stopped working somewhere between testing on V8.3 and
> testing on V8.4.

Since the OP backed up using V8.4 first, which failed, and then tried
with V8.3, which worked, we need an explanation why BACKUP operations
apparently started working somewhere between testing on V8.4 and
testing on V8.3.



--

Rob Brown mylas...@gmcl.com

[Jan-Erik Soderholm]

Right.
And what was copied *here* was actualy re-runs of both, not?
I think it's shown that 8.3 and 8.4 BACKUP gives different results.

Talking about dirt on the heads is going the wrong track.

But OK, re-running the both tests after a cleaning of
the drive is always possible.

Jan-Erik.

[Jan-Erik Soderholm]

abrsvc wrote 2013-05-01 16:54:

> Yep, I read the second pass incorrectly. The same "solution" does apply
> however. These errors are common with tapes when the heads get dirty.

And BACKUP 8.3 is not that sensitive to that?

>
> This should speed up the task, and use less tape maybe get it all in on
> the good part...
>

Does BACKUP 8.3 use "less tape" then BACKUP 8.4 ?

Jan-Erik.

> Dan
>

[Stephen Hoffman]

Tape drives don't need a reason to show weird behavior.

Clean the drive, swap for a different cartridge or different batch of
cartridges, etc.

As for OpenVMS V8.4, I had (other) issues with that prior to about UPDATE V5.

[Ralf Folkerts]

Ralf Folkerts wrote:

> [...]

> Will paste a transcript from a 8.3 boot/backup and a 8.4 boot/backup
> below. Both are from the same system, even the same Tape is being
> used... I cancelled the 8.4 verify, as it took ~3 times the time the
> complete backup/verify took with the 8.3 system...
>
> mka500.5.0.6.0 MKA500 Quantum DLT4000 CD4B
> dka0.0.0.6.0 DKA0 IBM DNES-309170 SAH0
>

> [...]

Hi all,

thanks for all the replies! While reading them I recognized that I
should actually have put more Details in.

The Problem first occured to me several weeks ago, using a "Jedi" 8.4
alpha CD. Then Downloaded the Hobbyist 8.4 Image. Same Problems during
backup.

Also, the "original" Sequence was:

- Boot off 8.4 CD, try backup/verify. Got Errors as those posted for 8.4
in my first post.

- Use another Cartridge. Check again, same errors again.

- Exchange Cable, Terminator, Check again, same errors.

- Check Tape Drive on a AIX 5.3 System (tar several Filesystems, then
test). No errors.

- Set everything back to its "original" state (i.e. use the "first"
Cartridge, Terminator, Cable), try again with 8.4 - got Errors.

- Booted off the 8.3 CD - and backup/verify ran fine. Had it running
three times, to make sure - no single errors was shown.

- Then booted off 8.4 CD again, got the Errors.

- Then finally booted off 8.3 CD - backup/verify ran thru just fine.

On my second try (the one with the Hobbyist CD) I didn't do all the
steps again; so I didn't test the Drive again on another System and also
did not change Cable/Cartridge etc. and also did not perform that many
trial-runs.

As I ran all that using the serial console I just connected it to a BSD-
Box today and ran just a "very short version" of the Backups to capture
the exact sequence and errors. So, the Cartridge that worked fine on the
System booted off the 8.3 CD a few weeks ago did work fine on 8.3 today,
too. And that same Cartridge then caused errors on 8.4 (and I'm sure it
would work just fine should I boot again off the 8.3 CD).

Also note, that the "use cleaning tape" LED does not
light/flash/whatever. Its just off. I'm reluctant to put some debris
into the drive just to check if that LED might be broken. But I did see
it light when using old, worn out tapes (i.e. when the drive detects
read-errors).

So I think both the drive and the tape should be OK, as should the SCSI-
bus. It looks as if the 8.4 has problems on that box, either with that
Type of Drive or Drive-Firmware or...

I wanted to test that Tape-Drive on a PWS500 using stand-alone backup
from the 8.4 CD -- but didn't do so, now.

Btw: I also checked the 8.4 Upgrade and Installation Manual for some
notes re. AS255/233 or backup, but didn't find anything usefull.

Cheers,
_ralf_

[Bob Koehler]

In article <slrnko2hgb...@libra.gmcl.internal>, Rob Brown <br...@libra.gmcl.internal> writes:
>
> Since the OP backed up using V8.4 first, which failed, and then tried
> with V8.3, which worked, we need an explanation why BACKUP operations
> apparently started working somewhere between testing on V8.4 and
> testing on V8.3.
>

Because the big old glob of rust got pushed through the heads during
the 8.4 error and fell out of the way, so it wasn't present during
the 8.3 pass?

Actually, hard to tell without inspecting the hardware. If there's
time, is it repeatable?

[Stephen Hoffman]

On 2013-05-01 17:09:19 +0000, Ralf Folkerts said:

> thanks for all the replies! While reading them I recognized that I

> should actually have put more Details in...

Test with a recent/current UPDATE kit installed on V8.4, if you haven't
already tried that.
The Alpha boxes I'm testing with have VMS84A_UPDATE V6.0 loaded.

[Rich Jordan]

On May 1, 12:55 pm, Stephen Hoffman <seaoh...@hoffmanlabs.invalid>
wrote:

I don't have an answer but I was reviewing a V8.4 upgrade we did last
year, and my notes had a warning: "Use the V8.3 boot CD instead of the
V8.4 CD due to known problems with V8.4 standalone". But I can't find
my notes on what the problems were. V8.4 base definitely had
directory corruption issues in use and I remember folks saying they
had issues after using the V8.4 standalone to create a new disk image;
I don't recall tape issues but there had to be some related ones for
that warning to be in the document.

[Phillip Helbig---undress to reply]

In article
<23e4888c-dcba-4032...@y12g2000yqb.googlegroups.com>,

Rich Jordan <jor...@ccs4vms.com> writes:

> I don't have an answer but I was reviewing a V8.4 upgrade we did last
> year, and my notes had a warning: "Use the V8.3 boot CD instead of the
> V8.4 CD due to known problems with V8.4 standalone". But I can't find
> my notes on what the problems were. V8.4 base definitely had
> directory corruption issues in use and I remember folks saying they
> had issues after using the V8.4 standalone to create a new disk image;
> I don't recall tape issues but there had to be some related ones for
> that warning to be in the document.

What about the downloadable hobbyist 8.4 image?

I'm considering finally going from 7.3-2 via 8.3 (have the hobbyist CD)
to 8.4 (with the downloadable hobbyist image). I'm still debating
whether it is worth it because of the restricted patch access.

What about the 8.4 image and current update patch via the hobbyist
programme; are they safe enough? There were apparently some serious
problems with 8.4.

[David Froble]

If you read the original post carefully, you will see this sequence:

1) Using 8.4, backup with verify failed
2) Using 8.3, backup with verify worked
3) Again, using 8.4, backup with verify failed

And I believe the OP mentioned using the same tape on all attempts.

You're not going to get me to believe the cat hair watched for 8.4
activity before deciding to get involved.

Yeah, tape drives suck, and every day older they suck even more. But
even tape drives usually are somewhat consistent.

If a spare disk is available, I'd like to see a backup and verify to the
disk, however, if the 8.4 software has a problem with tape drives, the
test with a disk may be meaningless.

[Rich Jordan]

On May 1, 2:54 pm, hel...@astro.multiCLOTHESvax.de (Phillip Helbig---
undress to reply) wrote:
> In article
> <23e4888c-dcba-4032-8aeb-cf53aacbc...@y12g2000yqb.googlegroups.com>,

No idea; the hobbyist kit has VMS plus the update kit, but not VMS
with the update applied as far as I know so I'd expect a standalone
boot of the disk to be no different than the factory V8.4 disk. We
use V8.3 standalone to do the safety image backups, and use the V8.4
disk to actually install/upgrade the OS. I have not tried using an
upgraded V8.4 to create a minimal boot environment for image backups
so don't know how that would work.

[Stephen Hoffman]

On 2013-05-01 20:16:25 +0000, David Froble said:

> If you read the original post carefully, you will see this sequence:

OK. So next time, you can write the problem statement. :-)

I'd still follow the same troubleshooting sequence I posted.

...Clean the drive, swap the cartridge, patch the OS, check the SCSI
and swap the drive.

[Jan-Erik Soderholm]

Stephen Hoffman wrote 2013-05-01 22:38:

> ... patch the OS,

How du you patch the 8.4 CD ?

The whole point of the initial question was
differences between the 8.3 and 8.4 *CD*
distributions, not ?

Jan-Erik.

[Phillip Helbig---undress to reply]

In article
<9f2df4d9-6958-40ae...@e13g2000yqp.googlegroups.com>,

Well, I don't need to make a backup from the CD menu since I would just
break a shadow set after shutting down the system. So I guess my
question is whether the 8.4 image can be used for installation and if,
with the update patch, it is good enough.

[Stephen Hoffman]

On 2013-05-01 20:55:34 +0000, Jan-Erik Soderholm said:

> Stephen Hoffman wrote 2013-05-01 22:38:
>
>> ... patch the OS,
>
> How du you patch the 8.4 CD ?

I'm going to assume you don't really want to know how to do that,
though remastering the kit isn't difficult.

> The whole point of the initial question was differences between the 8.3
> and 8.4 *CD* distributions, not ?

I clearly have no idea what the question was, and also have an
ever-decreasing interest in anything to do with this question.

[Jan-Erik Soderholm]

Yes, it is "good enough"...

[Jan-Erik Soderholm]

Stephen Hoffman wrote 2013-05-02 01:04:
> On 2013-05-01 20:55:34 +0000, Jan-Erik Soderholm said:
>
>> Stephen Hoffman wrote 2013-05-01 22:38:
>>
>>> ... patch the OS,
>>
>> How du you patch the 8.4 CD ?
>
> I'm going to assume you don't really want to know how to do that, though
> remastering the kit isn't difficult.
>

There was a reported difference between the BACKUPs on the
8.3 CD and the 8.4 CD.

The solution *you* had was to "patch the OS".

I simply asked how to patch the OS on the CD.

Is the ordinary user of the 8.4 CD dist expected to
"remaster" the CD dist ?

Now, I have used the 8.4 CD for upgrades on several system
without any (known) problems, but I have not used stand
alone BACKUP from the CD menu.

Other reports in this thread seems to imply that there
actualy *is* a problem with the BACKUP on the 8.4 CD.

>> The whole point of the initial question was differences between the 8.3
>> and 8.4 *CD* distributions, not ?
>
> I clearly have no idea what the question was, and also have an
> ever-decreasing interest in anything to do with this question.
>

I understand that. In some way it seems you totaly misunderstood
the whole issue from the start.

Jan-Erik.


>

[David Froble]

Stephen Hoffman wrote:
> On 2013-05-01 20:16:25 +0000, David Froble said:
>
>> If you read the original post carefully, you will see this sequence:
>
> OK. So next time, you can write the problem statement. :-)
>
> I'd still follow the same troubleshooting sequence I posted.
>
> ...Clean the drive, swap the cartridge, patch the OS, check the SCSI and
> swap the drive.
>
>

Oh, I would too.

And the OP has since stated the activity in more detail, which would
have been better in the OP.

It also seems that some have pointed out that there is a documented
problem with the 8.4 backup on the distribution media.

Funny how these things seem to have to evolve rather than being clear
from the beginning.

[Jan-Erik Soderholm]

David Froble wrote 2013-05-02 08:43:
> Stephen Hoffman wrote:
>> On 2013-05-01 20:16:25 +0000, David Froble said:
>>
>>> If you read the original post carefully, you will see this sequence:
>>
>> OK. So next time, you can write the problem statement. :-)
>>
>> I'd still follow the same troubleshooting sequence I posted.
>>
>> ...Clean the drive, swap the cartridge, patch the OS, check the SCSI and
>> swap the drive.
>>
>>
>
> Oh, I would too.
>
> And the OP has since stated the activity in more detail,
> which would have been better in the OP.
>

I still don't see where "patch the OS" comes into the picture.

> It also seems that some have pointed out that there is a documented problem
> with the 8.4 backup on the distribution media.
>

Well, someone had some *private* docs. :-)
Has any public/official docs been mentioned?

> Funny how these things seem to have to evolve rather than being clear from
> the beginning.

Yes, the fact that the CD distro isn't OK is a major fault, IMHO.

Jan-Erik.

[johnso...@gmail.com]

In the future, it might be more useful for questions like this to be posted
to something like stackoverflow.com. If you haven't done so, do check out
the site. The creators have done a terrific job at creating a system that
discourages trolling while encouraging focused questions and thoughtful
polite answers.

The back and forth seen here isn't really the fault of the OP or any of
the people who chose to help. The structure, or lack of it, in these
conversations is the real cause. Change the participants, but keep the
structure, and you will almost always have the same outcome.

Sites like stackoverflow.com attempt to resolve that. I think they've
succeeded. It's also a great place to go to find answers to existing
questions. I'm finding that if I can compose my question just right
in the google search box, it will almost always take me to the right
question on stackoverflow or one of its sister sites.

EJ

[Stephen Hoffman]

On 2013-05-02 06:11:01 +0000, Jan-Erik Soderholm said:

> Stephen Hoffman wrote 2013-05-02 01:04:
>> On 2013-05-01 20:55:34 +0000, Jan-Erik Soderholm said:
>>
>>> Stephen Hoffman wrote 2013-05-01 22:38:
>>>
>>>> ... patch the OS,
>>>
>>> How du you patch the 8.4 CD ?
>>
>> I'm going to assume you don't really want to know how to do that, though
>> remastering the kit isn't difficult.
>>
>
> There was a reported difference between the BACKUPs on the
> 8.3 CD and the 8.4 CD.
>
> The solution *you* had was to "patch the OS".
>
> I simply asked how to patch the OS on the CD.
>
> Is the ordinary user of the 8.4 CD dist expected to
> "remaster" the CD dist ?
>
> Now, I have used the 8.4 CD for upgrades on several system
> without any (known) problems, but I have not used stand
> alone BACKUP from the CD menu.
>
> Other reports in this thread seems to imply that there
> actualy *is* a problem with the BACKUP on the 8.4 CD.

Thank you for the restatement of the problem.

Though I'd prefer some more evidence, I really don't care if the distro
is actually screwed up. That's happened before. It'll probably happen
again. Remastering the distro, and working around a bad distro, are
both easy. If you have ancient hardware or not enough hardware, then
you'll certainly have problems, though that's to be expected. With
insufficient hardware, you can spend some money on hardware or on
support, or sort out how to deal with what hardware you do have
available. Tape drives have failed, as have tape cartridges, as have
SCSI bus parts, and ancient disk and tape and server hardware can be
flaky.

I don't expect VMS "to just work" with the typical complex
configurations I'm dealing with in recent years, and I don't think
anybody that looks at it seriously would think so, either. (I
encountered a case where PCSI deleted VMS system files, for instance.)
By present standards, VMS is definitely not friendly to new users. All
of which means VMS system managers can be involved with
troubleshooting, work-arounds, reading docs, reinstallations,
remastering, and the occasional calls to support.

Whether HP decides to remaster the V8.4 distro with the current patches
loaded (if this is a VMS bug), you'll have to ask them. In years past,
there'd probably have been a subsequent release with a roll-up of
patches made available by now. We're coming up on three years next
month, so we're in "uncharted territory" as far as software releases go.

>
>>> The whole point of the initial question was differences between the 8.3
>>> and 8.4 *CD* distributions, not ?
>>
>> I clearly have no idea what the question was, and also have an
>> ever-decreasing interest in anything to do with this question.
>
> I understand that. In some way it seems you totaly misunderstood the
> whole issue from the start.

Thank you, Captain Obvious.

[Jan-Erik Soderholm]

Stephen Hoffman wrote 2013-05-02 14:55:

>
> ...I really don't care if the distro is
> actually screwed up.

The OP seemed to care. That is enough for me.
I couldn't care less if somebody else cares or not.

Jan-Erik.

[Stephen Hoffman]

On 2013-05-02 07:43:41 +0000, Jan-Erik Soderholm said:

> Yes, the fact that the CD distro isn't OK is a major fault, IMHO.

While it's certainly unfortunate and certainly not a desirable state of
affairs and definitely something HP would want to look at, distro bugs
can and do happened before. Ask anybody that was working with DDS and
DVE in the early versions with that support, for instance.

Assuming that there will be new VMS releases — the August 2012 roadmap
that's currently posted doesn't indicate any releases past V8.4 — there
will probably be some bugs somewhere in some of those distros, too.

Even remastered distros can have bugs.

There are always work-arounds.

All this independent of whether this tape drive BACKUP verification
discussion is a VMS bug, or some other issue.

[Stephen Hoffman]

You seem to care that the distro is screwed up, though. I'm simply
pointing out that in the grand scheme, a screwed-up VMS distro isn't
unheard of, nor is it an insurmountable problem, and particularly given
there are two good workaround here (assuming this is a VMS bug): use a
different V8.3 distro, or remaster the V8.4 distro.

[Stephen Hoffman]

BTW, I apologize for my rude response. I read the OP's message
quickly, and answered what I thought was the question. If the distro
really is screwed up, c'est la VMS. That's easy enough to fix.

[Jan-Erik Soderholm]

Stephen Hoffman wrote 2013-05-02 15:51:> On 2013-05-02 13:21:49 +0000,

Jan-Erik Soderholm said:
>
>> Stephen Hoffman wrote 2013-05-02 14:55:
>>
>>>
>>> ...I really don't care if the distro is
>>> actually screwed up.
>>
>> The OP seemed to care. That is enough for me.
>> I couldn't care less if somebody else cares or not.
>
> BTW, I apologize for my rude response.

Accepted.

> I read the OP's message quickly,

Yes, that was my impression too. And everyone
else jumping on the dirt-on-the-heads-train
made the same mistake, IMHO.

> You seem to care that the distro is screwed up, though.

Yes, I do. I have two customer systems that will be upgraded
to 8.4 in a few weeks. This upgrade is done from the CD distro
(but copied to a SAN FC volume). It's good to know that the
BACKUP version on that distro is, hm, questionable...


Regards,
Jan-Erik

[Stephen Hoffman]

Some guesses...

You're probably not going to hit that particular BACKUP bug with the
way you're likely to do the upgrade. You'll probably be going
disk-to-disk. Even if you do use disk-to-tape as part of your upgrade
processing, you likely have an immediate backup plan: use an earlier
distro.

You're most of the way to remastering the CD distro kit in any case,
too. If you really wanted to do that.

Whether V8.4 works for you or not — I'd load a recent UPDATE, as there
are various other issues in the earlier UPDATE incarnations and in V8.4
— is only reasonably certain with some local application testing. I
hit some corner cases in some local stuff.

If you're concerned about these sorts of bugs, communicate that
directly with HP. Also perform a general review of your longer-term
use of VMS as a platform for your applications, too. Look carefully at
where your applications are now and where VMS is now, at where it's all
likely headed (no new releases are listed in the roadmap, with new
features arriving via patches), and at whether all this lines up with
your business expectations, requirements, budget and schedules. For as
long as your current applications or VMS — or any other product, for
that matter — suffices for your needs, certainly continue to use it and
maintain it. But if there's a better option available — and however
"better" is defined locally — find it and use it.

Put another way, have a testing plan, have a lowercase-b backup plan,
and have plans for backups.

TL;DR: "deal with it".

[Ralf Folkerts]

Ralf Folkerts wrote:

> wanted to Update my Hobbyist-AS255/233 from OpenVMS 8.3. to 8.4 -
> and tried to create a stand-alone backup using the 8.4 CD to Tape
> before that.
> [...]

Hi all,

thanks for the many replies! Its just too much to reply individually, so
I'll -again- reply to myself :(

So it seems that the produced Hobbyist-Image contains the plain 8.4
which might/does have some trouble with backup but will install some
patches so the updated system's backup will just run fine after the
Update. However, for standlone backup I'd have to remaster the CD or
just use the good old 8.3 CD.

Thanks!

Re. the valid point that I didn't post all the tests I performed during
my initial post: I think it's caused by my personal stance: I expect
people in "technical" groups (like cov) to be rather professionals than
"amateurs". As it would be just plain stupid to complain about backup-
Problems (to Tape) just after ONE failing backup I always assume people
to perform multiple tests, diagnostics etc. And I post that way, too.
Sorry for the confusion on that... I'll try to take into account that
people look for the most obvious reasons first and don't rule em out as
I usually do...

Re. the question what I wanted to ask... Well, I could have asked a
rather long list of specific (closed) questions, multiple choice style:
"Is the AS255 no longer supported on 8.4?" "Is the 53C874 no longer
supported on 8.4?" "Is a DLT4000 Drive no longer supported on 8.4?" "Is
backup using Tape Drives Compression no longer supported", ... I prefer
open questions, however, so I asked "However, does anyone have an Idea
what might be going on?". I did expect to read sthg. like "Read the
Release Notes, they clearly state that your system is no longer
supported"...

So, thanks again to all for the help and sorry for some confusion. Will
try to update the AS255 to 8.4 this weekend...

Cheers,
_ralf_

[Jan-Erik Soderholm]

Stephen Hoffman wrote 2013-05-02 20:08:
> On 2013-05-02 14:27:34 +0000, Jan-Erik Soderholm said:
>
>> Stephen Hoffman wrote 2013-05-02 15:51:> On 2013-05-02 13:21:49 +0000,
>> Jan-Erik Soderholm said:
>>
>> > You seem to care that the distro is screwed up, though.
>>
>> Yes, I do. I have two customer systems that will be upgraded
>> to 8.4 in a few weeks. This upgrade is done from the CD distro
>> (but copied to a SAN FC volume). It's good to know that the
>> BACKUP version on that distro is, hm, questionable...
>
> Some guesses...
>
> You're probably not going to hit that particular BACKUP bug with the way
> you're likely to do the upgrade. You'll probably be going disk-to-disk.
> Even if you do use disk-to-tape as part of your upgrade processing, you
> likely have an immediate backup plan: use an earlier distro.
>
> You're most of the way to remastering the CD distro kit in any case, too.
> If you really wanted to do that.
>

Since the "distro" now is on a regular R/W disk, I guess the
"remastering" gets a little easier. Maybe as easy as replacing
the BACKUP.EXE from a later UPDATE kit. But then, we will probably
never run the BACKUP image from the distro itself.

> Whether V8.4 works for you or not

We have had 8.4 for a year+ on our test box (similar DS20e with
storage on the same IBM DS8000 SAN) and I think that all
software components have been tested. There are other fun
stuff such as the long time unsupported "Rdb Transparent
Gateway for Oracle".

Now it's time for "prod" and "dev", both on 8.2 now.

> — I'd load a recent UPDATE, as there are
> various other issues in the earlier UPDATE incarnations and in V8.4 — is
> only reasonably certain with some local application testing. I hit some
> corner cases in some local stuff.

We'll load the latest UPDATE. We are on support. :-)

>
> If you're concerned about these sorts of bugs, communicate that directly
> with HP. Also perform a general review of your longer-term use of VMS as a
> platform for your applications, too.

No problem, the customer has plans for that... :-)
Thay are *very* happy with the services delivered from the
VMS systems today. We are two 1/2 time guys supporting
this. The factory runs two shifts 05:30 - 23:00, which
has been identified as a "problem" since they runs
"unsupported" outside of office hours.

> Look carefully at where your
> applications are now and where VMS is now, at where it's all likely headed
> (no new releases are listed in the roadmap, with new features arriving via
> patches), and at whether all this lines up with your business expectations,
> requirements, budget and schedules. For as long as your current
> applications or VMS — or any other product, for that matter — suffices for
> your needs, certainly continue to use it and maintain it. But if there's a
> better option available — and however "better" is defined locally — find it
> and use it.
>

I (we in the group) are not part of the overall strategic planning.
We are simply OpenVMS consultants supporting the systems as
long as they want to keep them. :-)

[Stephen Hoffman]

On 2013-05-02 19:38:08 +0000, Jan-Erik Soderholm said:

> Since the "distro" now is on a regular R/W disk, I guess the
> "remastering" gets a little easier. Maybe as easy as replacing the
> BACKUP.EXE from a later UPDATE kit. But then, we will probably never
> run the BACKUP image from the distro itself.

Install the patch kit onto a BACKUP /IMAGE copy of the installation
disk (as you're likely to do), BACKUP /IMAGE the results into a ~700 MB
LD device, dismount the LD device, block-burn the backing file to
optical media, done. (I don't know if the VMS UPDATE kits work
properly if you skip the intermediate copy and go directly to
installing on the ~700 MB device using PCSI$DESTINATION or PRODUCT
INSTALL /DESTINATION, but that might be worth a try.)

[Keith Parris]

On 5/2/2013 12:08 PM, Stephen Hoffman wrote:
> If you're concerned about these sorts of bugs, communicate that directly
> with HP. Also perform a general review of your longer-term use of VMS
> as a platform for your applications, too. Look carefully at where your
> applications are now and where VMS is now, at where it's all likely
> headed (no new releases are listed in the roadmap, with new features
> arriving via patches),

It has arguably been just as successful to ship new features (and even
new hardware support with a "remastered" 8.4 DVD) with an update kit as
in the old days to ship an 8.4-1 (or 8.4-1H1) release, and there is less
disruption on the user base.

There is a downside in that new features and new hardware support is
less visible in the marketplace, arguably adding to the myth that
OpenVMS is in maintenance-only mode.

In terms of where it's likely headed (and when): I've uploaded a version
of my Boot Camp 2013 presentation on "Possible Future Directions for the
OpenVMS Ecosystem" with speaker notes to the Connect Dropbox at
https://www.dropbox.com/sh/77vbsdlg8w5ejt0/BCXgXHReTb .

[Ketan]

Hi,

This issue has been fixed in VMS84A_UPDATE-V0400 kit. Please refer
section “5.2.51 BACKUP/IMAGE/VERIFY fails with BACKUP-E-POSERROR”
from the release note VMS84A_UPDATE-V0400.TXT for more details.
The fix is also part of VMS84I_UPDATE-V0400 kit. Please refer section
“ 5.2.57 BACKUP/IMAGE/VERIFY fails with BACKUP-E-POSERROR” from the
release note VMS84I_UPDATE-V0400.TXT for more details.

Below is the extract from the release note:

5.2.51 BACKUP/IMAGE/VERIFY fails with BACKUP-E-POSERROR

5.2.51.1 Problem Description:

When the system is booted from Version 8.4 media ($$$
prompt),
BACKUP reports the following error messages during
verification
phase while creating the BACKUP image with the /VERIFY
qualifier.

$$$ backup/image/verify DKA0: DKB200:[000000]TEST.BCK;
1/save
%BACKUP-I-STARTVERIFY, starting verification pass at
15-SEP-2010 20:28:43.19
%BACKUP-E-POSERROR, error positioning DKB200:
[000000]TEST.BCK;1
-RMS-F-SQO, operation not sequential (SQO set)
%BACKUP-F-READERRS, excessive error rate reading
DKB200:[000000]TEST.BCK;1
-BACKUP-E-HDRCRC, software header CRC error

If you try to restore, list, compare or verify the
saveset,
BACKUP command might fail with the following error
messages:

$ backup/image DKB200:[000000]TEST.BCK;1/save DKA100:
%BACKUP-E-POSERROR, error positioning DKB200:
[000000]TEST.BCK;1
-RMS-F-IOP, operation invalid for file organization or
device
%BACKUP-E-INVSTRUCT, invalid structure level in save
set
%BACKUP-E-POSERROR, error positioning DKB200:
[000000]TEST.BCK;1
-RMS-F-IOP, operation invalid for file organization or
device
%BACKUP-E-BLOCKLOST, block of DKB200:[000000]TEST.BCK;
1 lost
due to unrecoverable error
-BACKUP-E-HDRCRC, software header CRC error

This problem has been fixed.
This problem has been fixed.

To use the BACKUP images from $$$ prompt, follow these
steps:

1) Extract BACKUP.EXE, BACKUPSHR.EXE, and
BACKUP.CLD from
update 400 kit to a known disk location.

2) From the $$$ prompt, mount the disk that
contains these
images by executing the following commands:

$$$ DEFINE BACKUP <path>BACKUP.EXE
$$$ DEFINE BACKUPSHR <path>BACKUPSHR.EXE
$$$ SET COMMAND <path>BACKUP.CLD

where,
<path> - Location where BACKUP images are
extracted
from the update 400 kit.

Images Affected:

- BACKUP.EXE
- BACKUPSHR.EXE

Regards,
Ketan

[Rich Jordan]

On May 3, 1:25 am, Ketan <shrinike...@gmail.com> wrote:
> Hi,
>
> This issue has been fixed in VMS84A_UPDATE-V0400  kit. Please refer
> section “5.2.51  BACKUP/IMAGE/VERIFY fails with BACKUP-E-POSERROR”
> from the release note VMS84A_UPDATE-V0400.TXT for more details.
> The fix is also part of  VMS84I_UPDATE-V0400 kit. Please refer section
> “ 5.2.57 BACKUP/IMAGE/VERIFY fails with BACKUP-E-POSERROR” from the
> release note VMS84I_UPDATE-V0400.TXT for more details.
>
> Below is the extract from the release note:
>
>         5.2.51  BACKUP/IMAGE/VERIFY fails with BACKUP-E-POSERROR
>
>                 5.2.51.1  Problem Description:

> .....
>                 - BACKUPSHR.EXE
>
> Regards,
> Ketan

Thanks for finding that; I looked briefly but just did not have time
to locate it.

[Ralf Folkerts]

Hi all,

just a short update:

I updated my AS255/233 to the latest Hobbyist 8.4 today.

It *seems* the Backup-Patches didn't make it into the Hobbyist-Version
yet. Update went fine but when I tried to backup a Disk I got the same
errors I used to get from stand-alone-Backup using the 8.4 CD (I
connected the Disk from another VMS (8.3) System externally to the AS
and used the normally booted 8.4-System to backup/verify that disk to
Tape).

I "emphasized" "seems" as I only skimmed the Release Notes. Will read
them closely now and might try an Update again. Will post the Status...

Cheers,
_ralf_

[Jan-Erik Soderholm]

Ralf Folkerts wrote 2013-05-04 20:42:
> Hi all,
>
> just a short update:
>
> I updated my AS255/233 to the latest Hobbyist 8.4 today.
>

Including the supplied UPDATE kit ?
Without that you will probably get the same problem.

Jan-Erik.

[Stephen Hoffman]

On 2013-05-04 18:42:38 +0000, Ralf Folkerts said:

> I updated my AS255/233 to the latest Hobbyist 8.4 today.
>
> It *seems* the Backup-Patches didn't make it into the Hobbyist-Version
> yet. Update went fine but when I tried to backup a Disk I got the same
> errors I used to get from stand-alone-Backup using the 8.4 CD (I
> connected the Disk from another VMS (8.3) System externally to the AS
> and used the normally booted 8.4-System to backup/verify that disk to
> Tape).

Does PRODUCT SHOW PRODUCT VMS /FULL show the patch is installed?

[Ralf Folkerts]

Hi Stephen,

thanks for that hint! I first was under the impression that all fixes
were already applied to the Hobybist Image. Then, when Jan-Erik asked if
I installed the Update I checked again, didn't find anything. By
"product show product" didn't show any installed updates. Thats when I
recognized the hard way that there actually is a Patch-Kit on the
Hoyybist-FTP-Site. Just applied that. Will try "backup" again, after
going through the Release Notes of the Update Kit and the 8.4 Post-
Installation Checklist...

Thanks,
cheers,
_ralf_

[Ralf Folkerts]

Jan-Erik Soderholm wrote:

> Ralf Folkerts wrote 2013-05-04 20:42:
>> Hi all,
>>
>> just a short update:
>>
>> I updated my AS255/233 to the latest Hobbyist 8.4 today.
>>
>
> Including the supplied UPDATE kit ?
> Without that you will probably get the same problem.
>

Hi Jan-Erik,

thanks for pointing me to the Update! I already checked the Installation
Guide again, and also searched on the CD, with no success. Then checked
the Download-Site and found a "openvms_alpha_8_4_Update500.zip" there.

I just installed that. Will have to read the Update Kit Release Notes
and check the Post-Installtion-Checklist and will then try backup,
again!

Thanks!
Cheers,
_ralf_

[Jan-Erik Soderholm]

Ralf Folkerts wrote 2013-05-05 12:53:
> Jan-Erik Soderholm wrote:
>
>> Ralf Folkerts wrote 2013-05-04 20:42:
>>> Hi all,
>>>
>>> just a short update:
>>>
>>> I updated my AS255/233 to the latest Hobbyist 8.4 today.
>>>
>>
>> Including the supplied UPDATE kit ?
>> Without that you will probably get the same problem.
>>
>
> Hi Jan-Erik,
>
> thanks for pointing me to the Update! I already checked the Installation
> Guide again, and also searched on the CD, with no success. Then checked
> the Download-Site and found a "openvms_alpha_8_4_Update500.zip" there.
>

Note that the fix for the BACKUP bug was posted in the UPDATE 4
release notes. So yes, I'd expect the Update 5 to be fixed also.


Jan-Erik.

[Ralf Folkerts]

Jan-Erik Soderholm wrote:

> Ralf Folkerts wrote 2013-05-05 12:53:
>> Jan-Erik Soderholm wrote:
>>
>>> Ralf Folkerts wrote 2013-05-04 20:42:
>>>> Hi all,
>>>>
>>>> just a short update:
>>>>
>>>> I updated my AS255/233 to the latest Hobbyist 8.4 today.
>>>>
>>>
>>> Including the supplied UPDATE kit ?
>>> Without that you will probably get the same problem.
>>>
>>
>> Hi Jan-Erik,
>>
>> thanks for pointing me to the Update! I already checked the
>> Installation Guide again, and also searched on the CD, with no
>> success. Then checked the Download-Site and found a
>> "openvms_alpha_8_4_Update500.zip" there.
>>
>
> Note that the fix for the BACKUP bug was posted in the UPDATE 4
> release notes. So yes, I'd expect the Update 5 to be fixed also.
>

Hi Jan-Erik,

backup works fine, after applying the Patchset!

Cheers,
_ralf_

[Peter 'EPLAN' LANGSTOeGER]

In article <klrrtg$t0v$1...@online.de>, hel...@astro.multiCLOTHESvax.de (Phillip Helbig---undress to reply) writes:
>What about the downloadable hobbyist 8.4 image?

It is the same as the the original V8.4 CD

>I'm considering finally going from 7.3-2 via 8.3 (have the hobbyist CD)
>to 8.4 (with the downloadable hobbyist image). I'm still debating
>whether it is worth it because of the restricted patch access.

After almost 3 years still debating?
Think again. V8.3 has got the last UPDATE ECO for the next 12 months.
And V8.3 ECOs are now (for some years) restricted either!
V8.4 has 16 DCL parameters, 6 VOLSHAD members, and a lot more...

>What about the 8.4 image and current update patch via the hobbyist
>programme; are they safe enough? There were apparently some serious
>problems with 8.4.

Don't use a vanilla V8.3 system either. That's what ECOs are for.
And I never had any of the reported V8.4 problems so far (obviously
fixed by an ECO before I got bitten)...

My vote for "upgrade" (just like the last 3 years ;-)

--
Peter "EPLAN" LANGST�GER
Network and OpenVMS system specialist
E-mail Pe...@LANGSTOeGER.at
A-1030 VIENNA AUSTRIA I'm not a pessimist, I'm a realist