I think I'm in agreement with John McKown. If DB2 is where you're headed, then start heading. Of the options you list VSAM Transparency is the one that'll start you heading. Use it "as appropriate, appropriately."
Yes, OK, you'll probably have a longer path length than for VSAM, and that's something to be aware of but weigh against the functional benefits. Also, you probably don't just want to "slam in" whatever record layout you currently have into DB2 without thinking a bit. I suggest thinking about the way you want DB2 to look first -- what you want your ideal database to look like -- then make compromises only to the extent you absolutely have to (if at all). It's nice having a clean data model, at least at some point in time. Keep database I/O code well segregated (i.e. standard good programming practices for modularity) if you're going to start doing any coding. There are some discovery and analysis tools on the market if you need investigation of the current code (and if you're going to do any coding). Coding (and testing and debugging) is probably the most expensive task in all of IT, so it's almost always worth getting a reasonable collection of labor-saving tools, at least in most parts of the world. - - - - - Timothy Sipples IBM Consulting Enterprise Software Architect Specializing in Software Architectures Related to System z Based in Tokyo, Serving IBM Japan and IBM Asia-Pacific E-Mail: [EMAIL PROTECTED] ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
