Hi,
unload tility is used for taking a backup of a TABLE INTO A FLAT FILE.
LOAD UTILITY IS FOR LOADING A FLAT FILE RECORDS INTO A TABLE.
UNLOAD UTILITY::
//SYSREC00 DD DSN=NUUST.IMR.RTRV.DATA,-DISP=(NEW,CATLG,DELETE)
--THIS IS THE PS WHERE THE BACKUP'LL B STORED
//
//SYSIN DD *
SELECT * FROM TABLENAME;
//
hi all,
Load is to upload data into a table. (Restore process)
Unload is to download data into a table.(Backup process)
Please do revert it back if i'm wrong.
The basic concepts load and unload comes when you wnat to production data in the test ernvironment where we do our all the research work ..In the load process we unload all the productiond data into a samf file.... In the Load process we will be loading the data from the SAMF files to the test region database..
While loading the database we will load the parent table first and child tables in order maintain the referntial integrity...There are more concepts like Check Pending,Copy Pending,RunStats,Reorg Concepts related to this Unload and Load concepts..Please read this form the book..Feel Free to raise the doubts..As so many people are waiting to know variety of questions and so many people are there to answer as well
..
Cheers,
Jag.
Email: ***EMail ID REMOVED... Read Forum Rules***
While unloading Production data into sequential files, is there an option to mask some sensitive columns and then unload them onto sequential files? As Production database contains customer sensitive information, masking becomes absolutely necessary. Any ideas? Also, is there a way to unload only selected rows from tables. I think there is one but I dont know the exact method. Thanks...
Joined: 23 Nov 2006 Posts: 19244 Location: Inside the Matrix
Hello,
For this
Quote:
As Production database contains customer sensitive information, masking becomes absolutely necessary. Any ideas? Also, is there a way to unload only selected rows from tables.
you might create an additional table or simply write your own program to create a file of exactly what you want - both rows and content.
Even if you found a way to "work around" the issue, at some point, the scope of the requirement might expand and you'd need to write the code then anyway. If you write the code, you have complete control and will not waste resources for special purpose tables that are not needed for other than a work-around.