If you're running under VM, and have VMTAPE in use, and have Neale's cpint package installed and working, it seems to me you should be able to do something like
hcp sm vmtape mount <volser> 181 and have VMTAPE (with STAM if your tape drives are EMIF'ed among multiple LPARs) mount the tape, then insmod tape390 tape=181 and do something with /proc to make the 181 tape device active. At this point, you should be able to work with the tape itself using tar or mt. to release the tape, you'd have to delmod tape390 hcp detach 181. I can only see two problems with this approach: (1) I think tape390 and cpint use the same major node numbers. You might have to recompile one or the other to use a different major node number. (2) I've never been able to get cpint to properly issue a CP DETACH command that works. I may be doing something wrong. Anyone care to comment on this approach? "Great Minds discuss ideas. Average minds discuss events. Small minds discuss people." - Admiral Hyman Rickover Gordon Wolfe, Ph.D. (425)856-5940 VM Enterprise Servers, The Boeing Company > ---------- > From: Fargusson.Alan > Reply To: Linux on 390 Port > Sent: Thursday, June 12, 2003 4:57 PM > To: [EMAIL PROTECTED] > Subject: Re: Linux390 + VM + Tape 3490 > > In batch it happens at the allocate, which I think is at start of job in JES3, and > start of step in JES2. > > In TSO you do an allocate command, although I doubt many people do this. Usually > they write some JCL, and submit it. > > I think an allocate command would be the best way to do this in Linux, since it > would be about the same as TSO. I think that the mt command is not the right place > to do this though. > > -----Original Message----- > From: John Summerfield [mailto:[EMAIL PROTECTED] > Sent: Thursday, June 12, 2003 4:35 PM > To: [EMAIL PROTECTED] > Subject: Re: Linux390 + VM + Tape 3490 > > > On Thu, 12 Jun 2003, Jim Sibley wrote: > > > John, > > > > "insmod tape390 tape=xxx,xxx" - only list the tapes you want to use are > > specified. Obviously, putting them in the zipl.conf would lock them for the > > duration of the IPL - not good for shared tapes. > > Having loaded tape390 once, can you then load it again to get another > tape? > > Having the mt command handle locking/releasing looks good to me, coupled > with the driver spitting the dummy if you try to do anything to an > unreserved tape except reserve it, or detach it. > > "mt attach" sounds good to me too. On systems where attach/detach don't > apply, the operations should give no error or warning. > > I can imagine this functionality applying in other environments (such as > vmware), and it seems to me ideal for the semantics to be the same. > > > > > However you look at it, the solution requires the person using the machine > > to take overt acton to obtain the drive and it must be locked until he is > > ready to release it. And it needs to take into account the fact that other > > OS (non-linux) may also use the same drive. > > > I'm not keen on the idea of it being done at driver-load time. > > > > > In this case, I think it behooves Linux to comply with the rules already in > > place for shared tapes in an installation and follow the rules for the > > device as defined in the hardware specs. > > When does it happen in OS/390? > > > -- > > > Cheers > John. > > Join the "Linux Support by Small Businesses" list at > http://mail.computerdatasafe.com.au/mailman/listinfo/lssb > >
