DFSEE vs Seagate Backup Exec - OS2

This is a discussion on DFSEE vs Seagate Backup Exec - OS2 ; _____ Looks my trusty HP Colorado T1000e parallel port tape machine is failing. I have tried to work with DFSEE starting from a floppy. Was able to make an image of Drive C: onto another partition such as Drive E:. ...

+ Reply to Thread
Results 1 to 19 of 19

Thread: DFSEE vs Seagate Backup Exec

  1. DFSEE vs Seagate Backup Exec

    _____
    Looks my trusty HP Colorado T1000e parallel port tape machine is
    failing. I have tried to work with DFSEE starting from a floppy. Was
    able to make an image of Drive C: onto another partition such as Drive
    E:. What is the procedure to rebuild an entire copy of OS/2 onto the C:
    partition using the previously written C: drive image? DFSEE looks like
    a very thorough toolkit, but i find it rather cryptic.
    --
    Regards / JCH

  2. Re: DFSEE vs Seagate Backup Exec

    jch wrote:
    > _____
    > Looks my trusty HP Colorado T1000e parallel port tape machine is
    > failing. I have tried to work with DFSEE starting from a floppy. Was
    > able to make an image of Drive C: onto another partition such as Drive
    > E:. What is the procedure to rebuild an entire copy of OS/2 onto the C:
    > partition using the previously written C: drive image? DFSEE looks like
    > a very thorough toolkit, but i find it rather cryptic.

    _____
    Found it. In the DFSEE folder there are objects that do what i need;
    make an image of drive C: onto, say, drive E:, and then restore that
    image back where it came from. I have just never tried it, and assume
    that the restore job is reliable. I normally work from a Maintenance
    Partition on drive D:, so i can run the relevant programs from there.
    --
    Regards / JCH

  3. Re: DFSEE vs Seagate Backup Exec

    jch wrote:
    > jch wrote:
    >
    >> _____
    >> Looks my trusty HP Colorado T1000e parallel port tape machine is
    >> failing. I have tried to work with DFSEE starting from a floppy. Was
    >> able to make an image of Drive C: onto another partition such as Drive
    >> E:. What is the procedure to rebuild an entire copy of OS/2 onto the
    >> C: partition using the previously written C: drive image? DFSEE looks
    >> like a very thorough toolkit, but i find it rather cryptic.

    >
    > _____
    > Found it. In the DFSEE folder there are objects that do what i need;
    > make an image of drive C: onto, say, drive E:, and then restore that
    > image back where it came from. I have just never tried it, and assume
    > that the restore job is reliable. I normally work from a Maintenance
    > Partition on drive D:, so i can run the relevant programs from there.


    I would suggest that you need to make the backup on a separate (second)
    physical drive. If the backup is on the same physical drive, what
    happens when the drive fails?

    --
    Jack Wise

    PM, Jacques DeMolay Lodge No. 1390, AF & AM, Houston, TX
    ( www.jd1390.org/jdmlodge.htm )

    Member: Oak Wood Lodge No. 1444, AF & AM, The Woodlands, TX


    TEXAS red wine: renowned for its smoky-mesquite-bbq & jalapeno
    overtones, the perfect foil for a meal of tacos and refried beans...

  4. Re: DFSEE vs Seagate Backup Exec

    Jack Wise wrote:
    > jch wrote:
    >> jch wrote:
    >>
    >>> _____
    >>> Looks my trusty HP Colorado T1000e parallel port tape machine is
    >>> failing. I have tried to work with DFSEE starting from a floppy.
    >>> Was able to make an image of Drive C: onto another partition such as
    >>> Drive E:. What is the procedure to rebuild an entire copy of OS/2
    >>> onto the C: partition using the previously written C: drive image?
    >>> DFSEE looks like a very thorough toolkit, but i find it rather cryptic.

    >>
    >> _____
    >> Found it. In the DFSEE folder there are objects that do what i need;
    >> make an image of drive C: onto, say, drive E:, and then restore that
    >> image back where it came from. I have just never tried it, and assume
    >> that the restore job is reliable. I normally work from a Maintenance
    >> Partition on drive D:, so i can run the relevant programs from there.

    >
    > I would suggest that you need to make the backup on a separate (second)
    > physical drive. If the backup is on the same physical drive, what
    > happens when the drive fails?

    _____
    You are absolutely correct. The procedure i follow after the image has
    been written to E: drive, is to copy it to my OpenBSD file server. The
    server OS and all the data files (including the OS/2 C: drive image of
    about 230 Mb) is backup up every night. I use a removable hard disk
    cartridge that is rotated every Sunday. So, when the OS/2 hard disk
    fails catastrophically, i can restore it from this disk. However, that
    takes quite a bit of work. It was much simpler to use the tape machine
    which has lasted well over 10 years. Some of the rubber drive components
    have started to lose their original quality, and slippage occurs.
    --
    Regards / JCH

  5. Very low data transfer rate IBM Peer to BSD server


    Jack Wise wrote:

    >> I would suggest that you need to make the backup on a separate
    >> (second) physical drive. If the backup is on the same physical drive,
    >> what happens when the drive fails?


    > The procedure i follow after the image has been written to E: drive,
    > is to copy it to my OpenBSD file server. The server OS and all the
    > data files (including the OS/2 C: drive image of about 230 Mb) are
    > backup up every night.

    _____
    Using IBM Peer to copy data to the file server i get incredibly (and
    unacceptable) low data rates in the order of 600 bytes/sec! I use a 10
    Mb LAN, and the usual xfer rate between OpenBSD machines using SCP or
    FTP is in the order of 1,000 Mbytes/sec. So, instead i started the FTPD
    program on the OpenBSD file server, and used FTP on the OS/2 machine to
    do the xfer. The data rate for a 230 Mb disk image file was 30 Kb/sec.
    This is a factor 30 or so lower than what the LAN and the
    computers/NICs are capable of.

    What tuning parameters in the OS/2 environment should i suspect and
    alter to improve the data xfer performance? Something is wrong for sure.
    --
    Regards / JCH

  6. Re: Very low data transfer rate IBM Peer to BSD server

    jch wrote:
    >
    > Jack Wise wrote:
    >
    >>> I would suggest that you need to make the backup on a separate
    >>> (second) physical drive. If the backup is on the same physical
    >>> drive, what happens when the drive fails?

    >
    >> The procedure i follow after the image has been written to E: drive,
    >> is to copy it to my OpenBSD file server. The server OS and all the
    >> data files (including the OS/2 C: drive image of about 230 Mb) are
    >> backup up every night.

    >
    > _____
    > Using IBM Peer to copy data to the file server i get incredibly (and
    > unacceptable) low data rates in the order of 600 bytes/sec! I use a 10
    > Mb LAN, and the usual xfer rate between OpenBSD machines using SCP or
    > FTP is in the order of 1,000 Mbytes/sec. So, instead i started the FTPD
    > program on the OpenBSD file server, and used FTP on the OS/2 machine to
    > do the xfer. The data rate for a 230 Mb disk image file was 30 Kb/sec.
    > This is a factor 30 or so lower than what the LAN and the
    > computers/NICs are capable of.
    >
    > What tuning parameters in the OS/2 environment should i suspect and
    > alter to improve the data xfer performance? Something is wrong for sure.


    Is your CPU tied up doing something else and the daemons on the OS/2
    side running at normal priority? Are you getting a large number of
    collisions on your network?

    --
    [Reverse the parts of the e-mail address to reply.]

  7. Re: DFSEE vs Seagate Backup Exec

    jch wrote:
    > Jack Wise wrote:
    >
    >> jch wrote:
    >>
    >>> jch wrote:
    >>>
    >>>> _____
    >>>> Looks my trusty HP Colorado T1000e parallel port tape machine is
    >>>> failing. I have tried to work with DFSEE starting from a floppy.
    >>>> Was able to make an image of Drive C: onto another partition such as
    >>>> Drive E:. What is the procedure to rebuild an entire copy of OS/2
    >>>> onto the C: partition using the previously written C: drive image?
    >>>> DFSEE looks like a very thorough toolkit, but i find it rather cryptic.
    >>>
    >>>
    >>> _____
    >>> Found it. In the DFSEE folder there are objects that do what i need;
    >>> make an image of drive C: onto, say, drive E:, and then restore that
    >>> image back where it came from. I have just never tried it, and
    >>> assume that the restore job is reliable. I normally work from a
    >>> Maintenance Partition on drive D:, so i can run the relevant programs
    >>> from there.

    >>
    >>
    >> I would suggest that you need to make the backup on a separate
    >> (second) physical drive. If the backup is on the same physical drive,
    >> what happens when the drive fails?

    >
    > _____
    > You are absolutely correct. The procedure i follow after the image has
    > been written to E: drive, is to copy it to my OpenBSD file server. The
    > server OS and all the data files (including the OS/2 C: drive image of
    > about 230 Mb) is backup up every night. I use a removable hard disk
    > cartridge that is rotated every Sunday. So, when the OS/2 hard disk
    > fails catastrophically, i can restore it from this disk. However, that
    > takes quite a bit of work. It was much simpler to use the tape machine
    > which has lasted well over 10 years. Some of the rubber drive components
    > have started to lose their original quality, and slippage occurs.


    My solution is to have a second hard drive in my machine. I simply
    create the image on the second hard drive. If the boot drive fails, I
    can install a replacement drive: boot from DFSEE floppy and then
    restore image from the back up drive.

    --
    Jack Wise

    TEXAS red wine: renowned for its smoky-mesquite-bbq & jalapeno
    overtones, the perfect foil for a meal of tacos and refried beans...

  8. Re: Very low data transfer rate IBM Peer to BSD server

    Marty wrote:

    >> Using IBM Peer to copy data to the file server i get incredibly (and
    >> unacceptable) low data rates in the order of 600 bytes/sec! I use a
    >> 10 Mb LAN, and the usual xfer rate between OpenBSD machines using SCP
    >> or FTP is in the order of 1,000 Mbytes/sec. So, instead i started the
    >> FTPD program on the OpenBSD file server, and used FTP on the OS/2
    >> machine to do the xfer. The data rate for a 230 Mb disk image file
    >> was 30 Kb/sec. This is a factor 30 or so lower than what the LAN and
    >> the computers/NICs are capable of.
    >>
    >> What tuning parameters in the OS/2 environment should i suspect and
    >> alter to improve the data xfer performance? Something is wrong for sure.

    >
    > Is your CPU tied up doing something else and the daemons on the OS/2
    > side running at normal priority? Are you getting a large number of
    > collisions on your network?

    _____
    Yes, many collisions, hence my question.
    --
    Regards / JCH

  9. Re: DFSEE vs Seagate Backup Exec

    Jack Wise wrote:

    >> You are absolutely correct. The procedure i follow after the image has
    >> been written to E: drive, is to copy it to my OpenBSD file server. The
    >> server OS and all the data files (including the OS/2 C: drive image of
    >> about 230 Mb) is backup up every night. I use a removable hard disk
    >> cartridge that is rotated every Sunday. So, when the OS/2 hard disk
    >> fails catastrophically, i can restore it from this disk. However, that
    >> takes quite a bit of work. It was much simpler to use the tape machine
    >> which has lasted well over 10 years. Some of the rubber drive components
    >> have started to lose their original quality, and slippage occurs.

    >
    > My solution is to have a second hard drive in my machine. I simply
    > create the image on the second hard drive. If the boot drive fails, I
    > can install a replacement drive: boot from DFSEE floppy and then
    > restore image from the back up drive.

    _____
    Yes, that would be another good solution. I can install another
    cartridge drive bay, and use that drive to hold (a) my OS/2 Maintenance
    System, and (b) image of OS/2 system on Drive C:. For now, i am cutting
    a CD with the image file on it.

    I opened up the HP T1000 tape machine, and sure enough, the rubber
    coating (like a fat, flat rubber band) on drive wheel had started to
    slip. The design is quite simple. If i can find a replacement "rubber
    band", the machine would serve another while yet. The mechanical drive
    internals look like an ExaByte mechanism.
    --
    Regards / JCH

  10. Re: DFSEE vs Seagate Backup Exec

    jch wrote:

    >> I would suggest that you need to make the backup on a separate
    >> (second) physical drive. If the backup is on the same physical drive,
    >> what happens when the drive fails?

    > _____
    > You are absolutely correct. The procedure i follow after the image has
    > been written to E: drive, is to copy it to my OpenBSD file server.

    _____
    An even more elegant solution is to use a surplus 15 Gb (or larger)
    laptop hard drive in an aluminum case that converts it to a USB
    accessible device. I happen to have such a little drive. DFSEE
    supports a USB connection very well after booting from a DFS floppy. I
    am creating an image file of my OS/2 drive C: partition to the USB
    drive. Image transfer took about 27 minutes at a rate 1.22 MiB/sec
    using smart compression mode. That is about the same rate i got when
    using the old HP T1000 tape machine. Next i have to test the restore
    procedure onto a test disk.
    --
    Regards / JCH

  11. Re: DFSEE vs Seagate Backup Exec

    > jch wrote:
    >
    >>> I would suggest that you need to make the backup on a separate
    >>> (second) physical drive. If the backup is on the same physical
    >>> drive, what happens when the drive fails?

    >> _____
    >> You are absolutely correct. .....

    > _____
    > An even more elegant solution is to use a surplus 15 Gb (or larger)
    > laptop hard drive in an aluminum case that converts it to a USB
    > accessible device. DFSEE supports a USB connection very well after
    > booting from a DFS floppy. I am creating an image file of my OS/2
    > drive C: partition to the USB drive. Image transfer took about 27
    > minutes at a rate 1.22 MiB/sec using smart compression mode.

    _____
    Now i am royally stuck! I cannot get the restore step to work. Here is
    what i did as a test:
    1) With DFSEE created image file from current OS/2 Warp 4 system onto
    USB connected drive.
    2) Removed OS/2 drive, replaced it with similar, but not identically
    sized drive.
    3) Using OS/2 utility diskettes, partitioned drive, added IBM BM, and
    a primary partition for OS/2. Formatted C: partition with HPFS. Added
    boot files with "SYSINSTX C:". Checked that system would boot into IBM
    BM. It did.
    4) Ran DFSEE, and restored OS/2 Warp 4 image from USB drive onto new
    drive. Process completed normally.
    5) Booted system from new disk. NOTHING!! Does not even see IBM BM
    code.

    What am i doing wrong? With the tape based recovery procedure, i would
    replace step 4) with a "restore from tape" step.

    DFSEE must be overwriting BM code, primary partition BR code and not
    just replace the OS/2 files after the Boot Record on the new disk. I
    have recently purchased the DFSEE license from MENSYS, and would really
    like to learn how to use the program properly.

    Thanks in advance for any help.
    --
    Regards / JCH

  12. Re: DFSEE vs Seagate Backup Exec

    Maybe I can help here ..

    jch wrote:


    >> An even more elegant solution is to use a surplus 15 Gb (or larger)
    >> laptop hard drive in an aluminum case that converts it to a USB
    >> accessible device. DFSEE supports a USB connection very well after
    >> booting from a DFS floppy. I am creating an image file of my OS/2
    >> drive C: partition to the USB drive. Image transfer took about 27
    >> minutes at a rate 1.22 MiB/sec using smart compression mode.


    I'll vouch for the above. It works fine. Study the above and contrast this
    to what you posted below:


    > Now i am royally stuck! I cannot get the restore step to work. Here is
    > what i did as a test:
    > 1) With DFSEE created image file from current OS/2 Warp 4 system onto
    > USB connected drive.
    > 2) Removed OS/2 drive, replaced it with similar, but not identically
    > sized drive.
    > 3) Using OS/2 utility diskettes, partitioned drive, added IBM BM, and
    > a primary partition for OS/2. Formatted C: partition with HPFS. Added
    > boot files with "SYSINSTX C:". Checked that system would boot into IBM
    > BM. It did.
    > 4) Ran DFSEE, and restored OS/2 Warp 4 image from USB drive onto new
    > drive. Process completed normally.
    > 5) Booted system from new disk. NOTHING!! Does not even see IBM BM
    > code.
    >
    > What am i doing wrong? With the tape based recovery procedure, i would
    > replace step 4) with a "restore from tape" step.
    >
    > DFSEE must be overwriting BM code, primary partition BR code and not
    > just replace the OS/2 files after the Boot Record on the new disk. I
    > have recently purchased the DFSEE license from MENSYS, and would really
    > like to learn how to use the program properly.
    >
    > Thanks in advance for any help.


    For whatever reason you see the above, it may be that things are in contrast to
    what is being booted and expected to be LVM type drive work and Warp 4 which is
    not. Whatever.

    What I've done with all this is simply to clone a whole drive operation to the
    USB attached case, as is described above. But .. there is more! I've also
    gone ahead and used DFSEE to clone the whole drive to an 'internally attached'
    other hard drive, even non-USB. Then, using that completely cloned duplicated
    drive, I can simply boot from it to the new machine. That works. It works
    with Warp 4 to another Warp 4 system, or MCP2 to another MCP2 system. But
    *NOT* with the USB external drive case method with Warp 4. Only with MCP2 on
    the external USB case method.

    And .. it will even work for moving to a different kind of drive completely!

    For example, I can take my IBM R40 ThinkPad with MCP2. I can clone it to a USB
    external drive complete with either a Utility Boot Diskette set for OS/2 .. or
    even DFSEE with DOS! Then I can take that USB drive duplicate image. I can
    then reverse the operation and clone it into an R51 or T42P ThinkPad. That
    will boot as well. Now, sure, the audio is different in the T42P as well as
    the NIC chip. Yes, I have to rework the audio and change to BroadComm PEER
    driver stuff. But I can clone the whole operation as long and ONLY as long as
    I go ahead and clone the whole drive operation. Not try to just copy stuff.

    But wait! There's more!

    I can even take that whole IDE ThinkPad drive MCP2 clone. I can even clone it
    into a standard IDE hard drive in a desktop case. Presto! Startable OS/2
    system. And even better, since I'm using Dani's drivers and so on in the
    cloned system, I can even take it and clone it into a SATA drive on Intel 915
    motherboard desktop system cases!

    Or .. I can use DFSEE and clone a fixed IDE drive complete MCP2 operation and
    clone that IDE drive complete to a SATA drive case and away we go. No not Warp
    4; only MCP2.

    But wait! There's more!

    If I go ahead and add the Adaptec SCSI hard drive device driver stuff, I can
    take the driver and move it from an IDE system to an Adaptec SCSI system!
    Sure, during the boot run I see the failure to find any applicable drives
    during the IDE run. But when it does have the SCSI components in the box, I
    can create a drive that will, in fact, come up with the SCSI stuff! Or .. I
    can do the SCSI operation and move it to SATA operation as needed.

    The whole scenario is not to try to copy just the files and stuff. It is to
    create a whole drive image, then move the needed other utilities into what may
    be needed in the new system from there.

    But you CANNOT go, as far as I know, from Warp 4 to MCP2, or attempt to cross
    populate anything between Warp 4 and MCP2 stuff, just by using DFSEE to move
    files by themselves.

    I've even got the MCP2 USB external IBM ThinkPad R40 clone able to actually
    boot the IBM ThinkPads from that external USB hard drive unit. Yes, you have
    to reset stuff in the BIOS boot order and so on to do that. But it does work
    here at least on MCP2.

    I offer *NO* hope of getting this stuff all like this with Warp 4. Only with
    MCP2 and not even MCP1, and that with all the latest XRC04 Fix Pack, at least,
    together with all the other needed device driver fixes, and at least in some
    cases with Dani's device driver tools added as well.

    Maybe this will help, dunno ..


    --


    --> Sleep well; OS2's still awake!

    Mike Luther

  13. Re: DFSEE vs Seagate Backup Exec

    Mike Luther wrote:
    > Maybe I can help here ..


    >> Now i am royally stuck! I cannot get the restore step to work. Here
    >> is what i did as a test:
    >> 1) With DFSEE created image file from current OS/2 Warp 4 system
    >> onto USB connected drive.
    >> 2) Removed OS/2 drive, replaced it with similar, but not identically
    >> sized drive.
    >> 3) Using OS/2 utility diskettes, partitioned drive, added IBM BM,
    >> and a primary partition for OS/2. Formatted C: partition with HPFS.
    >> Added boot files with "SYSINSTX C:". Checked that system would boot
    >> into IBM BM. It did.
    >> 4) Ran DFSEE, and restored OS/2 Warp 4 image from USB drive onto new
    >> drive. Process completed normally.
    >> 5) Booted system from new disk. NOTHING!! Does not even see IBM BM
    >> code.
    >>
    >> What am i doing wrong? With the tape based recovery procedure, i
    >> would replace step 4) with a "restore from tape" step.
    >>
    >> DFSEE must be overwriting BM code, primary partition BR code and not
    >> just replace the OS/2 files after the Boot Record on the new disk. I
    >> have recently purchased the DFSEE license from MENSYS, and would
    >> really like to learn how to use the program properly.

    >
    > I offer *NO* hope of getting this stuff all like this with Warp 4. Only
    > with MCP2 and not even MCP1, and that with all the latest XRC04 Fix
    > Pack, at least, together with all the other needed device driver fixes,
    > and at least in some cases with Dani's device driver tools added as well.

    _____
    Mike,

    Thanks for your insights. Just received my DFSEE key file this morning,
    so that i can continue to use the tool kit. What i hear from you is
    that i should use the /clone disk/ procedure, not the image one. I
    actually tried that by putting the clone info on the USB attached drive.
    Then i installed an old disk, and put the cloned info onto it.
    Unfortunately, that disk died during the transfer step. I shall try it
    again with a newer disk. I am currently not using LVM partitions.
    Should i consider that?

    I have cloned disks in the past when duplicating Linux Red Hat versions.
    This is done very easily with the dump/restore or cc utilities. I use
    OpenBSD also, and cloning disks is very easy. Obviously if i move the
    OS from one machine to another, and the NIC or sound cards are
    different, i need to make some adjustments. Moving OS/2 Warp 4 from one
    machine to another (with my old tape machine) with slightly different
    hardware, i have always had trouble getting it to run properly. Looks
    like the CONFIG.SYS file info is quite tightly bound to the hardware.

    / John
    --
    Regards / JCH

  14. Re: DFSEE vs Seagate Backup Exec

    Well .. thinking here.

    jch wrote:

    > Mike,
    >
    > Thanks for your insights. Just received my DFSEE key file this morning,
    > so that i can continue to use the tool kit. What i hear from you is
    > that i should use the /clone disk/ procedure, not the image one. I
    > actually tried that by putting the clone info on the USB attached drive.
    > Then i installed an old disk, and put the cloned info onto it.
    > Unfortunately, that disk died during the transfer step. I shall try it
    > again with a newer disk. I am currently not using LVM partitions.
    > Should i consider that?


    I think this is exactly what I am posting towards. I'm *NOT* any expert at all
    this. So noted, as far as I understand, you can't use Warp 4 with LVM
    operations, at least from a generic standpoint. The LVM level operations were
    provided first with Merlin Convenience Pack code at the MCP1 level. In fact,
    as I remember all of this and have very carefully done, you cannot actually
    convert a Warp 4 level system to Merlin Convenience Pack with either MCP2 level
    code .. *OR* .. the eCs platform. I posted in a number of threads reference to
    this. Per my memory, there was a VERY specific avoidance of anyone in the eCs
    group from contesting the position that you cannot, at least in most cases,
    ever convert the Warp 4 hard disk operations to LVM.

    The actual conversion code that DOES work at this, was packaged with the MCP1
    first release for that plateau of OS/2. I've successfully converted a few
    dozen Warp 4 systems to MCP this way. Then, sigh, you get to UPGRADE the MCP1
    level box to MCP2 all over again! That includes all the temporary desktop; the
    complete conversion works at all this.

    As well, some of the tools on Warp 4 do not move either automatically or well
    during this process, which includes the migration from the Warp 4 hard disk
    code to LVM level code. If my memory is correct, you can only move the OS/2
    voice operations by a special manual cross over process when you are at the
    final MCP2 level code. As well, there are audio driver issues that may
    surface. You do the conversion with a "0" (zero level) of adapters. Then gop
    forward later for audio support with whatever. As well there is a PEER network
    issue, I think. Memory says that you have to perhaps go through a second pass
    with the ADMINISTRATOR level and initial password level of PASSWORD first.
    From there you get to customize the actual install of PEERLAN to your other
    desired parameters. I think that the initial level of MCP1 had a glitch in
    this, but without going through the LVM conversion process this way, you really
    risk big failure issues.

    Done carefully and with all this in mind, I've had no upgrade problems at all
    for the move up from Warp 4 to MCP2 level code. But as has never been refuted
    to me at all, this is a not possible process to move from Warp 4 direct by
    conversion to the eCs game.

    That doesn't mean you can't create an MCP2 level system or an eCs system in
    basic form. Then mount a form of archive data system which has application
    DATA on it. And move that to the MCP2 level system just fine. But you can't
    just XCOPY * /H/O/T/S/E/R/V and then SYSINSTX and go on your way between Warp 4
    and MCP2.

    I have no idea of a specialized way of doing this with Jan's DFSEE in some
    patch method. He might comment here on that, or you could partipate in his
    forum on all this and seek other advice there.

    > I have cloned disks in the past when duplicating Linux Red Hat versions.
    > This is done very easily with the dump/restore or cc utilities. I use
    > OpenBSD also, and cloning disks is very easy. Obviously if i move the
    > OS from one machine to another, and the NIC or sound cards are
    > different, i need to make some adjustments. Moving OS/2 Warp 4 from one
    > machine to another (with my old tape machine) with slightly different
    > hardware, i have always had trouble getting it to run properly. Looks
    > like the CONFIG.SYS file info is quite tightly bound to the hardware.
    >
    > / John


    The above is precisely correct as I understand this. The only way I think you
    can really SAFELY do the job is create a Warp 4 hard disk operation first.
    Then you'll have to move to MCP1, thence migrate that again to MCP2. Changes
    in hardware are sure enough bound tightly into the CONFIG.SYS file, appropriate
    device drivers, as well as kernel levels, and little bitty side steps like even
    the changes in hard disk cache and DOS differences. Whatever.

    This is the reason I never could afford to go toward eCs this way. It isn't
    that eCs is bad or good or whatever. It was just I couldn't migrate the stuff
    I had to do and couldn't afford to re-install and completely re-create all the
    rest of the mess to move that way.


    --


    --> Sleep well; OS2's still awake!

    Mike Luther

  15. Re: DFSEE vs Seagate Backup Exec

    On 08/11/08 04:25 pm, Mike Luther wrote:
    > Well .. thinking here.
    >
    > jch wrote:
    >
    >> Mike,
    >>
    >> Thanks for your insights. Just received my DFSEE key file this
    >> morning, so that i can continue to use the tool kit. What i hear from
    >> you is that i should use the /clone disk/ procedure, not the image
    >> one. I actually tried that by putting the clone info on the USB
    >> attached drive. Then i installed an old disk, and put the cloned info
    >> onto it. Unfortunately, that disk died during the transfer step. I
    >> shall try it again with a newer disk. I am currently not using LVM
    >> partitions. Should i consider that?

    >
    > I think this is exactly what I am posting towards. I'm *NOT* any expert
    > at all this. So noted, as far as I understand, you can't use Warp 4 with
    > LVM operations, at least from a generic standpoint. The LVM level
    > operations were provided first with Merlin Convenience Pack code at the
    > MCP1 level. In fact, as I remember all of this and have very carefully
    > done, you cannot actually convert a Warp 4 level system to Merlin
    > Convenience Pack with either MCP2 level code .. *OR* .. the eCs
    > platform. I posted in a number of threads reference to this. Per my
    > memory, there was a VERY specific avoidance of anyone in the eCs group
    > from contesting the position that you cannot, at least in most cases,
    > ever convert the Warp 4 hard disk operations to LVM.
    >
    > The actual conversion code that DOES work at this, was packaged with the
    > MCP1 first release for that plateau of OS/2. I've successfully converted
    > a few dozen Warp 4 systems to MCP this way. Then, sigh, you get to
    > UPGRADE the MCP1 level box to MCP2 all over again! That includes all the
    > temporary desktop; the complete conversion works at all this.
    >
    > As well, some of the tools on Warp 4 do not move either automatically or
    > well during this process, which includes the migration from the Warp 4
    > hard disk code to LVM level code. If my memory is correct, you can only
    > move the OS/2 voice operations by a special manual cross over process
    > when you are at the final MCP2 level code. As well, there are audio
    > driver issues that may surface. You do the conversion with a "0" (zero
    > level) of adapters. Then gop forward later for audio support with
    > whatever. As well there is a PEER network issue, I think. Memory says
    > that you have to perhaps go through a second pass with the ADMINISTRATOR
    > level and initial password level of PASSWORD first. From there you get
    > to customize the actual install of PEERLAN to your other desired
    > parameters. I think that the initial level of MCP1 had a glitch in this,
    > but without going through the LVM conversion process this way, you
    > really risk big failure issues.
    >
    > Done carefully and with all this in mind, I've had no upgrade problems
    > at all for the move up from Warp 4 to MCP2 level code. But as has never
    > been refuted to me at all, this is a not possible process to move from
    > Warp 4 direct by conversion to the eCs game.
    >
    > That doesn't mean you can't create an MCP2 level system or an eCs system
    > in basic form. Then mount a form of archive data system which has
    > application DATA on it. And move that to the MCP2 level system just
    > fine. But you can't just XCOPY * /H/O/T/S/E/R/V and then SYSINSTX and go
    > on your way between Warp 4 and MCP2.
    >
    > I have no idea of a specialized way of doing this with Jan's DFSEE in
    > some patch method. He might comment here on that, or you could partipate
    > in his forum on all this and seek other advice there.
    >
    >> I have cloned disks in the past when duplicating Linux Red Hat
    >> versions. This is done very easily with the dump/restore or cc
    >> utilities. I use OpenBSD also, and cloning disks is very easy.
    >> Obviously if i move the OS from one machine to another, and the NIC or
    >> sound cards are different, i need to make some adjustments. Moving
    >> OS/2 Warp 4 from one machine to another (with my old tape machine)
    >> with slightly different hardware, i have always had trouble getting it
    >> to run properly. Looks like the CONFIG.SYS file info is quite tightly
    >> bound to the hardware.
    >>
    >> / John

    >
    > The above is precisely correct as I understand this. The only way I
    > think you can really SAFELY do the job is create a Warp 4 hard disk
    > operation first. Then you'll have to move to MCP1, thence migrate that
    > again to MCP2. Changes in hardware are sure enough bound tightly into
    > the CONFIG.SYS file, appropriate device drivers, as well as kernel
    > levels, and little bitty side steps like even the changes in hard disk
    > cache and DOS differences. Whatever.
    >
    > This is the reason I never could afford to go toward eCs this way. It
    > isn't that eCs is bad or good or whatever. It was just I couldn't
    > migrate the stuff I had to do and couldn't afford to re-install and
    > completely re-create all the rest of the mess to move that way.
    >
    >


    I didn't have any problems adding LVM and JFS to my Warp 4 system. I
    used this package,
    http://hellspawn.dnsalias.net/~mirco...w4_lvm_jfs.zip which claims
    it just needs FP 13+ and includes a kernel, updated disk drivers, all
    the LVM stuff and the jfs stuff and a detailed installation guide. You
    do have to be carefull to install stuff in the right order and set your
    volumes before rebooting. Also includes a script to build a warpin
    archive which I never tried.
    syslevel reports XR0L001_Logical Volume Manager (LVM) Fixpak so it
    probably is MCP1 level.
    The web page says the files were all taken from some free updates.
    Dave

  16. Re: DFSEE vs Seagate Backup Exec

    Dave Yeo wrote:

    >> The above is precisely correct as I understand this. The only way I
    >> think you can really SAFELY do the job is create a Warp 4 hard disk
    >> operation first. Then you'll have to move to MCP1, thence migrate that
    >> again to MCP2. Changes in hardware are sure enough bound tightly into
    >> the CONFIG.SYS file, appropriate device drivers, as well as kernel
    >> levels, and little bitty side steps like even the changes in hard disk
    >> cache and DOS differences. Whatever.
    >>
    >> This is the reason I never could afford to go toward eCs this way. It
    >> isn't that eCs is bad or good or whatever. It was just I couldn't
    >> migrate the stuff I had to do and couldn't afford to re-install and
    >> completely re-create all the rest of the mess to move that way.
    >>
    >>

    >
    > I didn't have any problems adding LVM and JFS to my Warp 4 system. I
    > used this package,
    > http://hellspawn.dnsalias.net/~mirco...w4_lvm_jfs.zip which claims
    > it just needs FP 13+ and includes a kernel, updated disk drivers, all
    > the LVM stuff and the jfs stuff and a detailed installation guide. You
    > do have to be careful to install stuff in the right order and set your
    > volumes before rebooting. Also includes a script to build a warpin
    > archive which I never tried.
    > syslevel reports XR0L001_Logical Volume Manager (LVM) Fixpak so it
    > probably is MCP1 level.
    > The web page says the files were all taken from some free updates.

    _____
    Dave,

    Thanks. Excellent info! Have downloaded above referenced
    w4_lvm_jfs.zip package, and will check it in the near future. Is an LVM
    partitioned disk easier to deal with than the old fashioned drive letter
    scheme? What are the advantages? I have zero understanding about LVM
    partitioning.

    / John
    --
    Regards / JCH

  17. Re: DFSEE vs Seagate Backup Exec

    Bingo!

    Dave Yeo wrote:

    > I didn't have any problems adding LVM and JFS to my Warp 4 system. I
    > used this package,
    > http://hellspawn.dnsalias.net/~mirco...w4_lvm_jfs.zip which claims
    > it just needs FP 13+ and includes a kernel, updated disk drivers, all
    > the LVM stuff and the jfs stuff and a detailed installation guide. You
    > do have to be carefull to install stuff in the right order and set your
    > volumes before rebooting. Also includes a script to build a warpin
    > archive which I never tried.
    > syslevel reports XR0L001_Logical Volume Manager (LVM) Fixpak so it
    > probably is MCP1 level.
    > The web page says the files were all taken from some free updates.
    > Dave


    Downloaded! I'll tear into this in the near future and see what I can learn.
    I've actually got two boxes left on Warp 4 I'd like to move to MCP2. If I
    could connect the logic for the LVM operations to the Warp 4 disks, then I just
    might be able to simply bridge them to a clean MCP2 install. I might be able
    to simply copy the required files/directories to the MCP2 drive, then simply
    copy the Desktop objects required.

    No I haven't read the documentation yet, but I assume this is what you are
    pointing us towards, Dave?

    Thanks!

    --


    --> Sleep well; OS2's still awake!

    Mike Luther

  18. Re: DFSEE vs Seagate Backup Exec

    On 08/11/08 10:32 pm, jch wrote:
    > Dave Yeo wrote:

    [...]
    >> I didn't have any problems adding LVM and JFS to my Warp 4 system. I
    >> used this package,
    >> http://hellspawn.dnsalias.net/~mirco...w4_lvm_jfs.zip which
    >> claims it just needs FP 13+ and includes a kernel, updated disk
    >> drivers, all the LVM stuff and the jfs stuff and a detailed
    >> installation guide. You do have to be careful to install stuff in the
    >> right order and set your volumes before rebooting. Also includes a
    >> script to build a warpin archive which I never tried.
    >> syslevel reports XR0L001_Logical Volume Manager (LVM) Fixpak so it
    >> probably is MCP1 level.
    >> The web page says the files were all taken from some free updates.

    > _____
    > Dave,
    >
    > Thanks. Excellent info! Have downloaded above referenced w4_lvm_jfs.zip
    > package, and will check it in the near future. Is an LVM partitioned
    > disk easier to deal with than the old fashioned drive letter scheme?
    > What are the advantages? I have zero understanding about LVM partitioning.
    >
    > / John


    LVM still uses drive letters, the nice thing is that you can assign the
    drive letters to which ever partition you want.
    eg I just updated my disk drive, put new one in as master with my old
    one as slave and the old slave as secondary slave. Used DFsee to install
    BootManager to the first hard drive and OS/2 booted just fine (as E I
    then started creating partitions, giving them drive letters, xcopied
    everything over and changed the drive letters so E: was now on the first
    hard drive. much simpler then the old days when you had to do a lot of
    planning to make sure your drive letters worked out right.
    Other advantages include being able to use JFS, large file support,
    short chkdsk times and a JFS volume can span multiple partions, even
    across disks.
    Problems include, you can't go back. Some other programs like other
    system partitioning programs could screw things up.
    Dave

  19. Re: Very low data transfer rate IBM Peer to BSD server




    On 8/7/08 11:30 AM, in article NqFmk.62861$nD.58254@pd7urf1no, "jch"
    wrote:

    > Marty wrote:
    >
    >>> Using IBM Peer to copy data to the file server i get incredibly (and
    >>> unacceptable) low data rates in the order of 600 bytes/sec! I use a
    >>> 10 Mb LAN, and the usual xfer rate between OpenBSD machines using SCP
    >>> or FTP is in the order of 1,000 Mbytes/sec. So, instead i started the
    >>> FTPD program on the OpenBSD file server, and used FTP on the OS/2
    >>> machine to do the xfer. The data rate for a 230 Mb disk image file
    >>> was 30 Kb/sec. This is a factor 30 or so lower than what the LAN and
    >>> the computers/NICs are capable of.
    >>>
    >>> What tuning parameters in the OS/2 environment should i suspect and
    >>> alter to improve the data xfer performance? Something is wrong for sure.

    >>
    >> Is your CPU tied up doing something else and the daemons on the OS/2
    >> side running at normal priority? Are you getting a large number of
    >> collisions on your network?

    > _____
    > Yes, many collisions, hence my question.


    Then it is very possible that you have a problem with duplexing. If using a
    dumb 10mb hub, supporting only half duplex, and your OS/2 system is using
    full duplex, then you will have many collisions, and very poor performance.

    I remember one time years ago where I had this problem. I didn't notice it
    when booting Windows 95 on the same box, but since OS/2 had much better
    multitasking, it showed up then. Locking all systems to half duplex fixed
    the problem.


+ Reply to Thread