During the 7.2 -> 8.0 Applications upgrade cycle, Lawson introduced “Upgrade While Active” (at CUE 2003 I think…). This changed the upgrade process to reduce the downtime required to move the data from between application product lines as part of the upgrade.
The 8.0 -> 9.0 Applications were rewritten to use the Java-based sqldbcopy, and table data is copied between product lines/databases directly on the database server rather than the previously-used dump/load method. This, of course, speeds things up dramatically.
But still, there is significant downtime. Not all tables are direct copies (and even in that case I’ve seen some cases where these still take 12 hours or more). For tables which are converted rather than copied, Lawson has re-written those in Java. However, I’ve seen larger databases requiring an upgrade process that runs for 40+ hours. Which just begs for the “Upgrade While Active” process if you can’t afford to be down that long.
When I asked Lawson about using “Upgrade While Active” for the 9.0 Applications, their response was that, with the faster sqldbcopy and the re-writing of the upgrade programs in Java, they haven’t had a demand. However, they do claim that it’s still an available option.
Is anyone using it?
LawsonGuru.com Forums
LawsonGuru Blog 
I remember our 8.0 upgrade, it was very smooth and quick. I can only hope this remains true for 9.0.
OK John… please explain to me why “rewritten in Java” would imply any performance improvement. I mean, how would the language make any difference. I hear this kind of talk from these guys all the time and it just makes me laugh.
Sorry, I’m just quoting Lawson, as they attributed the “faster upgrade process” as the reason for not needing Upgrade While Active.
In my opinion, the sole performance improvement is that the copy programs now use sqldbcopy which utilizes the database to do the copying process.
I agree with you that “rewritten in Java” alone would have zero performance impact. The Java “load” programs still have roughly the same performance as their previous COBOL counterparts.
Thank you John… I was beginning to think it was me.
Why not? If you can use multi-threading using application program, which I dont think is possible in Cobol, it could speed up the conversion. And cobol has the issue of ‘taking-one-record-process-it-and take-next’ rather than select group of records and mass-update ’em.