Subj : Remote safe reboot
To   : Mike Luther
From : Herbert Rosenau
Date : Sat Nov 24 2007 01:55 pm

Am 23.11.07 19:15 schrieb Mike Luther

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

The differnce is that we do NOT migrate to MCP! We migrate to eCS. This is NOT 
the way IBM had done! The migration to eCS 1.2 is written by mensys to avoid 
the mistakes IBM had done in theyr migration path.

Yes, it is possible that the migration can fail - for that you would archive 
the complete system and restore the system from the archive when the migration 
fails. Sou you have always another chance to go on without loosing a bit of 
data.


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

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

There is nothing documented by IBM what eCS does to get the migration from 
WARP4 to eCS (not MCP!) because IBM knows nothing about the eCS migration path. 
Yes, eCS is based on MCP but far from identical.

Yes the way eCS 1.2 does the migration from WARP4 is absolutely different than 
in eCS 1.0 and eCS 1.1. This path is rewritten from scratch to avoid all the 
flaws.

The requirements for migration are clear:
- clean up OS2.INI and OS2SYS.INI bevore any try,
  because 99% of all problems are resulted in
  unclean INIs.

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

The migration to the current eCS ends up with
- a clean new desktop
- a new folder containing the whole OLD desktop
  ready to move anything needed from there
  to the location the user wants it to have now.

After the user has done the last step of moving anything of interest to its 
place the old desktop can easy removed from the desktop because nothing is left 
except of things with a bit of interest. Another cleanup of the INIs thereafter 
will increase the system stabilitiy but is not a requirement.

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


Yeah, the backup is a requirement for security only. That is set because there 
are uncountable variations a long time used owns the migration can fail on. 
Having a complete backup of an System gives always a secure way to go back to 
start and restart from begin. Again, I'M not willing to speak about migration 
to MCP - but migrating to eCS. These are 2 completely defferent pairs of boots. 
Again: eCS is NOT MCP and MCP is NOT eCS. Even as eCS uses MCP2 as root.

The differences between a new install and a migration to eCS are
- a new install starts with an empty volume
- a migration makes a backup of the INIs it findsand
  - removes outdated components from disk
    and lefts anythin not system related untouched
  - copies anything over from CD
  - recreates the old desktop into a separate folder
    on the new desktop.

Again: the new installed system is not MCP, it is eCS.

--- Sqed/32 1.15/development  978:
 * Origin: Lieber Kies in der Tasche, als Sand im Getriebe ! (2:2476/493)

.