Dante_A_Nicolello@cup.portal.com (05/02/90)
I am having two problems with an Archive 60 meg Fastape.
My setup:
25mhz 80386 w/cache
isc/386/ix 2.02
Adaptec SCSI adapter w/ scsi HD
Problem one:
Tape does not stream. It runs for about 3 seconds, stops.
Then the HD reads more data, then the tapes rewinds a little and
goes another 3 seconds and this repeats. This makes backing up take
a long time. I have tried both tar and cpio. I noticed that if I
make the buffer size in cpio 51200, it seems to write more data at
a time. The question is, can it read from the disk and write to
the tape concurrently? Or is this just wishfull thinking.
By the way, I have an Irwin 20 meg tape for dos that will read from
the disk and write to the tape concurrently. The tape streams all the
way through.
Problem two:
When the tape reaches the end of the cartridge, not the end of the
current track, unix produces a "write() error" instead of prompting
me to switch tapes.
I asked Archive tech support about this, but they weren't
too famillar with unix and couldn't help me. Interactive tech support
just told me to adjust the buffer size. If you know anything about
this, let me know what to do. Thanks
-------------------------------
dante_a_nicolello@cup.portal.com ____
\ //
\//jhl@frith.uucp (John Lawitzke) (05/02/90)
From article <29490@cup.portal.com>, by Dante_A_Nicolello@cup.portal.com: > Problem two: > When the tape reaches the end of the cartridge, not the end of the > current track, unix produces a "write() error" instead of prompting > me to switch tapes. tar and cpio have no idea how long or how dense your tape is. They assume you will not attempt to write more to tape than it can hold. If you use the backup program you can specifiy density and length so the program knows when it needs to prompt for a new tape. One solution is find the source to pdtar and hack it to prompt for a new tape at the necessary point. -- j |%|John Lawitzke, Dale Computer Corp., R&D |%|UUCP: uunet!frith!dale1!jhl Work |%| uunet!frith!ipecac!jhl Home Inquiring minds just wondering. |%|Internet: jhl@frith.egr.msu.edu
gerry@zds-ux.UUCP (Gerry Gleason) (05/03/90)
In article <29490@cup.portal.com> Dante_A_Nicolello@cup.portal.com writes: >I am having two problems with an Archive 60 meg Fastape. > Tape does not stream. It runs for about 3 seconds, stops. >Then the HD reads more data, then the tapes rewinds a little and >goes another 3 seconds and this repeats. This makes backing up take >a long time. I have tried both tar and cpio. I noticed that if I >make the buffer size in cpio 51200, it seems to write more data at >a time. The question is, can it read from the disk and write to >the tape concurrently? Or is this just wishfull thinking. >By the way, I have an Irwin 20 meg tape for dos that will read from >the disk and write to the tape concurrently. The tape streams all the >way through. I'm not even a little surprized. It is very difficult to get most tapes to stream, and I'd bet the only reason your Irwin does is that it is slow. It is possible with a good SCSI driver that has a good amount of kernel buffering for the tape (>100k), or some kind of support for asyncronous I/O in the driver. With kernel buffering normal archiving programs like cpio and tar are workable for single volume backups, otherwise you will need something that know about the hooks in your driver. Gerry Gleason
rsj@wa4mei.UUCP (Randy Jarrett WA4MEI) (05/03/90)
Dante_A_Nicolello@cup.portal.com writes: >I am having two problems with an Archive 60 meg Fastape. >My setup: > 25mhz 80386 w/cache > isc/386/ix 2.02 > Adaptec SCSI adapter w/ scsi HD >Problem one: > Tape does not stream. It runs for about 3 seconds, stops. >Then the HD reads more data, then the tapes rewinds a little and >goes another 3 seconds and this repeats. This makes backing up take >a long time. I have tried both tar and cpio. I noticed that if I >make the buffer size in cpio 51200, it seems to write more data at >a time. The question is, can it read from the disk and write to >the tape concurrently? Or is this just wishfull thinking. >By the way, I have an Irwin 20 meg tape for dos that will read from >the disk and write to the tape concurrently. The tape streams all the >way through. >Problem two: > When the tape reaches the end of the cartridge, not the end of the >current track, unix produces a "write() error" instead of prompting >me to switch tapes. >I asked Archive tech support about this, but they weren't >too famillar with unix and couldn't help me. Interactive tech support >just told me to adjust the buffer size. If you know anything about >this, let me know what to do. Thanks What you really need is a program called afio. This is a cpio replacement that allows you to setup multiple buffers and will also fork off a child task to do the writing to disk. With the proper selection of size and number of buffers my tape system (Archive 60) doesn't stop except to change direction. If you have problems finding afio let me know and I will ship a copy to you. -- Randy Jarrett WA4MEI UUCP ...!gatech!wa4mei!rsj | US SNAIL: P.O. Box 941217 PHONE +1 404 493 9017 | Atlanta, GA 30341-0217
pnessutt@dmshq.mn.org (Bob Monio) (05/03/90)
In article <1990May2.113532.26951@msuinfo.cl.msu.edu> jhl@frith.uucp (John Lawitzke) writes: >From article <29490@cup.portal.com>, by Dante_A_Nicolello@cup.portal.com: >> Problem two: >> When the tape reaches the end of the cartridge, not the end of the >> current track, unix produces a "write() error" instead of prompting >> me to switch tapes. > >tar and cpio have no idea how long or how dense your tape is. They >assume you will not attempt to write more to tape than it can hold. If >you use the backup program you can specifiy density and length so the >program knows when it needs to prompt for a new tape. Some vendors have modified their tar and cpio programs to support multiple volume archives. NCR has done this with their cpio implementation. But, not all vendors do this. This is unfortunate since some people don't have the luxury of large capacity tape devices. >One solution is find the source to pdtar and hack it to prompt for a new >tape at the necessary point. Or, use afio. Afio is a cpio lookalike with the capability to write tape volumes of varying sizes and blocking. We have used it extensively at different user sites that do not have backup tools with multiple-volume support. Afio was posted on comp.sources.unix a while back. I can mail the shar file to anyone that would like it. -Bob -- Robert A. Monio "I've learned all my heroes and wanted Level I Systems, Inc. the same/To try out my hand at the pnessutt@dmshq.mn.org Patriot Game..." ..amdahl!bungia!dmshq!pnessutt -- Robby Jackson, 'Patriot Games'
peter@orfeo.radig.de (Peter Radig) (05/03/90)
Dante_A_Nicolello@cup.portal.com writes: >I am having two problems with an Archive 60 meg Fastape. >My setup: > 25mhz 80386 w/cache > isc/386/ix 2.02 > Adaptec SCSI adapter w/ scsi HD >Problem one: > Tape does not stream. Use the GNU tar with a appropiate blocking factor (I use -b2000, i.e. 1 MB buffer). Peter -- Peter Radig Voice: +49 69 746972 USENET: peter@radig.de or: uunet!unido!radig!peter
turner@udecc.engr.udayton.edu (Bob Turner) (05/04/90)
In article <1990May2.113532.26951@msuinfo.cl.msu.edu> jhl@frith.uucp (John Lawitzke) writes: >From article <29490@cup.portal.com>, by Dante_A_Nicolello@cup.portal.com: >> Problem two: >> When the tape reaches the end of the cartridge, not the end of the >> current track, unix produces a "write() error" instead of prompting >> me to switch tapes. > >tar and cpio have no idea how long or how dense your tape is. They >assume you will not attempt to write more to tape than it can hold. If >you use the backup program you can specifiy density and length so the >program knows when it needs to prompt for a new tape. > >One solution is find the source to pdtar and hack it to prompt for a new >tape at the necessary point. > On a consulting job I did in March we had the same problem. Especially with cpio. We were using a 499 and a 60MB Fastape. Tar is an easy. It does not recognize the end of tape in any situation. But all is not lost. It keeps count of the number blocks written so far. And compares it the number of blocks available that was specified on the command line or in the file /etc/defaults/tar (or something like that). If you want specifics I will be happy to post. Cpio is a different beast. Cpio according to the manual :-), is supposed to detect the end of the device and prompt for a new filename. Usually you key in the tape again after you change the cartridge. Unfortunately, it actually works as you describe. The problem seems to lie within the device driver that Archive supplys. The device driver when it hits the end of the tape returns a write error #5 (or something approximating it) which is the general I/O Error rather than no more space on device (Error number 27). So that cpio knows to prompt. The unfortunate part is that the backup script also uses cpio. Realize that there is obvoiusly no problems unless you need to span a tape. If you need more help, mail me a message. Bob -- ==================================================================== Bob Turner Network Manager, School of Engineering 513-229-3171 turner@udecc.engr.udayton.edu Univ. of Dayton, Engineering Computing Center-KL211, Dayton OH 45469
bjstaff@zds-ux.UUCP (Brad Staff) (05/04/90)
In article <7804@dmshq.mn.org>, pnessutt@dmshq.mn.org (Bob Monio) writes: [ Some stuff deleted ] > Some vendors have modified their tar and cpio programs to support > multiple volume archives. NCR has done this with their cpio > implementation. But, not all vendors do this. This is unfortunate > since some people don't have the luxury of large capacity tape > devices. [ Some more stuff deleted ] Interactive has done this with 386/ix. Here is what I get when I run the following command: (Note that I am using the raw, not the block, floppy device.) $ find . -print | sort | cpio -ovB > /dev/rdsk/f0q15dt Reached end of medium on output. If you want to go on, type device/file name when ready. All that is needed is to swap floppies and type '/dev/rdsk/f0q15dt' again. The cpio that comes on the AT&T System V/386 Release 3.2 tape looks for ENOSPC or ENXIO coming back in errno after read() and write() calls. If it sees those values it assumes it has reached the end of that piece of media and asks for a new one. If your cpio doesn't do this, complain to your vendor. Of course, your floppy and/or tape drivers have to be well behaved as well if this is going to work. If they aren't well behaved, complain to your vendor. I hardly ever use tar, so I can't offer any suggestions there. -- Brad Staff | Zenith Data Systems | "A government that can forbid certain 616-982-5791 | psychoactive drugs can mandate others." bjstaff@zds-ux.zds.com | - Russell Turpin
pim@cti-software.nl (Pim Zandbergen) (05/04/90)
bjstaff@zds-ux.UUCP (Brad Staff) writes: >$ find . -print | sort | cpio -ovB > /dev/rdsk/f0q15dt >Reached end of medium on output. >If you want to go on, type device/file name when ready. Instead, use: $ find . -print | sort | cpio -ovBO /dev/rdsk/f0q15dt ^ This will make cpio know the device name, so you won't have to type "/dev/rdsk/f0q15dt" for every floppy change. -- Pim Zandbergen domain : pim@cti-software.nl CTI Software BV uucp : uunet!mcsun!hp4nl!ctisbv!pim Laan Copes van Cattenburch 70 phone : +31 70 3542302 2585 GD The Hague, The Netherlands fax : +31 70 3512837
bill@ssbn.WLK.COM (Bill Kennedy) (05/04/90)
In article <299@zds-ux.UUCP>, bjstaff@zds-ux.UUCP (Brad Staff) writes: > In article <7804@dmshq.mn.org>, pnessutt@dmshq.mn.org (Bob Monio) writes: > [ Some stuff deleted ] [ more stuff deleted ... ] > > Interactive has done this with 386/ix. Here is what I get when I run the > following command: (Note that I am using the raw, not the block, floppy > device.) > > $ find . -print | sort | cpio -ovB > /dev/rdsk/f0q15dt > Reached end of medium on output. > If you want to go on, type device/file name when ready. You can avoid having to retype the device name if you use the -O option, $find . -print | sort | cpio -ovB -O /dev/rdsk/f0q15dt And when it's time to change diskettes all you have to do is press return. I've not tried it, but I suspect you could specify a full cylinder for the blocking factor with the -C argument and maybe have fewer physical I/O events. [ ... ] > new one. If your cpio doesn't do this, complain to your vendor. Of course, > your floppy and/or tape drivers have to be well behaved as well if this is > going to work. If they aren't well behaved, complain to your vendor. If you're going to tape I highly recommend the -C argument. It lets you specify the physical block size. The ISC cpio inadvertantly adds a zero for you (I say -C512000 he uses -C5120000) so watch out that you don't require more buffer than you have memory. If you do that it will go to swap space and you lose a lot of time splashing back and forth. On ssbn (10Mb) I use -C 512000 -O /dev/tape and on inebriae (4Mb) I use -C 51200 -O /dev/tape. When it's time to put in the next volume I just wait for the tape to rewind, stick in the next cartridge and press return. > I hardly ever use tar, so I can't offer any suggestions there. Me neither, but I have a neighbor who does and he gets his tape to stay streaming. Even at -C 512000(0) I get six or so physical records (tape stops, writes record mark and gap and proceeds) per I/O event. GNU tar seems to pour it out all at once and he gets one tape record per I/O event. > -- > Brad Staff | > Zenith Data Systems | "A government that can forbid certain > 616-982-5791 | psychoactive drugs can mandate others." > bjstaff@zds-ux.zds.com | - Russell Turpin -- Bill Kennedy usenet {texbell,att,cs.utexas.edu,sun!daver}!ssbn!bill internet bill@ssbn.WLK.COM or attmail!ssbn!bill
clewis@eci386.uucp (Chris Lewis) (05/05/90)
In article <299@zds-ux.UUCP> bjstaff@zds-ux.UUCP (Brad Staff) writes: | In article <7804@dmshq.mn.org>, pnessutt@dmshq.mn.org (Bob Monio) writes: | [ Some stuff deleted ] | > Some vendors have modified their tar and cpio programs to support | > multiple volume archives. NCR has done this with their cpio | > implementation. But, not all vendors do this. This is unfortunate | > since some people don't have the luxury of large capacity tape | > devices. | Interactive has done this with 386/ix. Here is what I get when I run the | following command: (Note that I am using the raw, not the block, floppy | device.) I've yet to see a version of cpio that doesn't "handle" end of media... (Eg: System III source tapes...). And have seen few versions of tar that *do*. The problem is that cpio considers *any* read or write error to be end of tape and prompts for the next tape. Which, if the tape is partially defective, is definately wrong. I suspect that some of the other tape archivers do the same - I distinctly remember pax once continually reprompting me because I had write protect on the tape. Bit confusing to say the least. I wish that there was an end of media errno. (Though some tape drivers apparently do something slightly different on EOM versus true errors) -- Chris Lewis, Elegant Communications Inc, {uunet!attcan,utzoo}!lsuc!eci386!clewis Ferret mailing list: eci386!ferret-list, psroff mailing list: eci386!psroff-list
brad@bradf.UUCP (Bradley W. Fisher) (05/05/90)
In article <29490@cup.portal.com>, Dante_A_Nicolello@cup.portal.com writes: > I am having two problems with an Archive 60 meg Fastape. > My setup: > 25mhz 80386 w/cache > isc/386/ix 2.02 > Adaptec SCSI adapter w/ scsi HD > > Problem one: > Tape does not stream. It runs for about 3 seconds, stops. > Then the HD reads more data, then the tapes rewinds a little and > goes another 3 seconds and this repeats. This makes backing up take > a long time. I have tried both tar and cpio. I noticed that if I > make the buffer size in cpio 51200, it seems to write more data at > a time. After playing around with some commercial backup packages lately, I have noticed and tried to solve this same puzzle myself. In fact I had made a post to the net about a month ago asking why it was that SCO XENIX tape drivers were able to backup to tape so much faster than 386ix,Altos, NCR, etc. Unfortunately, no one responded. My own conclusions are basically what you were told ... > Interactive tech support just told me to adjust the buffer size. ... things do revolve around the buffer size. As I understand it, this is the amount of data transferred from origin to ram before it is transferred to the final destination. Also, as I understand it, this has been declared by AT&T source license code to be 10k (or 20 - 512 byte blocks,hence the usual blocking factor of 20) for tar. This was probably quite adequate for older start/stop reel and cartridge systems. Various companies that have licensed the source to *NIX either have or have not addressed this problem, and hacked the source for tar to increase the buffer size. It seems Interactive falls into the latter category. However, SCO falls into the former ... their "blocking factor" of 20 *I beleive* is really a multiple of ten ... and about 100k is being tranferred at a time. With less stops for transfer of data this results in an overall rate increase. > The question is, can it read from the disk and write to > the tape concurrently? Now for the clincher ... how do you keep it streaming? Well, going out to tape(the slowest device in the picture) you would ideally fill one ram buffer area with data from the disk and feed it to another ram buffer area (are we talking pipes here?) that is in control of feeding the tape drive. I think from what I've read, that to be able to do this involves the use of "shared memory", and in brief I've also been told "you can't do that with the Intel achitecure". But I'm rapidly stepping out of bounds on my knowledge of how all this works ... perhaps a someone with a greater understanding of the "internals" could step in now and give us all a clearer picture. > Problem two: > When the tape reaches the end of the cartridge, not the end of the > current track, unix produces a "write() error" instead of prompting > me to switch tapes. In tar you'll need to use the "k" option to tell it the size of the media you're using ... eg. tar cvbfk 20 /dev/rct0 60000 for a 60 mb tape under SCO XENIX. I'm just a wanna be UNIX guru (IJWBUG) | Micro Maintenance, Inc. | 2465 W. 12th St. #6 -== Brad Fisher ==- | Tempe, Arizona 85281 ...!asuvax!mcdphx!hrc!microm!bradf!brad | 602/894-5526
dougp@ico.isc.com (Doug Pintar) (05/08/90)
In article <261@bradf.UUCP> brad@bradf.UUCP (Bradley W. Fisher) writes: >... things do revolve around the buffer size. As I understand it, this is >the amount of data transferred from origin to ram before it is transferred >to the final destination. Also, as I understand it, this has been declared >by AT&T source license code to be 10k (or 20 - 512 byte blocks,hence the >usual blocking factor of 20) for tar. This was probably quite adequate for >older start/stop reel and cartridge systems. I think you're confusing application code and kernel code here. If you use the '-B' option on cpio, it gives you 5120 bytes, 10 Unix-standard blocks. The '-C' option will let you use a bigger block size, or you can run through 'dd' to do the buffering. I've never used the SCO system, so I may be incorrect in the following conjecture; take it with however much salt you wish... I suspect that the difference in performance you are seeing between (fundamentally) unblocked cpio/tar transfers on SCO and the other systems is that the SCO tape driver is probably buying a large buffer and hiding the buffering operation from the application program. We (Interactive) rejected this approach for two reasons: 1) For dumb (single address, single count) DMA tape controllers, you need to have PHYSICALLY-CONTIGUOUS memory for your buffer. Large chunks of this become difficult to find after the system has been running for any length of time, so you are usually forced to buy the pages at INIT time. This removes that memory from user programs WHETHER OR NOT THE TAPE IS BEING USED! 2) the original philosophy for Unix was (and still should be, IMHO) that things that can be done in user code SHOULD be done in user code, not in the kernel. Since 'dd' existed for buffering (although it tends to hide end-of-tape detection even more, sigh) and the latest cpio supports the -C option, there is no real win to attaching a comparatively expensive resource (memory) to an I/O device just so that programs not using large buffers run fast. >Various companies that have licensed the source to *NIX either have or have >not addressed this problem, and hacked the source for tar to increase the >buffer size. It seems Interactive falls into the latter category. However, >SCO falls into the former ... their "blocking factor" of 20 *I beleive* is >really a multiple of ten ... and about 100k is being tranferred at a time. >With less stops for transfer of data this results in an overall rate increase. > See above comment... >Now for the clincher ... how do you keep it streaming? Well, going out to >tape(the slowest device in the picture) you would ideally fill one ram buffer >area with data from the disk and feed it to another ram buffer area (are we >talking pipes here?) that is in control of feeding the tape drive. I think >from what I've read, that to be able to do this involves the use of "shared >memory", and in brief I've also been told "you can't do that with the Intel >achitecure". There is nothing in the Intel architecture that prevents having shared memory between two processes; if there were, 386-based Unix systems would never pass the System V Verification (Validation?) Suite (SVVS, required if you're going to call something Unix). You could indeed write 2 cooperating processes, one of which fills memory from disk while the other writes it to tape. This is known as double-buffering, and is a pain to do under Unix (as it requires two processes and shared memory instead of asynchronous I/O as God intended). I guess most systems writers never considered it a big enough problem to bother re-writing the back-up programs. Using large buffers will cause the tape to stream for quite a time, stop a little, and then stream again, so it saves BUNCHES of time over writing little teensy records. Just as a BTW, AIX/PS-2 (at least version 1.2) DOES have a 2-task cpio. Besides, if backups didn't take forever, where would all the grave-shift operations people find work? :-) DLP
tyager@maxx.UUCP (Tom Yager) (05/08/90)
In article <1990May3.133709.386@orfeo.radig.de>, peter@orfeo.radig.de (Peter Radig) writes: > Dante_A_Nicolello@cup.portal.com writes: > >I am having two problems with an Archive 60 meg Fastape. > >Problem one: > > Tape does not stream. > > Use the GNU tar with a appropiate blocking factor (I use -b2000, i.e. > 1 MB buffer). > Peter Radig > USENET: peter@radig.de or: uunet!unido!radig!peter I've got a nearly identical configuration running here, except that I've got a 125MB Archive instead of the 60. Should be the same controller, though. I've had no trouble getting it to stream to the tape, but be aware of this: The tape NEVER streams when you do a verbose tar. Each group of lines that kicks out to the display makes the tape do a start/stop. Instead of "tar cvf /dev/rct0 /foo", try "tar cf /dev/rct0 /foo", or redirect the output to a file ("tar cvf /dev/rct0 /foo >/tmp/filelist") if you want tar to move faster. If that doesn't work, you can up the blocking factor of tar by piping it through dd, to wit: "tar cf - /foo | dd of=/dev/rct0 obs=262144". I've seen some drives that take mysterious write errors on some block sizes, so this may take some experimentation. Good luck! (ty) -- +--Tom Yager, Technical Editor, BYTE----Reviewer, UNIX World---------------+ | NET: decvax!maxx!tyager -or- uunet!bytepb!maxx!tyager | | I speak only for myself "UNIX: It's not a job, | +-------------------------------------it's a Jihad!" -co-worker------------+
campbell@Thalatta.COM (Bill Campbell) (05/09/90)
In article <36@maxx.UUCP:> tyager@maxx.UUCP (Tom Yager) writes: :>In article <1990May3.133709.386@orfeo.radig.de>, peter@orfeo.radig.de (Peter Radig) writes: :>> Dante_A_Nicolello@cup.portal.com writes: :>> >I am having two problems with an Archive 60 meg Fastape. :>> >Problem one: :>> > Tape does not stream. :>> :>[deleted] :>I've got a nearly identical configuration running here, except that I've got :>a 125MB Archive instead of the 60. Should be the same controller, though. I've :>had no trouble getting it to stream to the tape, but be aware of this: The :>tape NEVER streams when you do a verbose tar. Each group of lines that kicks :>out to the display makes the tape do a start/stop. :> I have an Archive FastTape 150 running on SCO Xenix 2.3.2GT and it streams just fine even with verbose tar! This is with a 33Mhz 386 and 32K cache. -- ....microsoft--\ Bill Campbell; Celestial Software ...uw-entropy----!thebes!camco!bill 6641 East Mercer Way ....fluke------/ Mercer Island, Wa 98040 ....hplsla----/ (206) 232-4164
seckin@sumac.hf.intel.com.ogi.edu (05/26/90)
In article <1990May4.224058.4271@eci386.uucp> clewis@eci386.UUCP (Chris Lewis) writes: >I've yet to see a version of cpio that doesn't "handle" end of media... Same here. I routinely do multi-volume tape backups on my system, an Intel 386 AT running UNIX V/386 Release 3.2 Version 2.1. >The problem is that cpio considers *any* read or write error to >be end of tape and prompts for the next tape. ... cpio handles ENOSPC, "end of media" for tapes. The tape driver has to handle "end of media" correctly, that is it should stop writing data, write a file mark, and return the correct residual count and the correct error number (ENOSPC). For i/o errors the driver should report EIO, etc. >I wish that there was an end of media errno. (Though some tape drivers >apparently do something slightly different on EOM versus true errors) There is, ENOSPC. Standard System V/386 tape drivers handle end-of-tape properly, so multi-volume archives are good. Just use cpio! Also, note that cpio tries to allocate 10 buffers of specified size. For example "cpio -oB .." tries to allocate 10*5K, will issue 50K i/o requests with a n*5K final write. Using "cpio -oC 1024000 .." the cpio will try to allocate 10MB of memory, and it will succeed grabbing that much virtual memory, but you might end up paging/swapping a lot. Also again, the cpio buffer is contiguous in virtual memory, but the tape controller deals with real addresses, so the VM/driver usually end up issuing the i/o requests in chunks of 4K (pagesize). If the hardware/software is fast enough, and the tape controller/drive can handle a little delay, the tape streams. >Chris Lewis, Elegant Communications Inc, {uunet!attcan,utzoo}!lsuc!eci386!clewis >Ferret mailing list: eci386!ferret-list, psroff mailing list: eci386!psroff-list Seckin Unlu seckin@littlei.intel.com Software Engineer uunet!littlei!seckin Intel Corporation [Only my personal opinions]