Re: IOMEGA Rev intermittent failures - SCO

This is a discussion on Re: IOMEGA Rev intermittent failures - SCO ; Enrique Arredondo 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 ...

+ Reply to Thread
Results 1 to 13 of 13

Thread: Re: IOMEGA Rev intermittent failures

  1. Re: IOMEGA Rev intermittent failures

    Enrique Arredondo 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

  2. Re: IOMEGA Rev intermittent failures


    Just a couple of comments on two paragraphs - wjv.

    In article <200607131602.MAA04241@mlite.microlite.com>,
    D. Thomas Podnar wrote:
    >Enrique Arredondo 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

  3. Re: IOMEGA Rev intermittent failures

    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



  4. Re: IOMEGA Rev intermittent failures

    --------------------------- 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
    -------------------------- \( -- | | --------------------------------------
    | |


  5. Re: IOMEGA Rev intermittent failures

    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
    ZENEZ 1042 East Fort Union #135, Midvale Utah 84047

  6. Re: IOMEGA Rev intermittent failures

    In article ,
    Boyd Lynn Gerber 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

  7. Re: IOMEGA Rev intermittent failures

    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

  8. Re: IOMEGA Rev intermittent failures


    "D . Thomas Podnar" 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.






  9. Re: IOMEGA Rev intermittent failures

    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

  10. Re: IOMEGA Rev intermittent failures


    "Bob Rasmussen" 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.





  11. Re: IOMEGA Rev intermittent failures

    Enrique Arredondo wrote:
    > "Bob Rasmussen" 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.
    >
    >
    >
    >


    A 1,000 bucks for a PCI SCSI card to drive just a tape drive? Come on.

    And even if it were that price. Dell, you know, the MANUFACTURER tells
    you NOT to use CD like drives on the PERC channel and you insist on
    doing it anyway??

    Whats wrong with this picture? Wait - I know - you are counting on the
    consulting revenue when a major crash happens. Smart.

    --
    ----------------------------------------------------
    Pat Welch, UBB Computer Services, a WCS Affiliate
    SCO Authorized Partner
    Unix/Linux/Windows/Hardware Sales/Support
    (209) 745-1401 Cell: (209) 251-9120
    E-mail: patubb@inreach.com
    ----------------------------------------------------

  12. Re: IOMEGA Rev intermittent failures


    ----- Original Message -----
    From: "Pat Welch"
    Newsgroups: comp.unix.sco.misc
    To:
    Sent: Tuesday, July 18, 2006 11:28 PM
    Subject: Re: IOMEGA Rev intermittent failures


    > Enrique Arredondo wrote:
    >> "Bob Rasmussen" 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.
    >>
    >>
    >>
    >>

    >
    > A 1,000 bucks for a PCI SCSI card to drive just a tape drive? Come on.
    >
    > And even if it were that price. Dell, you know, the MANUFACTURER tells you
    > NOT to use CD like drives on the PERC channel and you insist on doing it
    > anyway??
    >
    > Whats wrong with this picture? Wait - I know - you are counting on the
    > consulting revenue when a major crash happens. Smart.


    I was going to say something like Bob Rasmussen said.
    17 years of experience should have showed him that just because something
    seems to work doesn't mean squat.
    17 days of experience told me that much.

    Let's say it in Seussese:

    It does not mean it will work near Duluth.
    It does not even mean it works here in truth.
    It doesn't mean it will work for me or he or she.
    It does not even mean it works for thee.
    It does not mean you have found a solution.
    It mostly means luck has made an intrusion.

    Brian K. White -- brian@aljex.com -- http://www.aljex.com/bkw/
    +++++[>+++[>+++++>+++++++<<-]<-]>>+.>.+++++.+++++++.-.[>+<---]>++.
    filePro BBx Linux SCO FreeBSD #callahans Satriani Filk!


  13. Re: IOMEGA Rev intermittent failures

    Pat Welch wrote:
    > Enrique Arredondo wrote:
    >
    >> "Bob Rasmussen" 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.
    >>
    >>
    >>
    >>

    >
    > A 1,000 bucks for a PCI SCSI card to drive just a tape drive? Come on.
    >
    > And even if it were that price. Dell, you know, the MANUFACTURER tells
    > you NOT to use CD like drives on the PERC channel and you insist on
    > doing it anyway??
    >
    > Whats wrong with this picture? Wait - I know - you are counting on the
    > consulting revenue when a major crash happens. Smart.


    Having followed this thread with interest in all it's convolutions, I
    have to inject:
    Dell does not have the only SCSI RAID controller system that does not
    work correctly under SCO UNIX and even WINDOWS SERVER for some devices.
    I bought an IBM Server and the IBM SCSI Tape drive would not work
    correctly when attached to the add-in RAID controller, using IBM's
    drivers. It also did not work correctly when attached to the single
    channel built-in tape controller as long as the add-in RAID controller
    card was present. Worked well when I took the add-in RAID controller
    card out and attached the tape drive and one hard drive to the built-in
    single channel SCSI controller. I put the add-in RAID controller back
    in, put in a single channel adaptec SCSI controller that was not in use
    at the time, attached the tape drive to the Adaptec controller, and the
    tape drive worked properly. Everything has been fine since. I found out
    through IBM's support site that several people using the same server for
    a WINDOWS server also experienced similar problems, with a similar
    solution. The symptom I had with the tape drive was consistent loss of
    data during a backup and the backup would stop and hang up sometimes.
    Of course, I found out about the loss of data by restoring the backup.
    This happened with the tar and cpio backup utilities. Habitually, I
    always test with the built-in utilities. Thankfully the problem showed
    up early in testing so I never felt that it was working properly.
    Of course I complained loudly, but sometimes you just have to bite the
    bullet and move on because time's a'wasting.
    >



    --
    William P. Akers E-Mail: billa@mgmindustries.com
    MGM Industries, Inc. Web Site: http://www.mgmindustries.com
    Hendersonville TN

+ Reply to Thread