How about the tape drive ?

[lunew]

Alpha ES40,Tape drive ,OpenVMS7.1-2.
I run the mon.com to backup my files as following:
ljj> @mon
%MOUNT-I-MOUNTED, MON mounted on _ALPHA$MKB600:
Listing of save set(s)

%SYSTEM-F-ACCVIO, access violation, reason mask=00, virtual address=000000000000
0000, PC=0000000000000000, PS=00000000

The bakup procedure stopped. why ?

The procedure mon.com is as following:
$ init mkB600: mon
$ mount mkb600:/ov=id
$ BACKUP/LIST/RECORD DRA0:[SEM.DATA.ZZ]*.*;* MKB600:ZZ.BAK
$ BACKUP/LIST/RECORD DKA100:[SEM.DATA.BAK.200312]*.*;* MKB600:LOG.BAK
$ BACKUP/LIST/RECORD DRA0:[SEM.DATA.CK]*.*;* MKB600:CK.BAK
$ BACKUP/LIST/RECORD DRA0:[SEM.DATA.PP]*.*;* MKB600:PP.BAK
$ BACKUP/LIST/RECORD DRA0:[SEM.DATA.DI]*.*;* MKB600:DI.BAK
$ BACKUP/LIST/RECORD DRA0:[SEM.DATA.EP]*.*;* MKB600:EP.BAK
$ BACKUP/LIST/RECORD DRA0:[SEM.DATA.KD]*.*;* MKB600:KD.BAK
$ BACKUP/LIST/RECORD DRA0:[SEM.DATA.IX]*.*;* MKB600:IX.BAK
$ BACKUP/LIST/RECORD DRA0:[SEM.DATA.MR]*.*;* MKB600:MR.BAK
$ BACKUP/LIST/RECORD DRA0:[SEM.DATA.PW]*.*;* MKB600:PW.BAK
$ BACKUP/LIST/RECORD DRA0:[SEM.DATA.PU]*.*;* MKB600:PU.BAK
$ dismount mkB600:

[Uwe Zessin]

You might check your process' quotas. In the past I have found out that inappropriate settings can result in process crashes, process hangs or even corrupted save sets(!).

I have just thrown some keywords into google and came up with this link (see 10.7, Setting Process Quotas for Efficient Backups):
http://h71000.www7.hp.com/doc/72final/6017/6017pro_044.html

Although this documentation is for V7.2 I don't recall that the rules have changed over the years. (Anybody else: have they?)

[Antoniov.]

Hello,
you mou tape device as structured device (MOUNT /OV=ID); this required tape working not in it optimal way and then may be require more quota you have avaiable (as posted by Uwe).
You could make as follow:
$ INIT MKB600: MON
$ MOUNT MKB600 /FORE
$ BACKUP/LIST/RECORD DRA0:[SEM.DATA.ZZ]*.*;* MKB600:ZZ.BAK/SAVE
$ ....
$ DISM MKB600:
You can investigate usinf ACCOUNT to view some process quota.
Also you could check software version: may be tape driver in V7.1-2 has som bug corrected by next version.

@Antoniov

[labadie_1]

having correct quotas can avoid such accvio, and for better performance, you should add a qualifier
/block=16384
or
/block=65535
as, unfortunately, the default (of 8192) gives very bad performance.

Regards

Gerard

[Uwe Zessin]

Good point, Gerard.
I just want to remind that in the past people did $COPY the backup savesets from tape to disk and processed from there. This doesn't work when the block size is bigger that 32256.

[Mohamed K Ahmed]

backup/list command only works if the device is mounted / for

Mohamed

[Jan van den Ende]

Lunev,

if your problem IS related to process quota (which sound rather probable to me), then be warned in advanced: going from VMS 7.1(-x) to 7.2(some) might want some more, but going to 7.3(some) requires about DOUBLE the BYTLM & PGFLQ. Also JTQUO is used a bit more. (Of course, if they are now already overdimensioned you will not notice, but I don't think that applies ;-) )

Jan