Enrique Arredondo <atk@sbcglobal.net> said...

> I think BackupEdge is crap with REV drives (too many bad experiences)....
> Get LoneTar instead. It's flawless with REV drives. Download a trial
> version and you'll see what I mean. Also technical support is more user
> friendly, you talk to the main programmer the first time you talk to
> someone. Don't need to escalate to the next level. Just my 2 cents.

Mr. Arredondo.

I normally ignore this kind of stuff. Responding properly requires pointing out
to a potential client that they might be wrong about something, and to talk
about someone else's product in a less-than glowing fasion. Neither are my
favorite things to do.

But now you've made this kind of comment twice in a 10 month period, and
perhaps bruised our reputation a bit with customers who don't know better, so
I feel it is necessary in this case to reply.


So lets look at your comments, statement-by-statement.

> I think BackupEdge is crap with REV drives (too many bad experiences)....

The only experience I'm aware of that you had was back in Sep '05 when you
attached the REV to a PERC 4 RAID controller and we had a problem. We
spent two weeks working to help you, even though the Dell web site
CLEARLY STATES...

"NOTE: The PERC 4/Di/Si and 4e/Di/Si RAID controllers support
hard disk drives only; they do not support CD-ROMs, tape drives,
tape libraries, or scanners."

Dell Reference:
http://support.dell.com/support/edoc...en&cs=04&s=bsd

So even though Dell says DON'T DO THIS (the REV has a CD-ROM-type BIOS)
you still thought it was a good thing to do. We tried to help.

Lone-Tar is MUCH less sophisticated in its REV error handling than BackupEDGE,
and I eventually made a decision to stop spending engineering time trying to
support a host adapter that that the manufacture says a REV should never be
plugged into.


> Get LoneTar instead. It's flawless with REV drives.

Let's examine that statement. I'll have to, in order to justify what I
said in my last paragraph, won't I?

Caveat. I really DON'T like talking about other people's products, but
sometimes manufactures are the only ones who really understand the differences
between hype and reality.

Scribbling data on a REV is quite simple. It took us about 10 minutes
from the time we saw our first REV to the time we were writing on it.

Adding the things necessary to make it it into a reliable backup device,
especially the error checking, took a lot longer. We favor not just doing the
10% of the work necessary to say we "support" something, but instead doing the
other 90% to fully integrate a new technology before we release it. we'll still
have problems, as customer environments differ, but we'll have done everything
we can to make a product reliable before shipping it.




We downloaded the Lone-Tar 4.2 that was available on their web site for demo
on 7/10/2006 and installed it along with BackupEDGE 02.01.05 build 2. The
machine is an HP ML330 G3 with 2 SCSI 73GB 10k hard drives and a SCSI REV
plugged in to the same HP OEM variant of the Adaptec 29160 that comes with
the G3. The system has OpenServer 5.0.7, a development system, and MP4.

There is also an ATAPI Sony DVD-Multi drive DRU-820A.

BackupEDGE and Lone-Tar were not modified from default, with device detection
settings unaltered.

The first thing we did was create a bunch of 1GB directories.
To do this we concatenated all the operating system files into one large
file, then split the first 1GB of this file into 8 slices. We then duplicated
these 1GB directories as many times as needed.


The first tests involved backing up 3 GB of data, using 3 directories, with
compression disabled.

-- Lone-Tar Test 1. Start Backup - no REV Media inserted.

Lone-Tar DID NOT NOTICE that I hadn't inserted any media. It merrily
proceded to do a 3GB backup at about 853 MB/min, then reported...
Status: 0 Backup was successful!!

Whoops.
Fortunately, the verify noticed that it had nothing to read, and failed.
Don't ever disable verify.


-- Lone-Tar Test 2. Start Backup - Media Inserted - Kill REV writer
lt.devcontrol after one minute.

Lone-Tar reports "NETWORK LINK just FAILED!", prompts for a new volume,
and waits. Couldn't answer "n" or anything else but "Y", so had to
core dump to escape.


-- Lone-Tar Test 3. Start Backup - Media Inserted - No test complexity

Lone-Tar did a relatively quick 3GB backup.
Speed: 17699130 Bytes/sec (1012.7 MB/min)
Elapsed: 3 minutes 2 seconds

