David O'Brien posts: >The following has been posed by one of our mainframe users. >QUESTION: What options (if any) are available for migrating >these old study files and contents of accounts to storage media >such as DVDs and external hard drives that could be securely >held (off-line) by the agencies? >Looking at the user id provided I find that most of these files >are VSAM. >Is there any way to use VSAM in a non-mainframe environment? >Is there a way to write directly to a dvd from a mainframe?
There have been a lot of replies already, but I think there's also a lot of guessing going on. Let's not guess too much. The most reasonable question to ask at this point is "What business problem(s) are you trying to solve?" Without that context, it's difficult to answer these questions. To answer the questions to the degree possible for now: 1. There are myriad options for copying data. Mainframe-accessible data are also ones and zeros. Several copy methods have been mentioned, and I could probably come up with a dozen more. (IND$FILE? Kermit? :-)) What would you prefer? 2. Maybe there is a way to use VSAM (data) in a non-mainframe environment. The data are ones and zeros, regardless of platform. Interpreting the data is another question. What programs interpret and process the data today? How were those programs created, and how are they maintained? Is NIH's requirement to preserve the ability to run those programs upon demand for some period of time and to preserve the associated data for the same period of time? And to do that in a way that reliably reproduces original study results (and potential new results based on older data), with the integrity associated with careful medical research? For how long? Or are there some other (or additional) requirements? Is that an ongoing requirement for current and future studies, to have a computing infrastructure that supports long-term retention of data *and the ability to interpret those data*? That's exactly what mainframes are designed to do. There are programs written in the mid-1960s (and perhaps even earlier) that are still running today, still processing and interpreting their data. Medical research goes back at least that far, including groundbreaking studies on smoking and cancer (for example). This is something NIH really ought to be thinking about, carefully, and at senior levels. The central design premise of mainframes is "avoid breaking programs if at all possible." In contrast, our PCs (and Macs) break programs practically every year that passes. Archivists are warning that society is rushing headlong into creating a big "digital hole" in the historical record, because we simply won't be able to process and interpret older data (even if we have it) even a few years from now. Mainframes are a very notable exception, precisely because many businesses have the same requirements. Many insurance companies, for example, need to retain policies and the processing rules associated with those policies for 100 years or more (the lifetime of a life insurance policyholder and his/her heirs). Mainframes do that -- and support running brand new programs written 5 minutes ago. 3. Yes, actually. (There's at least one vendor that sells hardware to do that.) To what purpose? Many/most mainframes have tape available, often HSM-managed, which works beautifully for archiving programs and data -- and for managing the ability to carry those data forward for decades through technology changes, if that's the retention policy. (And I could see why that might be the retention policy for certain NIH programs and data. Cancer studies need to be long-running, for example. Same with research into chemicals that mimic hormones, which are very subtle and gradual but extremely serious, to pick another example.) If the business problem is "to save money," bear in mind that programs that don't run consume zero CPU and data stored on tape consumes (a part of) a tape. That's it. Mainframes are exceptionally talented at (centralized cloud) archiving, because that's what businesses (and governments) need to do quite often, and those are the systems they buy to do it. I'm hard pressed to think of another option that could be less expensive in the real world. If somebody is charging someone else within the same federal government a price that bears no relation to that reality, then that's the business problem to solve -- certainly for the sake of this taxpayer and millions of others. -------------------------------------------------------------------------------------------------------- Timothy Sipples Resident Enterprise Architect (Based in Singapore) E-Mail: timothy.sipp...@us.ibm.com ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
