Archives of the TeradataForum

Message Posted: Mon, 12 Jul 2004 @ 17:51:30 GMT

	<Prev	Next>		<<First	<Prev	Next>	Last>>

Based on our experience, arcmain is a terrible tool for changing system versions. When we received new hardware (9/2003), we decided to spare the user community the pain of a V2R5 upgrade followed by a rehosting (or vice versa). So we dumped on V2R4 and loaded on V2R5 via MVS arcmain (can't speak to other platforms).

We ran into a lot of trouble with arcmain not liking certain table headers (we needed 2 patches before we were through), and the fact that join indexes can't be dumped at all (there's a DR). After the tables were loaded we had to run a V2R4 to V2R5 data conversion script to update table headers.

We've learned our lesson: we will *never again* use arcmain as part of a hardware rehost. We will upgrade in place on the old systems and then dump/restore at the same system levels. But this doesn't address the general upward compatibility issue of arcmain.

Once we were up and running, we spent the next six months restoring our long retention tapes (we have 3-year and 7-year long hold requirements) into our test system so we could run the conversion script and redump them at V2R5. We decided that this was better than running a V2R5 conversion script on a live production system after a restore. And besides, once we're on V2R9, how the heck are we going to locate the 4 intervening conversion scripts?

If you think this doesn't affect you, ask your legal department about Sarbanes-Oxley 7-year retention requirements for data (esp. financial). Consider: 7 years ago we had just gotten off our DBC1012 and were planning our V1R5 to V2R2 conversion. And we were still using round reels for some dumps (they're gone thank heavens).

How the heck are we supposed to read tapes from that era? Have you recopied your old tapes to new tapes to counter media deterioration? Do you have hardware that will read tapes from seven years ago? At that, we're luckier than the sites doing Unix dumps: they have two discontinued software products to deal with and I don't know how many drive types (we restored and redumped what little we had).

What we really need from the arcmain utility at this point is the ability to dump the tablename, a show table in clear text and the data. Arcmain (especially copy) needs to be able to run the create table and then load the data across a 10 year time span of system releases. This does not necessarily need to be the default mode, but for long retention it needs to be available as an option.

I suppose we could cobble together something out of fastexport/fastload, but the amount of record keeping is unappealing. We'd need a database to track the dumps of the database. And since NCR pushing Warehouse Builder as a sometime replacement for fastexport/fastload, how long would that last?

These problems are not unique to NCR, but we need to have NCR solutions for the NCR products.

david.a.hough

	<Prev	Next>		<<First	<Prev	Next>	Last>>