From: SMTP%"RELAY-INFO-VAX@CRVAX.SRI.COM" 13-AUG-1993 13:53:55.85 To: EVERHART CC: Subj: Re: Zombie on TA79 From: harvey@indyvax.iupui.edu X-Newsgroups: comp.os.vms Subject: Re: Zombie on TA79 Message-Id: <1993Aug12.131201.1672@indyvax.iupui.edu> Date: 12 Aug 93 13:12:01 -0500 Organization: Indiana University-Purdue University at Indianapolis Lines: 34 To: Info-VAX@kl.sri.com X-Gateway-Source-Info: USENET In article <1993Aug12.043549.25243@colorado.edu>, dwing@uh01.colorado.edu (Dan Wing) writes: > In article <1993Aug11.171343.5@vortex.gici.com>, laffrey@vortex.gici.com > writes: >>In article <01H1L4QJBTCY000ZIE@UNCVX1.OIT.UNC.EDU>, Jim Murrell >> writes: >>> It seems as if I've heard the answer to this question awhile back but don't >>> remember. Is there a way to free a TA79 from a process that doesn't exist? >>> The problem happens when a process has mounted a tape and the process is >>> killed before a dismount has been issued. >> >>No. >>To help prevent this, we jacked up our CHANNELCNT param so the device >>doesn't run out of I/O channels. >>DEC has a couple of patches to correct "most" of the occurences. There >>is even a deallocation program in CSCPAT_0245 to be used "with EXTREME >>CAUTION" > > A "device" doesn't run out of channels, a process does. I may have missed > something, but I don't recall increasing CHANNELCNT as being a fix for this > problem...? The problem occurs when a process runs out of channels in the middle of a dismount operation. To avoid the problem, either raise the SYSGEN parameter CHANNELCNT or lower the maximum FILLM UAF quotas of all your accounts until CHANNELCNT - maximum FILLM >= 15. It hasn't happened here since we did this. There is a DSN article on this problem titled "Foreign Mounted Device Remains Allocated to Deleted Process." -- James Harvey IUPUI OIT Technical Support -- VMS/UNIX/Networks harvey@iupui.edu uucp:iugate!harvey bitnet:harvey@indyvax Disclaimer: These are my opinions, not those of Indiana University.