Subj : Remote safe reboot To : Herbert Rosenau From : Mike Luther Date : Fri Nov 23 2007 07:15 pm 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) .