Re: [EXTERNAL] Re: Bad backup stories (was: Re: Ransomware in VSAM and DB2)
It was an NCR 9050 mini, with 658 disk drives. 15 inch removable packs but I don't remember how many platters on them. IIRC they were actually manufactured by CDC. -Original Message- From: IBM Mainframe Discussion List On Behalf Of Seymour J Metz Sent: Monday, March 13, 2023 11:02 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: [EXTERNAL] Re: Bad backup stories (was: Re: Ransomware in VSAM and DB2) ? The BUNCH machine's I'm familiar with were somewhat earlier, and didn't have removable disks. What machine and drive was that? FWIW, I know something about all five but have only used CDC and UNIVAC, plus a dwarf not part of the BUNCH. -- Shmuel (Seymour J.) Metz https://urldefense.com/v3/__http://mason.gmu.edu/*smetz3__;fg!!KjMRP1Ixj6eLE0Fj!titHwWQzN6s4fDwJzbV_w5_RYDakrGPxwUUvRmmz8xtLUq2v7ycpF9EG1yCFC8lr2sSEsiF-TbO09xxofw$ From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of Pommier, Rex [rpomm...@sfgmembers.com] Sent: Monday, March 13, 2023 10:51 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: [EXTERNAL] Re: Bad backup stories (was: Re: Ransomware in VSAM and DB2) My turn. :-) BUNCH computer back in mid '80s. No tape on it so backups were removable disk to removable disk. Director was too cheap to spring for tape drives/media and also decided we didn't need to back up load modules because "if we lose one we can just recompile it". Part of a bigger disaster was that we lost the disk containing all of our load modules. Took a week to get the computer back up and running and all our programs recompiled. Did I mention this was a hospital? Rex -Original Message- From: IBM Mainframe Discussion List On Behalf Of Charles Mills Sent: Sunday, March 12, 2023 12:33 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: [EXTERNAL] Re: Bad backup stories (was: Re: Ransomware in VSAM and DB2) Gee, this is more of a nostalgia thread than most ... My very first programming job, the tape librarian quit. (Remember tape libraries and librarians and manual tape management?). Our boss was too cheap to hire a replacement with any overlap in employment dates. So the new woman started with no tape librarian experience. Everything seemed to be going well for a couple of weeks ... until it turned out that if she got a scratch request and could not find the volume -- perhaps it was lying on someone's desk or something like that -- she would scratch the closest match she *could* find. For example, if the scratch request was for VOLSER 274382 and she couldn't find it, she might scratch 274383 because it was the closest match she could find. Just trying to do the best job she could ... Charles -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- The information contained in this message is confidential, protected from disclosure and may be legally privileged. If the reader of this message is not the intended recipient or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any disclosure, distribution, copying, or any action taken or action omitted in reliance on it, is strictly prohibited and may be unlawful. If you have received this communication in error, please notify us immediately by replying to this message and destroy the material in its entirety, whether in electronic or hard copy format. Thank you. -- 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 -- The information contained in this message is confidential, protected from disclosure and may be legally privileged. If the reader of this message is not the intended recipient or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any disclosure, distribution, copying, or any action taken or action omitted in reliance on it, is strictly prohibited and may be unlawful. If you have received this communication in error, please notify us immediately by replying to this message and destroy the material in its entirety, whether in electronic or hard copy format. Thank you. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: [EXTERNAL] Re: Bad backup stories (was: Re: Ransomware in VSAM and DB2)
? The BUNCH machine's I'm familiar with were somewhat earlier, and didn't have removable disks. What machine and drive was that? FWIW, I know something about all five but have only used CDC and UNIVAC, plus a dwarf not part of the BUNCH. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of Pommier, Rex [rpomm...@sfgmembers.com] Sent: Monday, March 13, 2023 10:51 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: [EXTERNAL] Re: Bad backup stories (was: Re: Ransomware in VSAM and DB2) My turn. :-) BUNCH computer back in mid '80s. No tape on it so backups were removable disk to removable disk. Director was too cheap to spring for tape drives/media and also decided we didn't need to back up load modules because "if we lose one we can just recompile it". Part of a bigger disaster was that we lost the disk containing all of our load modules. Took a week to get the computer back up and running and all our programs recompiled. Did I mention this was a hospital? Rex -Original Message- From: IBM Mainframe Discussion List On Behalf Of Charles Mills Sent: Sunday, March 12, 2023 12:33 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: [EXTERNAL] Re: Bad backup stories (was: Re: Ransomware in VSAM and DB2) Gee, this is more of a nostalgia thread than most ... My very first programming job, the tape librarian quit. (Remember tape libraries and librarians and manual tape management?). Our boss was too cheap to hire a replacement with any overlap in employment dates. So the new woman started with no tape librarian experience. Everything seemed to be going well for a couple of weeks ... until it turned out that if she got a scratch request and could not find the volume -- perhaps it was lying on someone's desk or something like that -- she would scratch the closest match she *could* find. For example, if the scratch request was for VOLSER 274382 and she couldn't find it, she might scratch 274383 because it was the closest match she could find. Just trying to do the best job she could ... Charles -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- The information contained in this message is confidential, protected from disclosure and may be legally privileged. If the reader of this message is not the intended recipient or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any disclosure, distribution, copying, or any action taken or action omitted in reliance on it, is strictly prohibited and may be unlawful. If you have received this communication in error, please notify us immediately by replying to this message and destroy the material in its entirety, whether in electronic or hard copy format. Thank you. -- 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: [EXTERNAL] Re: Bad backup stories (was: Re: Ransomware in VSAM and DB2)
My turn. :-) BUNCH computer back in mid '80s. No tape on it so backups were removable disk to removable disk. Director was too cheap to spring for tape drives/media and also decided we didn't need to back up load modules because "if we lose one we can just recompile it". Part of a bigger disaster was that we lost the disk containing all of our load modules. Took a week to get the computer back up and running and all our programs recompiled. Did I mention this was a hospital? Rex -Original Message- From: IBM Mainframe Discussion List On Behalf Of Charles Mills Sent: Sunday, March 12, 2023 12:33 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: [EXTERNAL] Re: Bad backup stories (was: Re: Ransomware in VSAM and DB2) Gee, this is more of a nostalgia thread than most ... My very first programming job, the tape librarian quit. (Remember tape libraries and librarians and manual tape management?). Our boss was too cheap to hire a replacement with any overlap in employment dates. So the new woman started with no tape librarian experience. Everything seemed to be going well for a couple of weeks ... until it turned out that if she got a scratch request and could not find the volume -- perhaps it was lying on someone's desk or something like that -- she would scratch the closest match she *could* find. For example, if the scratch request was for VOLSER 274382 and she couldn't find it, she might scratch 274383 because it was the closest match she could find. Just trying to do the best job she could ... Charles -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- The information contained in this message is confidential, protected from disclosure and may be legally privileged. If the reader of this message is not the intended recipient or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any disclosure, distribution, copying, or any action taken or action omitted in reliance on it, is strictly prohibited and may be unlawful. If you have received this communication in error, please notify us immediately by replying to this message and destroy the material in its entirety, whether in electronic or hard copy format. Thank you. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Bad backup stories (was: Re: Ransomware in VSAM and DB2)
1981 - dual 370/168s MP'ed together. A sysprog coworker applied maintenance to AbendAid, then left town for the weekend. Turns out he linked RTM in the nucleus incorrectly and the scheduled Sunday night IPL failed with a disabled wait state. We can't find the FDR/SAR tape backup of the sysres. Tried to IPL SAR from the card reader with a punched card deck, that failed. Now we are getting desperate; it's 2AM Monday morning. We talked our IBM CE into removing the HDA from the 3350 sysres and we take it across town to a friendly MVS shop. He removed the HDA from one of their 3350s, installs our HDA and we fix the problem there, then he deinstalls our HDA, we take it back to our shop, reinstall it in our 3350, then IPL just in time for CICS to come up at 6AM. A very bad night. Mike Shaw QuickRef Support Chisoft On Sun, Mar 12, 2023, 1:33 PM Charles Mills wrote: > Gee, this is more of a nostalgia thread than most ... > > My very first programming job, the tape librarian quit. (Remember tape > libraries and librarians and manual tape management?). Our boss was too > cheap to hire a replacement with any overlap in employment dates. So the > new woman started with no tape librarian experience. Everything seemed to > be going well for a couple of weeks ... until it turned out that if she got > a scratch request and could not find the volume -- perhaps it was lying on > someone's desk or something like that -- she would scratch the closest > match she *could* find. For example, if the scratch request was for VOLSER > 274382 and she couldn't find it, she might scratch 274383 because it was > the closest match she could find. Just trying to do the best job she could > ... > > Charles > > -- > 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: Bad backup stories (was: Re: Ransomware in VSAM and DB2)
Gee, this is more of a nostalgia thread than most ... My very first programming job, the tape librarian quit. (Remember tape libraries and librarians and manual tape management?). Our boss was too cheap to hire a replacement with any overlap in employment dates. So the new woman started with no tape librarian experience. Everything seemed to be going well for a couple of weeks ... until it turned out that if she got a scratch request and could not find the volume -- perhaps it was lying on someone's desk or something like that -- she would scratch the closest match she *could* find. For example, if the scratch request was for VOLSER 274382 and she couldn't find it, she might scratch 274383 because it was the closest match she could find. Just trying to do the best job she could ... Charles -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Bad backup stories (was: Re: Ransomware in VSAM and DB2)
Hi Phil, Since you asked for bad backup stories ... In the mid '80s, I was working at the Canadian head office of a multinational food company. We were using 6250 BPI Tapes on STK 4520 drives. My boss, who also managed operations, decided that when tapes would get physical errors, the operator should cut off 10 feet and place a new silver strip on the tape. It got to a point where many 2400 foot reels (from a not high quality tape vendor) had maybe 300 feet left. A lot off these tapes were minimum 10 years old. One Wednesday night, as I was suiting up to play my weekly ice hockey game, the pager goes off. I went to a payphone and called operations. They told me that the ADABAS backup failed and that they had no Database for Production. (Needless to say, I wasn't happy to miss my weekly exercise.) I took off my gear and drove to the office. When I got there, I looked at job log and realized that the Backup Batch Job would copy the Database offload to tape, DELETE the Database, DEFINE a New Database and then reload the backup to DASD, effectively doing a REORG. This time, however, the backup to tape failed, the Database was deleted and, of course, my colleague the genius SysProg hadn't bothered checking Condition Codes before the next Step began. I spent all night recovering the Database (unloaded to tape) via FATAR (an amazing software product). Before I left, I wrote a scathing email (PROFS actually) to my director complaining about my jack@$$ boss who was the poster boy for "Penny Wise and Pound Foolish". My idiot boss then called in STK to prove that the EREP/LOGREC Data for tape failures per million I/Os was well within the national tolerance. He was partially correct, if we would allow data from one of our not-too-smart provinces. Regards, David On 2023-03-11 19:44, Phil Smith III wrote: Since we're swapping bad backup stories. I'm at a small mainframe vendor, mid-90s. Data center manager quits with no notice because boy genius sociopath CFO tell him at the last minute that he can't take long-planned, prepaid vacation trip because CFO wants him there for something stupid. This was not just a fit of pique-it was the final straw in a large bale. His sidekick takes over, proves himself to be a junior sociopath. While he's out of town, Senior VP of Marketing wants DNS redirected to actual web page instead of static page we'd been hosting on VM/ESA in lieu of having a real site. This is before cellphones, so I have no way to reach junior sociopath. I was running our DNS (we were the ONLY site on the planet running a primary DNS on VM at the time, as proven by our discovering that IBM had implemented their DNS server in strict accordance with the RFCs, meaning name service broke when a secondary pulled from it), so I make the change, send sociopath email. He gets back and is pissed that he "wasn't consulted" (as if he was going to buck the Sr. VP). He pulls my system privileges, which I need to, like, do my job, which includes supporting ~40% of our revenue. That leads to a confrontation with our mutual manager: "Put them back." "No." "PUT. THEM. BACK." "No. I'll walk out that door first." "OK, bye." So now he's gone. We tell boy genius CFO "Somebody needs to take this over"; he's smarter than everyone else, doesn't see the need. Few weeks later, day or two before Christmas, I get a call from a cow-orker. "We lost an HDA, and boy genius hasn't had anyone doing backups, so the newest one is months old". He then runs through a list of minidisks we've lost, which are all noise except the last one in his list (just as I was calming down!), which included a fix I'd finished a few days before that had taken months to develop. Fortunately it was about 99% faster to rewrite, since I knew what the problem was. No, boy genius didn't get fired or even get his wrist slapped. CEO was equally clueless. I sometimes wonder how these people wind up in a business they don't begin to understand. And before someone says "You should have been running backups anyway", no: we had warned repeatedly and didn't have access to do so. We knew the main source code was backed up, so it was just service like my fix that was at risk. And of course this was long before mainframe use of git or anything like that, at least at our ~50-person company-fixes written on 3270s, so not even a backup on PC. I think after that, though, I started downloading difficult fixes so I wouldn't have to recreate them. That was also the company where I owned some small number of shares of stock, because my wife (whom I met there-she had retired by then) had been granted some in the early days. That meant I was the only employee besides the executives who would show up for stockholder meetings, which they HATED because it limited their ability to lie to the other investors, knowing that I was willing to say "Gosh, sir, you must have forgotten/been misinformed/be lying through your teeth."
Re: Bad backup stories (was: Re: Ransomware in VSAM and DB2)
Anything I write for a client, I take a backup home, even though some HR folks may consider that a violation of confidentiality or copyright or something so I don't ever do it and I never said I did and anyway you can't prove nuthin'. But if it gets destroyed at work, let me know; I have a very good memory and may be able to recall every line verbatim. --- Bob Bridges, robhbrid...@gmail.com, cell 336 382-7313 /* In no way can your enemy hurt you by his violence as much as you hurt yourself if you don't love himIf he had no ill, he would not even be your enemy. Wish him well, then, that he may end his ill, and he will be your enemy no longer. -St Augustine (354-430) */ -Original Message- From: IBM Mainframe Discussion List On Behalf Of Phil Smith III Sent: Saturday, March 11, 2023 19:45 I'm at a small mainframe vendor, mid-90s. Data center manager quits with no notice because boy genius sociopath CFO tell him at the last minute that he can't take long-planned, prepaid vacation trip because CFO wants him there for something stupid. This was not just a fit of pique-it was the final straw in a large bale. His sidekick takes over, proves himself to be a junior sociopath. While he's out of town, Senior VP of Marketing wants DNS redirected to actual web page instead of static page we'd been hosting on VM/ESA in lieu of having a real site. This is before cellphones, so I have no way to reach junior sociopath. I was running our DNS (we were the ONLY site on the planet running a primary DNS on VM at the time, as proven by our discovering that IBM had implemented their DNS server in strict accordance with the RFCs, meaning name service broke when a secondary pulled from it), so I make the change, send sociopath email. He gets back and is pissed that he "wasn't consulted" (as if he was going to buck the Sr. VP). He pulls my system privileges, which I need to, like, do my job, which includes supporting ~40% of our revenue. That leads to a confrontation with our mutual manager: "Put them back." "No." "PUT. THEM. BACK." "No. I'll walk out that door first." "OK, bye." So now he's gone. We tell boy genius CFO "Somebody needs to take this over"; he's smarter than everyone else, doesn't see the need. Few weeks later, day or two before Christmas, I get a call from a cow-orker. "We lost an HDA, and boy genius hasn't had anyone doing backups, so the newest one is months old". He then runs through a list of minidisks we've lost, which are all noise except the last one in his list (just as I was calming down!), which included a fix I'd finished a few days before that had taken months to develop. Fortunately it was about 99% faster to rewrite, since I knew what the problem was. No, boy genius didn't get fired or even get his wrist slapped. CEO was equally clueless. I sometimes wonder how these people wind up in a business they don't begin to understand. And before someone says "You should have been running backups anyway", no: we had warned repeatedly and didn't have access to do so. We knew the main source code was backed up, so it was just service like my fix that was at risk. And of course this was long before mainframe use of git or anything like that, at least at our ~50-person company-fixes written on 3270s, so not even a backup on PC. I think after that, though, I started downloading difficult fixes so I wouldn't have to recreate them. That was also the company where I owned some small number of shares of stock, because my wife (whom I met there-she had retired by then) had been granted some in the early days. That meant I was the only employee besides the executives who would show up for stockholder meetings, which they HATED because it limited their ability to lie to the other investors, knowing that I was willing to say "Gosh, sir, you must have forgotten/been misinformed/be lying through your teeth." -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Bad backup stories (was: Re: Ransomware in VSAM and DB2)
Since we're swapping bad backup stories. I'm at a small mainframe vendor, mid-90s. Data center manager quits with no notice because boy genius sociopath CFO tell him at the last minute that he can't take long-planned, prepaid vacation trip because CFO wants him there for something stupid. This was not just a fit of pique-it was the final straw in a large bale. His sidekick takes over, proves himself to be a junior sociopath. While he's out of town, Senior VP of Marketing wants DNS redirected to actual web page instead of static page we'd been hosting on VM/ESA in lieu of having a real site. This is before cellphones, so I have no way to reach junior sociopath. I was running our DNS (we were the ONLY site on the planet running a primary DNS on VM at the time, as proven by our discovering that IBM had implemented their DNS server in strict accordance with the RFCs, meaning name service broke when a secondary pulled from it), so I make the change, send sociopath email. He gets back and is pissed that he "wasn't consulted" (as if he was going to buck the Sr. VP). He pulls my system privileges, which I need to, like, do my job, which includes supporting ~40% of our revenue. That leads to a confrontation with our mutual manager: "Put them back." "No." "PUT. THEM. BACK." "No. I'll walk out that door first." "OK, bye." So now he's gone. We tell boy genius CFO "Somebody needs to take this over"; he's smarter than everyone else, doesn't see the need. Few weeks later, day or two before Christmas, I get a call from a cow-orker. "We lost an HDA, and boy genius hasn't had anyone doing backups, so the newest one is months old". He then runs through a list of minidisks we've lost, which are all noise except the last one in his list (just as I was calming down!), which included a fix I'd finished a few days before that had taken months to develop. Fortunately it was about 99% faster to rewrite, since I knew what the problem was. No, boy genius didn't get fired or even get his wrist slapped. CEO was equally clueless. I sometimes wonder how these people wind up in a business they don't begin to understand. And before someone says "You should have been running backups anyway", no: we had warned repeatedly and didn't have access to do so. We knew the main source code was backed up, so it was just service like my fix that was at risk. And of course this was long before mainframe use of git or anything like that, at least at our ~50-person company-fixes written on 3270s, so not even a backup on PC. I think after that, though, I started downloading difficult fixes so I wouldn't have to recreate them. That was also the company where I owned some small number of shares of stock, because my wife (whom I met there-she had retired by then) had been granted some in the early days. That meant I was the only employee besides the executives who would show up for stockholder meetings, which they HATED because it limited their ability to lie to the other investors, knowing that I was willing to say "Gosh, sir, you must have forgotten/been misinformed/be lying through your teeth." Good times. Share your stories. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
