%MSMCVT is indeed the fastest way. %DSMCVT is the fastest way for a DSM conversion, and %DTMCVT for DTM conversions. Note that in all cases, these routines do not move the application routines, you have to export them separately, and import them using Cache Explorer.

If down time is a concern, it can be minimized by restoring a MSM/DSM/DTM backup on the Cache machine, converting them, and then applying the journal files since the backup to the Cache system. This is the way we converted the VA a while ago, and leaves the old system up and running until the last journal file is moved.

The key to this conversion is being able to read the MSM/DSM/DTM journal file, and to convert it to something Cache can read.

In 3.2 there are 2 updated routines, JCONVERT and %JREAD. JCONVERT will take a Cache journal file, and convert it to a flat text file which %JREAD can then read. You can take JCONVERT and modify it to run on an MSM/DSM/DTM system to create this flat text file, and then FTP the file to the Cache system where it can be read in by the %JREAD routine. Both of these routines are self documenting, including the flat file format, and are also documented in the 3.2 release notes. For help on reading the MSM/DSM/DTM journal files, you can look at each platforms journal restore routine. So the procedure would be as follows:

1. Set up necessary namespaces and mapping on the Cache system
2. Move the application routines from the old system to the Cache system
3. Turn on journaling on old system (probably journal ALL globals).
4. Take backup of old system.
5. Restore backup onto Cache system
6. Run the appropriate conversion routine (%MSMCVT/%DSMCVT/%DTMCVT)
7. Roll the journal file on the old system
8. Run the modified JCONVERT on the rolled over journal file
9. FTP the flat test journal file to the Cache system
10. Use %JREAD to restore the journal
11. Continue to roll, convert, and restore the old system journal files until you are caught up.
12. Turn off old system (get users off).
13. Convert and restore last journal
14. Run reports for data validation on old system
15. Bring up the new Cache system
16. Run reports for data validation on Cache system
17. Compare report results, and then let users on

One thing that this procedure can allow you to do is to move most of the data to the Cache system, and then start validating the application.

Depending on the speed of the machine/disks, and how compact the data is (running a compaction prior to the conversion will help), anywhere between 400mb and 2gb can be converted an hour. It helps to have the databases being converted on a separate disk and controller, and a large buffer pool (as big as you can make it).

Now, if a major catastrophe occurs (i.e. the application routines were not converted correctly), and you have to drop back to the old system, you can get there the following way.

1. Make sure that you are journaling all globals on the Cache system, and are keeping the journal files on line. Note that by default there is a 7 day purge cycle for journal files.
2. Get users off the Cache system
3. Run JCONVERT on the Cache journal files to convert them to a flat file format
4. FTP the journal files to the old system
5. Run the modified %JREAD to read the flat journal files into the old system
6. Turn off the Cache system, and turn on the old system.

Home | M Technologies | Support | Company | Contact

MOVE TO CACHÉ

© Copyright 1996-2000 InterSystems Corporation. All Rights Reserved.
email: wwwadmin@intersys.com