However, after an hour, the verify wasn't complete, and the REV light was
out, so I started looking and the process was hung out. I killed it and the
log indicated that it had gotten through about 2GB of data before stopping.
So I tried to RESTORE the REV. After an hour, the light went out again and
I waited and waited. When I finally killed the process, it was obvious
that Lone-Tar FAILED TO RESTORE ANY DATA past the 2GB mark on the media.

A "lone-tar tvnf /dev/rcd1" also failed at 2GB.


When I couldn't restore more than 2GB of data from the REV, I decided
to duplicate this test on the Sony DVD-Multi using DVD-RAM. I tried
the no media test with the same results, and Lone-Tar was unable to
verify or restore more than 2GB of data from the DVD-RAM.



Now let's look at those same tests using BackupEDGE.


-- BackupEDGE Test 1. Start Backup - no REV Media inserted.

BackupEDGE failed during media prep/detection with "No Media Inserted".

-- BackupEDGE Test 2. Start Backup - Media Inserted - Kill REV writer
edge.tape after one minute.

BackupEDGE fails immediately. The error message is a little cryptic
but it knows what to do.

-- BackupEDGE Test 3. Start Backup - Media Inserted - No test complexity

BackupEDGE had a backup speed approximately 29% faster than Lone-Tar.
Elapsed Time = 00:02:21
Data Transfer Speed = 76.568 GB/hr
= 1306.786 MB/min

BackupEDGE verified the 3GB properly.
Elapsed Time = 00:02:15
Data Transfer Speed = 80.000 GB/hr
= 1365.354 MB/min

BackupEDGE restored the 3GB properly.
Elapsed Time = 00:05:34
Data Transfer Speed = 32.335 GB/hr
= 551.864 MB/min

Restore, of course relates more to the hard drive / filesystem write speed.

To complete the BackupEDGE part of the test, I backed up 33GB of data,
which assured I would need to use 2 volumes.
Data Transfer Speed = 33.741 GB/hr
= 575.876 MB/min
Segments Used = 2
Data Read = 33GB


Even though I can't restore anything more than 2GB into the REV media using
Lone-Tar 4.2, I thought I'd try a few more tests.


The Lone-Tar auto-detector arbitrarily sets the REV volume size at 34000000KB,
or about 32.42GB. This wastes over 177MB of available media space. However,
this is MUCH BETTER than the volume size their last release used, which
was 35000000KB, or about 799MB MORE than the actual capacity of a REV. For
over a year they didn't notice this, so one wonders if they never really tried
to fill a single REV.

So I set a very high volume size and tried to write 35GB of data to the REV.
Lone-Tar DIDN'T NOTICE WHEN IT RAN OUT OF MEDIA, and just continued to write
the data to nowhere until the 35GB was complete.

During verify, it may or may not notice that it threw that data away, depending
on whether the last block it DID write was the last block of a real file.

If you've got an older release of Lone-Tar with the size set to 35000000,
you need to go lower it before you fill a volume.

Question: If the Lone-Tar writer ignores the fact that it has no media, or that
it has filled the media, what does it do with normal, everyday write errors
or SCSI errors?


BackupEDGE actually ASKS THE MEDIA how many raw blocks are available, applies
the appropriate mmc-recommended formula, and calculates a reliable volume size. It does this on a PER-MEDIA basis during a backup.

This is even more important when using CD/DVD media, where BackupEDGE detects
media type, write strategy, preparation strategy and volume size on a
per media basis. A multi-volume backup can actually have a DVD+R dual layer
as volume 1, CD-RW as volume 2, DVD+RW as volume 3, and an 8cm 200MB CD-R
as volume 4, or any other combination of supported media. It will get
everything right, including preparing and finishing the media (if necessary)
and setting each volume size to the maximum usable space. No least-common
denominators that waste space, and no knowledge on the part of the end-user
required.

Note: Lone-Tar told me it couldn't identify my Sony DVD-Multi drive and
was going to set it to be a CD-RW drive, and did so with a
least-common-denominator CD volume size. When I re-set it to DVD-RAM, as an
end-user I would have had no idea what volume size to use. Fortunately for me,
I was able to ask BackupEDGE for the proper volume size to give Lone-Tar.


Full disclosure. If you take volume size out of BackupEDGE's hands and set
it too high, it can hang when media is full on the REV. It won't keep backing
up and pass the backup: it will just stop. We didn't notice that since
BackupEDGE, not the user, is responsible for volume size. We're looking to
see if we need to improve that.


