Text 369, 96 rader
Skriven 2007-11-23 19:15:14 av Mike Luther (1:117/3001.0)
    Kommentar till text 364 av Herbert Rosenau (2:2476/493)
Ärende: Remote safe reboot
==========================
Thanks for the thought Herbert

 HR> Oh, eCS 1.2R gives you an easy way to migrate from 
 HR> WARP 4.0, 4.5, 4.51 or 4.52 to eCS. The only 
 HR> requirements to get it right are:
 HR> - clean os2.ini, os2.sys.ini
 HR>   wptool32.zip (HOBBES) helps you to get that
 HR> - a system partiton in size of 500 MB or bigger
 HR> - do NOT format the system partiton when the installer asks for
 HR>   That means to install over the old system. 

 HR> To be sure for success you'll make a backup of the system before you 
 HR> tries to do that. Thereafter you will simply copy/move 
 HR> the member of the "old desktop" you likes to hold in 
 HR> the new system to the place you likes they have to 
 HR> reside now and kill the folder thereafter.

 HR> When something fails you can easy restore the backup to make another try.

I'd like to investigate this part of your post.  I do understand the migration
process for moving a Warp 4 operation to Merlin Convenience Pack.  But per what
I found out the very hard way, as well as formally as a member of IBM's
TestCase in Austin, and also in comments with the eCs crew at the time, there
simply is *NO* safe way to migrate any Warp 4 OS/2 operation directly to eCs at
all for the very huge number of files and the complex desktop operations I had
in all my OS/2 Warp 4 operations.  And may face in yet other systems of others
which I really should move to MCP2 level code.

What I found out the hard way, IBM absolutely confirmed formally in both
TestCase as well as was released to the public, you should *NOT EVER* try to
migrate the hard drive operations directly from Warp 4 to MCP2. The migration
process, as well as the LVM conversion of the hard drive disk partitions can
*ONLY* be safely done as provided in Merlin Convenience Pack #1.  As was told
me, not only this was true, but IBM pulled and would not provide the LVM disk
migration utility from the MCP2 level distribution.  There were VERY serious
data loss issues that could, did and do erupt from trying this any other way
than MCP1 level upgrade path work.

Yes, that means I had to and did do two desktop migrations.  I first migrated
the whole systems to MCP1.  Then, as absolutely required by the error issues in
MCP1, I did and you really have to install Fix Pack #1 for MCP1 to solve some
serious problems there.

From there, you do a SECOND migration to MCP2.  Then do the whole desktop
migration a second time to MCP2 from MCP1.  Then you do a complete Fix Pack
update for the MCP2 code only AFTER you get the core stuff there at the MPTN,
PEER and TCP/IP fix levels needed.  Plus do the require audio support work and
so on for that as your final steps.

In doing this I was able to completely and SAFELY move all of the OS/2 work
which I had migrated first from OS/2 version 2, to OS/2 version 3,to Warp 4
through I think it was Fix Pack 15 at that time.

More important, at this point even after YEARS of service since migration, I
have never once had any stability issues for desktop operations and system
instability at all from the migration process. Not ever.

The absolute professional advice for all this was very specific.  It wasn't an
issue of eCs at all.  It was the fact that there was absolutely no safe way to
handle complex desktop and application migration directly to eCs.  Because the
migration tools and really needed technology could not be contained and
furnished in the eCs product as it even first was released.

OK ... that was quite a while ago.

Now .. what absolute proof and experience is there that migration of very
complex and huge file totals from Warp 4 can *SAFELY* be moved to eCs even as
to the version 1.24 that I, for example, do have, but have never been able to
take a chance to even install?

Precisely where is it documented by IBM and the crew that the LVM conversion
can be safely done for Warp4 and the MCP2 level which is eCs at this point?

I'd really like to know the complete professional documentation and text of the
discussion for this.  And it isn't a criticism of eCs at all as to the things
that are in eCs in the formal releases .. or .. the eCs test crew at all to
which I am speaking.  I just cannot afford to make an error in mission critical
work from which there is simply no way, to as you suggest:

 HR> When something fails you can easy restore the backup to make another try.


Thanks!


--> Sleep well; OS/2's still awake! ;)

Mike @ 1:117/3001






--- Maximus/2 3.01
 * Origin: Ziplog Public Port (1:117/3001)