Or archive a detailed printout of the data to answer any questions. On Mon, Oct 8, 2018 at 12:22 PM Steve Thompson <[email protected]> wrote: > > You have hit upon a checklist item when I am involved in a migration > (especially from one O/S environment to another). > > A sign off ensuring that management understands that should any archives be > needed from the “old database”, the new system will not be able to read or > process that data to produce any needed reports. > > If they need that data it must be migrated to the new system’s format and > tested to ensure the reports give the same answers as found on a prior > printed/captured report (prior to the time the migration was started). > > Steve Thompson > > Sent from my iPhone — small keyboarf, fat fungrs, stupd spell manglr. Expct > mistaks > > > > On Oct 8, 2018, at 7:47 PM, Jesse 1 Robinson <[email protected]> > > wrote: > > > > The distinction between backup and archive is useful. I'm not sure that '90 > > day usage' is the definitive boundary--we have scheduled year-end jobs that > > run only annually--but the categories make sense. However, it's not only > > about the data itself. Data is a structured mass of zeroes and ones that > > makes no sense at all without a means to render it intelligible. > > > > Some time ago, we (IT) was asked to restore very old data needed by the > > Finance department. The data was years old, but as responsible corporate > > caretakers we found the tapes that contained the information requested. The > > kicker: it was IMS data, and IMS had been decommissioned here years > > earlier. Even if we could somehow wangle a temporary copy of IMS, the > > process of installing it was daunting as none of us had relevant > > experience. Moreover, there was no guarantee that a 'modern' version of IMS > > would be able to untangle ancient data formats. Finance eventually let us > > off the hook, but it was a lesson that still haunts us. > > > > . > > . > > J.O.Skip Robinson > > Southern California Edison Company > > Electric Dragon Team Paddler > > SHARE MVS Program Co-Manager > > 323-715-0595 Mobile > > 626-543-6132 Office ⇐=== NEW > > [email protected] > > > > > > -----Original Message----- > > From: IBM Mainframe Discussion List [mailto:[email protected]] On > > Behalf Of Gabe Goldberg > > Sent: Sunday, October 07, 2018 6:11 PM > > To: [email protected] > > Subject: (External):Destination z article: Ensuring Data Storage Longevity > > > > Ensuring Data Storage Longevity > > > > Backup and Archival Data > > > > Data comes in many varieties, related to why it exists and how it's > > stored: active, warehouse, transactional, backup, archival and more. > > I'll skip over the first three forms and focus on backup data (briefly) and > > archival data (primarily). > > > > Because backup data recovers from human error, equipment failures and > > external catastrophes, its only reason for existing is restoring data to a > > recent image. Archival data may be needed for legal or industry compliance, > > historical recordkeeping, merger and acquisition due diligence, > > unanticipated queries/searches, or reconstructing operational environments. > > Backup data can be stored piecemeal as long as it can be completely > > restored. Archival data is holistic, a complete/consistent image. For > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to [email protected] with the message: INFO IBM-MAIN
-- Mike A Schwab, Springfield IL USA Where do Forest Rangers go to get away from it all? ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
