October 23, 2016 at 9:57 pm
Comments posted to this topic are about the item Clownpocalypse and DR
"The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood"
- Theodore Roosevelt
Author of:
SQL Server Execution Plans
SQL Server Query Performance Tuning
October 23, 2016 at 11:06 pm
The difference between Zombies and Clowns is simple. Zombies are external sources. Clowns are internal. 😉
--Jeff Moden
Change is inevitable... Change for the better is not.
October 24, 2016 at 1:30 am
Grant - its likely to be Solar EMP rather than Solar Radiation - look up carrington event.
.. and the Sun HAS been behaving in an unpredictable manner this Solar cycle :blink:
October 24, 2016 at 4:00 am
"Zombies" are the "code word" for fear of desperate fellow citizens/looters after civil order breaks down. Like good admins with backups and tested restores, there's a plethora of folks preparing for more than just a SAN outage or bad SQL code. Especially in "2016"...
"Yard work" is the code phrase for spending a good chunk of the weekend preparing for "zombies". Some of us might be sore on Monday from "cutting the grass" or "trimming the hedges".
😛
October 24, 2016 at 5:05 am
Totally agree with the editorial. Being prepare for disasters means that it is more likely that the disaster suffered will match one of the ones prepared for.
Totally enjoyed the Clowns v Zombies metaphore...perhaps a little too topical for some at the moment.
Gaz
-- Stop your grinnin' and drop your linen...they're everywhere!!!
October 24, 2016 at 8:50 am
I'm old enough to have been working in the IT field during the whole Y2K "event". Major decisions were put off because of it. A lot of work preparing DR plans was done. (And that was a good thing.) But at the end of the day our systems were fine because we didn't save date/time data in text fields using YYMMDD format. Instead we depended upon our vendors (in our case, Microsoft) getting it right in their databases and applications. And we just made sure that we were up to date in everything. It was an awful lot of hype, but it was just largely hype. I remember hearing a week or so after Y2K that some military systems experienced at outage (and was kept very secret), but for the most part it was a non-event. I do think that perhaps it was a non-event in large part because so many IT folks took it seriously and fixed potential problems in their systems.
Kindest Regards, Rod Connect with me on LinkedIn.
October 24, 2016 at 11:18 am
Great article. We're much more likely to be done in by ignorance and apathy than a savvy attack or meteor strike.
October 24, 2016 at 3:23 pm
Rod at work (10/24/2016)
I'm old enough to have been working in the IT field during the whole Y2K "event". Major decisions were put off because of it. A lot of work preparing DR plans was done. (And that was a good thing.) But at the end of the day our systems were fine because we didn't save date/time data in text fields using YYMMDD format. Instead we depended upon our vendors (in our case, Microsoft) getting it right in their databases and applications. And we just made sure that we were up to date in everything. It was an awful lot of hype, but it was just largely hype. I remember hearing a week or so after Y2K that some military systems experienced at outage (and was kept very secret), but for the most part it was a non-event. I do think that perhaps it was a non-event in large part because so many IT folks took it seriously and fixed potential problems in their systems.
Heh... I'm old enough to say that I first starting writing Y2K compatible code in 1976, which is also when I first started writing real deployable code. When 1999 came along, I had to fill out paper work to answer the PUC for 48 of the 50 states because I worked in the telephone business in 1999. One of the questions that they asked on each form (and you couldn't just staple a rote answer to the forms) was "What have you spent the most time on in your preparations for Y2K"? My answer was "Filling out these stupid forms".
As you say, except for filling out form after bloody form, it was a non-event for us.
--Jeff Moden
Change is inevitable... Change for the better is not.
October 25, 2016 at 5:45 am
Jeff Moden (10/24/2016)
Rod at work (10/24/2016)
I'm old enough to have been working in the IT field during the whole Y2K "event". Major decisions were put off because of it. A lot of work preparing DR plans was done. (And that was a good thing.) But at the end of the day our systems were fine because we didn't save date/time data in text fields using YYMMDD format. Instead we depended upon our vendors (in our case, Microsoft) getting it right in their databases and applications. And we just made sure that we were up to date in everything. It was an awful lot of hype, but it was just largely hype. I remember hearing a week or so after Y2K that some military systems experienced at outage (and was kept very secret), but for the most part it was a non-event. I do think that perhaps it was a non-event in large part because so many IT folks took it seriously and fixed potential problems in their systems.Heh... I'm old enough to say that I first starting writing Y2K compatible code in 1976, which is also when I first started writing real deployable code. When 1999 came along, I had to fill out paper work to answer the PUC for 48 of the 50 states because I worked in the telephone business in 1999. One of the questions that they asked on each form (and you couldn't just staple a rote answer to the forms) was "What have you spent the most time on in your preparations for Y2K"? My answer was "Filling out these stupid forms".
As you say, except for filling out form after bloody form, it was a non-event for us.
Whilst many systems were geared up for it, many weren't. It is a credit to our industry that Y2K ended up a damp squib. It wasn't because that there wasn't an issue, it was because by Y2K there was no longer an issue.
On the other hand, we did create it ourselves.1
1 Ourselves as an industry. Not necessarily anyone here. Old enough to have had the opportunity, smart enough to have passed it by. :satisfied:
Gaz
-- Stop your grinnin' and drop your linen...they're everywhere!!!
October 25, 2016 at 5:55 am
Gary Varga (10/25/2016)
Jeff Moden (10/24/2016)
Rod at work (10/24/2016)
I'm old enough to have been working in the IT field during the whole Y2K "event". Major decisions were put off because of it. A lot of work preparing DR plans was done. (And that was a good thing.) But at the end of the day our systems were fine because we didn't save date/time data in text fields using YYMMDD format. Instead we depended upon our vendors (in our case, Microsoft) getting it right in their databases and applications. And we just made sure that we were up to date in everything. It was an awful lot of hype, but it was just largely hype. I remember hearing a week or so after Y2K that some military systems experienced at outage (and was kept very secret), but for the most part it was a non-event. I do think that perhaps it was a non-event in large part because so many IT folks took it seriously and fixed potential problems in their systems.Heh... I'm old enough to say that I first starting writing Y2K compatible code in 1976, which is also when I first started writing real deployable code. When 1999 came along, I had to fill out paper work to answer the PUC for 48 of the 50 states because I worked in the telephone business in 1999. One of the questions that they asked on each form (and you couldn't just staple a rote answer to the forms) was "What have you spent the most time on in your preparations for Y2K"? My answer was "Filling out these stupid forms".
As you say, except for filling out form after bloody form, it was a non-event for us.
Whilst many systems were geared up for it, many weren't. It is a credit to our industry that Y2K ended up a damp squib. It wasn't because that there wasn't an issue, it was because by Y2K there was no longer an issue.
On the other hand, we did create it ourselves.1
1 Ourselves as an industry. Not necessarily anyone here. Old enough to have had the opportunity, smart enough to have passed it by. :satisfied:
I was also in telecoms for Y2K. As you say it was basically a non-event. The only issue I encountered was a couple of years later when I worked for a ‘billing/call logging’ company who had issues with a client who had refused to have his PABX upgraded for Y2K as it was a chargeable and not free upgrade. This resulted in a century old data and the need to patch code!
As regards zombies I read something a few years ago that the concept arose in the eighteenth/nineteenth century. People with serious mental conditions, including dementia that was not recognised at the time, were often locked away. The care they received varied with what their families could afford to pay. With poor families this was nothing and the poor wretches had an awful existence. Neglect and minimal self-care meant they often had rotting teeth, sores and often worse. Sometimes they escaped but in their confused state others were terrified of them. There was no mention of how the term 'zombie' came about.
There were some issues in my area a week or so ago with numerous reports of sightings. This seemed to die down after one clown had to flee a gang of teenagers who decided to grab a clown after being jumped!
October 25, 2016 at 7:17 am
I still hope I never have to see either apocalypse.
October 25, 2016 at 7:32 am
Iwas Bornready (10/25/2016)
I still hope I never have to see either apocalypse.
Agreed, but especially the clown one.
"The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood"
- Theodore Roosevelt
Author of:
SQL Server Execution Plans
SQL Server Query Performance Tuning
October 25, 2016 at 7:36 am
Gary - the two digit year was born out if the need to conserve memory in early systems - back in the late 70s /early 80s memory was expensive and every byte counted (anyone remember 77 levels in Cobol? ) so while we (the industry) "did it to ourselves" there was a goo reason for it
October 25, 2016 at 7:47 am
Geoff.Sturdy (10/25/2016)
Gary - the two digit year was born out if the need to conserve memory in early systems - back in the late 70s /early 80s memory was expensive and every byte counted (anyone remember 77 levels in Cobol? ) so while we (the industry) "did it to ourselves" there was a goo reason for it
A reason but arguable either way. We had this discussion at college (17-18 year olds) with a lecturer in the late 1980s. The greneral consensus was that the risk coupled with the inevitable cost of resolving would likely prove more unsavoury than the cost of a four digit year. That was before the inflated costs of "Y2K Consultants" was even imagined.
The real embarrassment are those tales of people creating programs utilising two digit years alongside those working on a Y2K project.
Gaz
-- Stop your grinnin' and drop your linen...they're everywhere!!!
October 25, 2016 at 8:06 am
Gary Varga (10/25/2016)
Geoff.Sturdy (10/25/2016)
Gary - the two digit year was born out if the need to conserve memory in early systems - back in the late 70s /early 80s memory was expensive and every byte counted (anyone remember 77 levels in Cobol? ) so while we (the industry) "did it to ourselves" there was a goo reason for itA reason but arguable either way. We had this discussion at college (17-18 year olds) with a lecturer in the late 1980s. The greneral consensus was that the risk coupled with the inevitable cost of resolving would likely prove more unsavoury than the cost of a four digit year. That was before the inflated costs of "Y2K Consultants" was even imagined.
The real embarrassment are those tales of people creating programs utilising two digit years alongside those working on a Y2K project.
Another embarrassment is that many of those "Y2K Consultants" were nothing more than programmers who had themselves been coding two digit year databases and application only 1 year before. They simply put on a $300 suit and began dispensing sage advice for twice the rate.
"Do not seek to follow in the footsteps of the wise. Instead, seek what they sought." - Matsuo Basho
Viewing 15 posts - 1 through 15 (of 42 total)
You must be logged in to reply to this topic. Login to reply