So, so far, we have Lone-Tar 4.2...
- not detecting that the REV has no media.
- not properly recognizing when something bad happens to the writer.
- not detecting and using maximum storage space on the media.
- not detecting that the REV has filled the media if bad volume size is used.
- not being nearly as fast as BackupEDGE where we could test it.

and most importantly.
- not being able to restore more than 2GB of data from a backup.

They must have blown the 2GB thing in their rush to release 4.2. I know
they had this problem before but I thought they fixed it.


Flawless, huh?

I would point out that these are just two devices on one system, using one
version of Lone-Tar (the latest they had on Monday when I started these
tests). Your results may vary. And knowing what I know, I expect the 2GB issue
to be limited to OpenServer 5.


Should they get these problems resolved, I guess I'll mention a few more
reasons why BackupEDGE is the far better choice for REV (or any other media).

1) The BackupEDGE data format includes full-file error checksumming, not just
header checksumming like Lone-Tar. This is incredibly important when
switching from tape drives, which have built in error checking, to other
media types and network backups which do not.

2) It is 2006, and Lone-Tar will STILL fail to back up files with over 400
character pathnames or 170 character link pathnames. BackupEDGE handles
5,000 character pathnames of any type, far longer than UNIX can actually
traverse or create.

3) BackupEDGE has Instant File Restore, which can access files within seconds
from network, REV, DVD, and CD backups (even those with multiple volumes).
I couldn't make Fast Seek Restore from Lone-Tar work on the REV, so they'll
have to tell us if it is supposed to, or whether they still have to read
through the entire medium to get to the files / directories to be restored.

4) If you are a command-line writer, you'll want to note that BackupEDGE is
fully coupled for all media types. In other words...

edge cvf rev0 [files]

will take its que from your default REV device settings and write
directly to the REV, getting volume size, compression, etc. correct.

5) If you are running BackupEDGE on OpenServer 6, UnixWare 7, Linux, etc.
and using Access Control Lists (ACLs), BackupEDGE understands how to
archive and restore them.

6) The performance of our compressor is far higher both in compression ratio
and speed than the legacy Lone-Tar compressor, and far higher in speed
than their new bzip2 compressor, although it is a small percentage lower
in compression ratio than bzip2. We examined bzip2 (and other technologies)
three years ago when we replaced our compressor, but found it far too
slow to be useful in a day-to-day production backup environment. We
settled on ZLIB compression. It's balance of speed and compression ratio
is very well suited for backup, and we make all nine levels available
for users to tune.

Bzip2 is great for compressing files for things like internet downloads,
where it doesn't matter how long it takes to compress, since it is only
being done once, and the bandwidth savings are great. It is also great
for that one time when you have to compress as much as possible to fit
on a CD.

We also don't require any temporary disk space, as Lone-Tar does. This both
wastes space (which you may not have) and slows performance. If you compress
large files to REV with Lone-Tar and watch the drive, it simply shuts down
for long periods of time while the program is compressing to the temporary
file.

6) BackupEDGE fully supports the REV 1000 SCSI autoloader, including random
slot access and access by barcode label.

7) BackupEDGE fully supports the REV 280 USB autoloader on Linux. Supporting
it under OSR5, OSR6 and UW7 requires SCO to fix a small driver issue. We
have reported it and are waiting for the fixes.


So BackupEDGE has "the other 90% of the work", including...
- Media detection and preparation
- Volume Size detection
- performance optimization
- data format
- error checking
- "Instant File Restore"
- support for ALL REV technologies
to make REV technology a truly useful storage technology. It is DESIGNED
to fail when it encounters a problem. Any problem. Write or read.


> Also technical support is more user
> friendly, you talk to the main programmer the first time you talk to
> someone. Don't need to escalate to the next level.

Their programmer is also their tech support person? Oh, my. I' rather have
engineers programming and support people supporting, unless an escalation
is required. Most of day-to-day support does not require an engineer and
would keep he/she from doing what they are paid for.

> Just my 2 cents.

Yeah ;-)


Tom
D. Thomas Podnar
Microlite Corporation
2315 Mill Street
Aliquippa PA USA 15001-2228
724-375-6711
888-257-3343 Sales
Developers of Microlite BackupEDGE

Just a couple of comments on two paragraphs - wjv.

