From:	CSBVAX::CSBVAX::MRGATE::"SMTP::CRVAX.SRI.COM::RELAY-INFO-VAX" 30-MAR-1989 06:20
To:	MRGATE::"ARISIA::EVERHART"
Subj:	How to Backup To Tape through DECnet


Received: From KL.SRI.COM by CRVAX.SRI.COM with TCP; Wed, 29 MAR 89 18:02:44 PDT
Received: from ucbvax.Berkeley.EDU by KL.SRI.COM with TCP; Wed, 29 Mar 89 18:04:00 PST
Received: by ucbvax.Berkeley.EDU (5.61/1.36)
	id AA16232; Wed, 29 Mar 89 17:32:27 -0800
Received: from USENET by ucbvax.Berkeley.EDU with netnews
	for info-vax@kl.sri.com (info-vax@kl.sri.com)
	(contact usenet@ucbvax.Berkeley.EDU if you have questions)
Date: 29 Mar 89 22:38:00 GMT
From: ecsvax!uncw!session@mcnc.org  (Zack Sessions)
Organization: Univ NC at Wilmington, CS & Math Dept.
Subject: How to Backup To Tape through DECnet
Message-Id: <314@uncw.UUCP>
Sender: info-vax-request@kl.sri.com
To: info-vax@kl.sri.com

I have had several requests for this procedure, so I decided to
simply post it here instead of tryuing to mail it back to all
of the requestors. I decided not to include our site specific
code, but to reproduce the article from which I gleaned the code.
It was printed in the DECUS VAX Sigs newsletter, The Pageswapper,
date unknown.

--------------------------beginning of text------------------------------
"How to Backup to Magtape over DECnet"

Allen Reuter
Mallinckrodt Institute of Radiology
510 South Kingshighway Boulevard
St. Louis, MO 63110

In our shop we have 2 VAXs and 3 uVAX IIs but only one has a tape drive.
Out 11/730 (SARA) is of the R80/RL02 variety. It would take a lot of RL02s
to back up the R80 and even more if you plan to keep it 2 cycles. At the
Spring 84 DECUS I talked to a man, who works for Evans & Sutherland, and
found some interesting things you can over DECnet at the DCL level. DEC
does not support running backup with output to a tape drive on another
node but at a DECnet sessions we were told you are allowed to write to a 
mailbox! The problem with Backup is it wants to write variable length 
records. When access the tape over DECnet you need to write fixed length 
records to tape. This problem can be cured by using the utility CONVERT, 
with FDL files describing the input and output. On our 730 we have the 
following file which backs up the R80 to 2 tapes.

BckUpDQA0.com

$ !backup dqa0 to lucy::mta0:
$ ON ERROR THEN GOTO ERROR_EXIT
$ ON CONTROL_Y THE GOTO ERROR_EXIT
$ OPEN/WRITE RMT LUCY::"0=NETDCL2"        ! 1) LOGIN VIA PROXY
$ TYPE SYS$INPUT                          ! 2)

 Please mount tape DQA01 on lucy::mta0:

$ INQUIRE YN "Press return when ready to continue"
$ ! verify mount and init
$ WRITE RMT "Moun MTA0 DQA01"             ! 3) mount the tape
$ READ RMT s                              ! to make sure its the
$ WRITE RMT "Dism/nounlo MTA0"            ! right one
$ READ RMT s
$ WRITE RMT "Init MTA0 DQA01"             ! and initialize it.
$ READ RMT s
$ TYPE SYS$INPUT                          ! 4)

 Please mount tape DQA00 on Lucy::MTA0:

$ INQUIRE yn "Press return when ready to continue"
$ ! verify mount and init tape 0
$ WRITE RMT "Moun/assist MTA0 DQA00"
$ READ RMT s
$ WRITE RMT "Dism/nounlo MTA0"
$ READ RMT s
$ WRITE RMT "Init MTA0 DQA00"
$ READ RMT s
$ CLOSE RMT                               ! 5)
$                                         ! 6) do the backup
$ BACKUP/IMAGE DQA0:/IGNORE=INTERLOCK -
LUCY::"0=DQA0"/SAVE/BLOCK=4096
$ EXIT
$ERROR_EXIT:
$ CLOSE RMT
$ EXIT


The above command file does the following:

1. Starts process on the other node to process dcl commands via 
proxyu access. For more info on proxy see commented out help in 
sys$help:uafhelp.hlb.

2. Tell the operator to mount the 1st tape to be zeroed.

3. Tell the tape node to mount the tape to verify it's the right
one. Dismount and initialize it. The '$ READ RMT s' commands are
used to keep things syncronized otherwise the 730 writes the 
commands faster than the 750 processes them and the messages on
the console get out of sync with reality.

