Re: Destination z article: Ensuring Data Storage Longevity
Or archive a detailed printout of the data to answer any questions. On Mon, Oct 8, 2018 at 12:22 PM Steve Thompson 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 > > 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 > > robin...@sce.com > > > > > > -Original Message----- > > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > > Behalf Of Gabe Goldberg > > Sent: Sunday, October 07, 2018 6:11 PM > > To: IBM-MAIN@LISTSERV.UA.EDU > > 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 lists...@listserv.ua.edu 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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Destination z article: Ensuring Data Storage Longevity
We also have been informed by our records retention team that we are NOT to retain data past the legal retention period, even if the application teams/business teams would like to do so. If the data exists, you would be legally obliged to provide the data in the case of a legal dispute, if its purged no issues arise. Jerry Whitteridge Delivery Manager / Mainframe Architect GTS - Safeway Account 602 527 4871 Mobile jerry.whitteri...@ibm.com IBM Services IBM Mainframe Discussion List wrote on 10/08/2018 09:47:37 AM: > From: Jesse 1 Robinson > To: IBM-MAIN@LISTSERV.UA.EDU > Date: 10/08/2018 09:48 AM > Subject: Re: Destination z article: Ensuring Data Storage Longevity > Sent by: IBM Mainframe Discussion List > > 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 > robin...@sce.com > > > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU > ] On Behalf Of Gabe Goldberg > Sent: Sunday, October 07, 2018 6:11 PM > To: IBM-MAIN@LISTSERV.UA.EDU > 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 a detailed explanation of > why multiple backup copies—even cloud storage—don't constitute > archived data, see this Storage Switzerland blog: https:// > urldefense.proofpoint.com/v2/url? > u=https-3A__bit.ly_2DzoJrR=DwIGaQ=jf_iaSHvJObTbx- > siA1ZOg=0avyVTgpzBFlo1QAgHxCtqKtRE6Ldl_1M9tI2p7Kc8E=n5vEqYyQJdgVV6l7F06AIBuPQxWwDhb8wjgqk1BME4Q=4GZQNL_blbDWP7_a94lx8obHHyNp4tOypPAes6dodQo= > > INVALID URI REMOVED > u=http-3A__destinationz.org_Mainframe-2DSolution_Trends_Ensuring-2DData-2DStorage-2DLongevity=DwIGaQ=jf_iaSHvJObTbx- > siA1ZOg=0avyVTgpzBFlo1QAgHxCtqKtRE6Ldl_1M9tI2p7Kc8E=n5vEqYyQJdgVV6l7F06AIBuPQxWwDhb8wjgqk1BME4Q=96iPf4sjy2kN0Twtd8ec7tTUcm9cGXm3IHdp8n8leTM= > INVALID URI REMOVED > u=https-3A__bit.ly_2NiJVSS=DwIGaQ=jf_iaSHvJObTbx- > siA1ZOg=0avyVTgpzBFlo1QAgHxCtqKtRE6Ldl_1M9tI2p7Kc8E=n5vEqYyQJdgVV6l7F06AIBuPQxWwDhb8wjgqk1BME4Q=zl7GuQO8ctdbaBqQtx93EJOERBaBsHGgBEU2aksMinY= > > ...for non-technical folk reading this (it's going to diverse lists) > -- your data needs backup and archiving too. And backup still isn't archive. > > -- > Gabriel Goldberg, Computers and Publishing, Inc. g...@gabegold.com > 3401 Silver Maple Place, Falls Church, VA 22042 (703) 204-0433 > LinkedIn: INVALID URI REMOVED > u=http-3A__www.linkedin.com_in_gabegold=DwIGaQ=jf_iaSHvJObTbx- > siA1ZOg=0avyVTgpzBFlo1QAgHxCtqKtRE6Ldl_1M9tI2p7Kc8E=n5vEqYyQJdgVV6l7F06AIBuPQxWwDhb8wjgqk1BME4Q=OqDmH0BmTVL9r60Jckl6_jq60ERES5d8dP90xuJ2OqM= > Twitter: GabeG0 > > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Destination z article: Ensuring Data Storage Longevity
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 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 > robin...@sce.com > > > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > Behalf Of Gabe Goldberg > Sent: Sunday, October 07, 2018 6:11 PM > To: IBM-MAIN@LISTSERV.UA.EDU > 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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Destination z article: Ensuring Data Storage Longevity
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 robin...@sce.com -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Gabe Goldberg Sent: Sunday, October 07, 2018 6:11 PM To: IBM-MAIN@LISTSERV.UA.EDU 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 a detailed explanation of why multiple backup copies—even cloud storage—don't constitute archived data, see this Storage Switzerland blog: https://bit.ly/2DzoJrR http://destinationz.org/Mainframe-Solution/Trends/Ensuring-Data-Storage-Longevity https://bit.ly/2NiJVSS ...for non-technical folk reading this (it's going to diverse lists) -- your data needs backup and archiving too. And backup still isn't archive. -- Gabriel Goldberg, Computers and Publishing, Inc. g...@gabegold.com 3401 Silver Maple Place, Falls Church, VA 22042 (703) 204-0433 LinkedIn: http://www.linkedin.com/in/gabegoldTwitter: GabeG0 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
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 a detailed explanation of why multiple backup copies—even cloud storage—don't constitute archived data, see this Storage Switzerland blog: https://bit.ly/2DzoJrR http://destinationz.org/Mainframe-Solution/Trends/Ensuring-Data-Storage-Longevity https://bit.ly/2NiJVSS ...for non-technical folk reading this (it's going to diverse lists) -- your data needs backup and archiving too. And backup still isn't archive. -- Gabriel Goldberg, Computers and Publishing, Inc. g...@gabegold.com 3401 Silver Maple Place, Falls Church, VA 22042 (703) 204-0433 LinkedIn: http://www.linkedin.com/in/gabegoldTwitter: GabeG0 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