In article <200607131602.MAA04241@mlite.microlite.com>,
D. Thomas Podnar <tom@microlite.com> wrote:
>Enrique Arredondo <atk@sbcglobal.net> said...


>> I think BackupEdge is crap with REV drives (too many bad experiences)....
>> Get LoneTar instead. It's flawless with REV drives. Download a trial
>> version and you'll see what I mean. Also technical support is more user
>> friendly, you talk to the main programmer the first time you talk to
>> someone. Don't need to escalate to the next level. Just my 2 cents.

>Mr. Arredondo.

>I normally ignore this kind of stuff. Responding properly requires pointing out
>to a potential client that they might be wrong about something, and to talk
>about someone else's product in a less-than glowing fasion. Neither are my
>favorite things to do.

.....

>BackupEDGE actually ASKS THE MEDIA how many raw blocks are available, applies
>the appropriate mmc-recommended formula, and calculates a reliable volume size. It does this on a PER-MEDIA basis during a backup.

>This is even more important when using CD/DVD media, where
>BackupEDGE detects media type, write strategy, preparation
>strategy and volume size on a per media basis. A multi-volume
>backup can actually have a DVD+R dual layer as volume 1, CD-RW
>as volume 2, DVD+RW as volume 3, and an 8cm 200MB CD-R as volume
>4, or any other combination of supported media. It will get
>everything right, including preparing and finishing the media (if
>necessary) and setting each volume size to the maximum usable
>space. No least-common denominators that waste space, and no
>knowledge on the part of the end-user required.

Now that is SLICK. So many things - not just computers - get
lockked in on what the first media is.

>1) The BackupEDGE data format includes full-file error
>checksumming, not just header checksumming like Lone-Tar. This is
>incredibly important when switching from tape drives, which have
>built in error checking, to other media types and network backups
>which do not.

I have the few remainging sites I do work for running BackupEdge
and Lone-Tar.

I just double checked the Lone-Tar - version 4.1.5 - and the
default is bit-level-verify - which has parens after it that
says (recommended). The check-sum verify is the second option
on the verify menu. I also had a failed bit-level verify last
night and I checked and it pointed to where the byte vefify failed.
It identifes the failure with a message of "bytes differ at
kilobyte 269213". I'd prefer finer-grained reporting, but at
least it does bit-level.

Or did you mean something else when you said "full-file error
checksumming" ? If so, my apologies.

And even with devices that have built-in error checking I'd still
always go for a bit-level. I can envision some starnge happening
where the date becomes courrupt from the time it is read from the
disk and before it hits the tape drive. Then the tape-drive
will perform error checking against the corrupt data. This
could/should be extrememly rare. And the reverse should also be
true on a restore. Run a bit level to make sure the restored
data matches what is on the tape.

The only time I had probelms with any backup program was
a version of Ctar which was disabled after running a year.

I called Ctar and talked with (probably) Steve, and he said that
was done because the dealer who installed that was suspected of
bootlegging material. Now THAT was true, but about the only piece
that was not bootlegged was the CTAR. At that point the owner
decided the competitive upgrade to BackupEdge was the best way to
go. That was on a Xenix system back in 1990. They have been
upgrading it through changes from Xenix thru a couple of SCO
versions to their current Suse platform - and also have a support
contract in case they can't get in touch with me to fix a problem.

That's 16 years from a very happy customer. They just keep getting
bigger, and have now outgrown their second main building.

With data you can't be too sure if you business depends upon it.

Bill
--
Bill Vermillion - bv @ wjv . com

Tom,

I liked your product with DAT tapes but now in my case it didn't worked.

[snip]

> pent two weeks working to help you, even though the Dell web site
> CLEARLY STATES...
>
> "NOTE: The PERC 4/Di/Si and 4e/Di/Si RAID controllers support
> hard disk drives only; they do not support CD-ROMs, tape drives,
> tape libraries, or scanners."
>
> Dell Reference:
> http://support.dell.com/support/edoc...en&cs=04&s=bsd
>

Lonetar worked out of the box even that DELL denies the posibility of that
task.