4. Mount and initialize the other tape.

5. End the network dcl process with the correct tape on the drive.

6. Backup through CONVERT to tape.

If our operator is on his toes, the backup tapes 1 hour over Ethernet to a 
75 ips Kennedy 9100. In addition I set large scratch files to nobackup with 
the set file command, such as PAGEFILE.SYS and SWAPFILE.SYS to reduce the 
time the backup takes.

The NETDCL2 file which process the command from BCKUPDQA0 is as follows:

$ ! process dcl commands over th4e network and reply with status
$ ! to start this try OPEN /WRITE RMT node::"0=NETDCL"
$ SET VERIF
$ OPEN RMT SYS$NET:/READ/WRITE
$NXT_LINE:                 ON ERROR THEN CONTINUE
$                          READ RMT LINE/END=EXIT
$                          SET VERIF
$ 'LINE
$                          SET NOVERIF
$                          S = $STATUS
$                          WRITE RMT S
$                          GOTO NXT_LINE
$EXIT:                     EXIT


The DQA0 command file which mounts the tape and invokes CONVERT is as
follows:

$ ! network tape drive
$ SET VERIF                          !  for debugging
$ SET PROC/PRIV=VOLPRO               ! the account needs volpro
$                                    ! or setprv
$ ALLO MTA0
$ MOUNT MTA0 DQA00/BLOC=4096         ! at 8192 we get overruns
$ CONVERT SYS$NET:/FDL=NETIN MTA0:SARADQA0.DAT/FDL=MTA0OUT
$ DISM MTA0
$ DEALLO MTA0
$ EXIT


The DQA0.com file does have porential problems. The 1st problem being some 
one could allocate the taope drive between initializing and the backup 
starting. Secondly if the tape node systen is slow, you may get a LINKEXIT 
error, which can be caused byu the incoming and outgoing timers being set 
too low (Use NCP SH EXEC CHAR to check.) Other restriction include no 
generalized method to support different tapoe labels, so for now we just 
keep different COM files. I suppose one could use NETDCL2 to create some 
logical names at the group level and then generalize this command procedure 
further. Currently we only have need to backup our R80. Those of you with 
11/780s or faster machines may be ab le to block the records at 8192, on our 
machines thigs would just seem to hang when either node got real busy. With 
the block size aset to 4096 we have not had any problems. In addition an 
account was created to do the backups with its BYTLM set to  20480, this 
lets DECnet work more efficiently. With SYSGEN we adjusted the number of 
free LRPs, before the backup starts, up to about 12 on the receiving node.

The NETIN fdl file for CONVERT's input from SYS$NET: is as follows:

SYSTEM
 SOURCE                 VAX/VMS

FILE
 ORGANIZATION           sequential

RECORD
 CARRIAGE_CONTROL       none
 FORMAT                 variable
 SIZE                   4096


And the MTA0OUT fdl file for CONVERT to write to tape is

SYSTEM
 SOURCE                 VAX/VMS

FILE
 ORGANIZATION           sequential

RECORD
 CARRIAGE_CONTROL       none
 FORMAT                 fixed
 SIZE                   4096


This has been working quite well for over a year in our shop. One of the 
nice features is, that convert automatically asks for the next tape. Our 
operator uses the following command after mounting the next tape:

$ REPLY/TO=<the request number> "DQA01"


where DQA01 is the label to be put on the second tape.

This backup tape, and the initial VMS distribution media along with a backup 
of SYS$SYSDEVICE:[SYS0...] to RL02s, to speed up the upgrade from V3.0 to 
V3.6 works. I have not been able to restore the disk from the tape, back 
across the network. I have managed to borrow a tape drive from another 
system and restore the whole disk without any problems. I went through the 
following steps to restore the system.

1) Load and install the system from the distribution media.

2) Then using our weekly backup of [sys0...] I brought the system V3.0 to 
V3.6 with:

          $ BACKUP DQA1:SYSTUFF.BCK/SAVE DQA0:[*...]/NEW_VER/OWNER=ORIG

3) reboot

4) purge out the old system directory stuff:

          $ PURGE DQA0:[*...]

5) restore the network backup

          $ BACKUP MTA0:DQA0BCK.DAT/SAVE DQA0:[*...]/OWNER=ORIG


Ignore the error message about the system files that already exits or use 
the /SELECT with whatever directories you want to put in first.
---------------------------end of text-------------------------------------


One more note from me (Zack), this is an old procedure but it still works 
just fine. If you have any problems implementing this procedure feel free to 
send me mail. Note that the process of initializing the tapes each time
is crucial and cannot be skipped!

Zack Sessions

