Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/18/84; site ucbvax.ARPA
Path: utzoo!watmath!clyde!cbosgd!ucbvax!info-vax
From: info-vax@ucbvax.ARPA
Newsgroups: fa.info-vax
Subject: RE: Dual ported TU78s
Message-ID: <5135@ucbvax.ARPA>
Date: Thu, 28-Feb-85 14:08:38 EST
Article-I.D.: ucbvax.5135
Posted: Thu Feb 28 14:08:38 1985
Date-Received: Fri, 1-Mar-85 20:31:39 EST
Sender: daemon@ucbvax.ARPA
Organization: University of California at Berkeley
Lines: 36

From: (Stephen Tihor) <TIHOR@NYU-CMCL1.ARPA>

With a dual ported TU78 you have three useful options on the
little POST thumb wheel on the drive:

	(0)	PORT A -- the system on Port A can use the drive.  Operations
				from Port B will fail
	(1)	PORT B -- just the reverse of above
	(2)	PORT A/B -- either system can write to the drive interleaving
				I/Os on a command by command basis.  No
				problem in a VAXcluster where the system
				software arbitrates to allocation of the tape
				drive and insists that only on process tree
				can have it at a time;

				Requires some care under non-clusted VMS
				systems but at least you have to allocate
				the drive exclusively on the system to use it
				so various tricks like having the drive
				always allocated to the console (or a background
				job) until the user asks for it in uch a way
				that a human or the two owning processes get
				to arbitrate the allocation.

				Uncomunicative VMS systems or any Unix system
				without the tape allocation patchs will rely
				on user kindness.  Since users overwrite
				each others tapes NOW on our BSD 4.2 systems
				I wouldn;t hold out great hope unless these are
				basically single user 785s but ...

 \\   Stephen Tihor / CIMS / NYU / 251 Mercer Street  / New York, NY 10012  //
((  DEC Enet: RHEA::DECWRL::"""TIHOR@NYU-CMCL1.ARPA"""  NYUnet: TIHOR.CMCL1  ))
 // ARPAnet: Tihor@NYU-CMCL1   UUCPnet address: ...!ihnp4!cmcl2!cmcl1!tihor \\

-------