> So even though Dell says DON'T DO THIS (the REV has a CD-ROM-type BIOS)
> you still thought it was a good thing to do. We tried to help.
>
> Lone-Tar is MUCH less sophisticated in its REV error handling than
> BackupEDGE,
> and I eventually made a decision to stop spending engineering time trying
> to
> support a host adapter that that the manufacture says a REV should never
> be
> plugged into.
>
>
>> Get LoneTar instead. It's flawless with REV drives.
>
> Let's examine that statement. I'll have to, in order to justify what I
> said in my last paragraph, won't I?
>

[ snip ]


The bottom line is that I didn't spend more than 3 minutes of my time after
I downloaded Lonetar (versus 2 weeks of frustating time with backupedge ,
which it never worked out anyways). Since using Lonetar ,my REV BACKUP has
been working flawlessly every single day for almost a year. And I'm not
using the most recent version from Lonetar. It's version 4.05. The new
release has more features than the one I currently use.
For me , the product worked the first time I tried and I'm very happy with
it. When I needed help, I want to talk to a tech rep that has my level of
knowledge and not a waste my time or your time talking to a low level Tech
support rep for 2 weeks so then the escalate the call to a "higher" level.

Thanks for your analisys.

SCO + LONETAR + REV drives + DELL PERC4 = The best choice for me.


Mr. Arredondo

--------------------------- clipped ---------------------------
| >1) The BackupEDGE data format includes full-file error
| >checksumming, not just header checksumming like Lone-Tar. This is
^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Bill,
Tom has made some comments about LONE-TAR that are incorrect and he's
been doing this for some time. I may prepare a more detailed reply to
these inaccuracies, but in the mean time, here's where the info is on
bit-level failures.

# ltmenu
7 -> 5 -> 9 -> 1
7 -> 5 -> 9 -> h This HELP Screen is informative.
.... or ...

# more /log/changed.V
^^^^^------------- $TARDIR set inside ltar.cfg (or ENV for older copies)

| >incredibly important when switching from tape drives, which have
| >built in error checking, to other media types and network backups
| >which do not.
|
| I have the few remainging sites I do work for running BackupEdge
| and Lone-Tar.
|
| I just double checked the Lone-Tar - version 4.1.5 - and the
| default is bit-level-verify - which has parens after it that
| says (recommended). The check-sum verify is the second option
| on the verify menu. I also had a failed bit-level verify last
| night and I checked and it pointed to where the byte vefify failed.
| It identifes the failure with a message of "bytes differ at
| kilobyte 269213". I'd prefer finer-grained reporting, but at
| least it does bit-level.

Bill... Not only is bit-level recommended, we will WARN you if
fail to do bit-level. Making sure the data is safe, and recoverable
to another system is what its all about... weither with edge or lone-tar,
or anything else for that matter. Weither Tom appreciates it or not,
competitive products are good for the public. It keeps everyone on their
toes not only with features, but pricing as well. Tom is one of my
best salesman.
--------------------------- clipped ---------------------------

Best Regards,
Jeffrey Hyman, CEO/President
.--.
___________________________ .-. | | _____________________________________
Lone Star Software Corp. | | | | .-. Home of World Famous LONE-TAR(tm)
Cactus International, Inc. | |_| | | | Backup Software for UNIX and LINUX
Sales: 800.525.8649 _ |___ |_| | 24x7 Support Available
Support: 301.829.1622 _| ~- | ___| RESCUE-RANGER(tm) and AIR-BAG(tm)
http://www.LONE-TAR.com \, _} | | Disaster Recovery Software
-------------------------- \( -- | | --------------------------------------
| |

On Thu, 13 Jul 2006, Jeff Hyman wrote:
> Bill... Not only is bit-level recommended, we will WARN you if
> fail to do bit-level. Making sure the data is safe, and recoverable
> to another system is what its all about... weither with edge or lone-tar,
> or anything else for that matter. Weither Tom appreciates it or not,
> competitive products are good for the public. It keeps everyone on their
> toes not only with features, but pricing as well. Tom is one of my
> best salesman.

I use both products. For new customers I have them download both and use
them in their real world enviroment. I insist that all my customers use
some form of backup with bit-level verification. Each customer decides
which is best for their needs. I have been very happy using both of these
products for many years. the competition between them benefits us all. I
think it makes them refine their products.

--
Boyd Gerber <gerberb@zenez.com>
ZENEZ 1042 East Fort Union #135, Midvale Utah 84047

In article <Pine.LNX.4.64.0607131421130.1212@xenau.zenez.com> ,
Boyd Lynn Gerber <gerberb@zenez.com> wrote:
>On Thu, 13 Jul 2006, Jeff Hyman wrote:
>> Bill... Not only is bit-level recommended, we will WARN you if
>> fail to do bit-level. Making sure the data is safe, and recoverable
>> to another system is what its all about... weither with edge or lone-tar,
>> or anything else for that matter. Weither Tom appreciates it or not,
>> competitive products are good for the public. It keeps everyone on their
>> toes not only with features, but pricing as well. Tom is one of my
>> best salesman.

>I use both products. For new customers I have them download both and use
>them in their real world enviroment. I insist that all my customers use
>some form of backup with bit-level verification. Each customer decides
>which is best for their needs. I have been very happy using both of these
>products for many years. the competition between them benefits us all. I
>think it makes them refine their products.

One reason I use both is that between them they cover all the
platforms I support [and used to support]. I 'lent' a machine
to Steve on the 'net so he could compile a version for SGI's Irix,
and Lone-Tar also supports FreeBSD. Between the two programs
you can cover almost all Unix machine extant, and at one time
BRU covered those the other two didn't. I don't know muhc about
BRU since it changed hands a few years ago, but I see they
also have Mac OS/X backup programs.

Bill

--
Bill Vermillion - bv @ wjv . com

On Thu, Jul 13, 2006 at 06:27:50PM +0000, Enrique Arredondo wrote:
> [ snip ]
>
>
> The bottom line is that I didn't spend more than 3 minutes of my time after
> I downloaded Lonetar (versus 2 weeks of frustating time with backupedge ,
> which it never worked out anyways). Since using Lonetar ,my REV BACKUP has
> been working flawlessly every single day for almost a year. And I'm not
> using the most recent version from Lonetar. It's version 4.05. The new
> release has more features than the one I currently use.
> For me , the product worked the first time I tried and I'm very happy with
> it.
> When I needed help, I want to talk to a tech rep that has my level of
> knowledge and not a waste my time or your time talking to a low level Tech
> support rep for 2 weeks so then the escalate the call to a "higher" level.

Well we all want that. Fortunately, we have Arnie, who handled your emails.
Arnie has 10 1/2 YEARS in support here at Microlite, and came to us from a
UNIX background where his SCO experience started, as best as he can recall,
in 1989. It is safe to say his SCO expertise, after 17 years, is pretty good.

Also fortunately, we have a pretty good email support tracking system.
According to it, your first email came in late in the day on August 25, 2005
and was escalated to engineering on August 26, 2005 at about noon, where we
spent a few weeks analyzing your problem, compiling and sending different
versions of our REV writer, and moving into direct conversations with
engineering.

Perhaps your last paragraph was rhetorical.

> Thanks for your analisys.
> SCO + LONETAR + REV drives + DELL PERC4 = The best choice for me.
> Mr. Arredondo

I'm very glad it is working for you. I only take exception when blog-style
generalizations instead of facts are used to paint scenarios.


For those of you who have been saved by Arnie many times, you have a chance
to meet him. He'll be joining us on the floor at Forum next month.
Please come by and say hello.


---
Tom
D. Thomas Podnar
Microlite Corporation
2315 Mill Street
Aliquippa PA USA 15001-2228
724-375-6711
888-257-3343 Sales
Developers of Microlite BackupEDGE

"D . Thomas Podnar" <tom@microlite.com> wrote in message
news:20060714182656.C12213@mlite.microlite.com...
> On Thu, Jul 13, 2006 at 06:27:50PM +0000, Enrique Arredondo wrote:
>> [ snip ]
>>
>>
>> The bottom line is that I didn't spend more than 3 minutes of my time
>> after
>> I downloaded Lonetar (versus 2 weeks of frustating time with backupedge ,
>> which it never worked out anyways). Since using Lonetar ,my REV BACKUP
>> has
>> been working flawlessly every single day for almost a year. And I'm not
>> using the most recent version from Lonetar. It's version 4.05. The new
>> release has more features than the one I currently use.
>> For me , the product worked the first time I tried and I'm very happy
>> with
>> it.
>> When I needed help, I want to talk to a tech rep that has my level of
>> knowledge and not a waste my time or your time talking to a low level
>> Tech
>> support rep for 2 weeks so then the escalate the call to a "higher"
>> level.
>
> Well we all want that. Fortunately, we have Arnie, who handled your
> emails.
> Arnie has 10 1/2 YEARS in support here at Microlite, and came to us from a
> UNIX background where his SCO experience started, as best as he can
> recall,
> in 1989. It is safe to say his SCO expertise, after 17 years, is pretty
> good.
>
> Also fortunately, we have a pretty good email support tracking system.
> According to it, your first email came in late in the day on August 25,
> 2005
> and was escalated to engineering on August 26, 2005 at about noon, where
> we
> spent a few weeks analyzing your problem, compiling and sending different
> versions of our REV writer, and moving into direct conversations with
> engineering.
>
> Perhaps your last paragraph was rhetorical.
>
>> Thanks for your analisys.
>> SCO + LONETAR + REV drives + DELL PERC4 = The best choice for me.
>> Mr. Arredondo
>
> I'm very glad it is working for you. I only take exception when blog-style
> generalizations instead of facts are used to paint scenarios.
>
>
> For those of you who have been saved by Arnie many times, you have a
> chance
> to meet him. He'll be joining us on the floor at Forum next month.
> Please come by and say hello.
>

The worst part was when Arnie told me over the phone.... "You have to go buy
a new SCSI CARD" and I said " Why in the world ? Don't you see it works with
lonetar! you want me to go and spend $1000 on a new card just because you
are sticking with Dell's argument about perc4 (or whatever reason) and just
because of that you are too lazy to try to fix the problem and he just say
yes.". That's what make me leave BE for ever!. Great support ,,, Oh yeah!.
Sure...... Do you keep also track of the phone calls ? Can you listen to it
?

Unbelivable!! 17 years of experience to tell me go buy a card.....
arrrgggggg.

On Mon, 17 Jul 2006, Enrique Arredondo wrote:

> The worst part was when Arnie told me over the phone.... "You have to go buy
> a new SCSI CARD" and I said " Why in the world ? Don't you see it works with
> lonetar! you want me to go and spend $1000 on a new card just because you
> are sticking with Dell's argument about perc4 (or whatever reason) and just
> because of that you are too lazy to try to fix the problem and he just say
> yes.". That's what make me leave BE for ever!. Great support ,,, Oh yeah!.
> Sure...... Do you keep also track of the phone calls ? Can you listen to it
> ?
>
> Unbelivable!! 17 years of experience to tell me go buy a card.....
> arrrgggggg.

The way I see it: 17 years of experience to tell you that it is not smart
to trust your backup to a hardware combination that the hardware vendor
doesn't recommend or support. Sounds like good advice.

Regards,
.....Bob Rasmussen, President, Rasmussen Software, Inc.

personal e-mail: ras@anzio.com
company e-mail: rsi@anzio.com
voice: (US) 503-624-0360 (9:00-6:00 Pacific Time)
fax: (US) 503-624-0760
web: http://www.anzio.com

"Bob Rasmussen" <ras@anzio.com> wrote in message
news:mailman.5.1153161354.26573.sco-misc@lists.celestial.com...
> On Mon, 17 Jul 2006, Enrique Arredondo wrote:
>
>> The worst part was when Arnie told me over the phone.... "You have to go
>> buy
>> a new SCSI CARD" and I said " Why in the world ? Don't you see it works
>> with
>> lonetar! you want me to go and spend $1000 on a new card just because you
>> are sticking with Dell's argument about perc4 (or whatever reason) and
>> just
>> because of that you are too lazy to try to fix the problem and he just
>> say
>> yes.". That's what make me leave BE for ever!. Great support ,,, Oh
>> yeah!.
>> Sure...... Do you keep also track of the phone calls ? Can you listen to
>> it
>> ?
>>
>> Unbelivable!! 17 years of experience to tell me go buy a card.....
>> arrrgggggg.
>
> The way I see it: 17 years of experience to tell you that it is not smart
> to trust your backup to a hardware combination that the hardware vendor
> doesn't recommend or support. Sounds like good advice.
>
> Regards,
> ....Bob Rasmussen, President, Rasmussen Software, Inc.
>


Hey but, come on.. we're not talking about a 1980's SCSI card
technology..it's a 2005-06 Brand spanking new server with DUAL XEON yada
yada yada with state of the art technology scsi card. And Lonetar is still
working great on it! I was just trying to keep using BE and helping these
guys out to come back with the FIX but who cares now! with that attitude
B.I.H.