Inbound and Outbound to NYC

I still recall the first computer program I wrote. Or rather co-wrote. It was a rather simple program, in Fortran I believe, though that’s really an educated guess. I don’t have a copy of it. It was either in 7th or 8th grade when several of us were given an opportunity to go down to the local high-school and learn a bit about the computer that they had there. I honestly have NO idea what kind of computer it was, perhaps a PDP-9 or PDP-11. We were asked for ideas on what to program and the instructor quickly ruled out our suggestion of printing all numbers from 1 to 1 Million. He made us estimate how much paper that would take.

So instead we wrote a program to convert temperature Fahrenheit to Celsius. The program was as I recall a few feet long. “A few feet long? What are you talking about Greg?” No, this was not the printout. This wasn’t how much it scrolled on the screen. Instead it was the length of the yellow (as I recall) paper tape that contained it. The paper tape had holes punched into it that could be read by a reader. You’d write your program on one machine, and then take it over to the computer and feed it into the reader and it would run it. I honestly don’t recall how we entered the values to be converted, if it was already on the tape or through some other interface. In any case, I loved it and fell in love with computers then. Unfortunately, somewhere over the years, that paper tape has since disappeared. That saddens me. It’s a memento I wish I still had it.

In four or five short years, the world was changing and quickly. The IBM PC had been released while I was in high school and I went from playing a text adventure game called CIA on a TRS-80 Model II to programming in UCSD Pascal on an original IBM PC. (I should note that this was my first encounter with the concept of a virtual machine and p-code machine.) This was great, but I still wanted more. Somewhere along the line I encountered a copy of Microsoft’s Flight Simulator. I loved it. In January of 1985 my dad took me on a vacation to St. Croix USVI. Our first step on that trip was a night in NYC before we caught our flight the next morning. To kill some time I stepped into 47th Street Photo and bought myself a copy of Flight Simulator. It was the first software I ever bought with my own money. (My best friend Peter Goodrich and I had previously acquired a legal copy of DOS 2.0, but “shared” it. Ok, not entirely legal, but hey, we were young.)

I still have the receipt.

For a High School Student in the 80s, this wasn’t cheap. But it was worth it!

I was reminded of this the other day when talking with some old buddies that I had met when the Usenet sci.space.policy was still the place to go for the latest and greatest discussions on space programs. We were discussing our early intro to computers and the like.

I haven’t played this version in years, and honestly, am not entirely sure I have the hardware any more that could. For one thing, this version as I recall was designed around the 4.77Mhz speed of the original IBM PC. This is one reason that some of my readers may recall when the PC AT clones came out running the 80286 chip running at up to 8Mhz (and faster for some clones) there was often a switch to run the CPU at a slower speed because many games otherwise simply ran twice as fast and as a result the users couldn’t react fast enough. So even if I could find a 5 1/4″ floppy and get my current machine to read the drives in a VM, I’m not sure I could clock down a VM slow enough to play this. But, I may have to do this one of these days. Just for the fun of it.

I still have the original disks and documentation that came with it.

Flying outbound from NYC

A part of me does wonder if this is worth anything more than the memories. But for now, it remains in my collection; along with an original copy of MapInfo that was gifted to me by one of the founders. But that’s a stroll down memory lane for another day.

And then I encountered SQL Server only a short 6 or so years later. And that ultimately has been a big part of where I am today.

“Houston, we’re venting something into Space…”

This post is the result of several different thoughts running through my head combined with a couple of items I’ve seen on social media in the past few days. The first was a question posted to #SQLHelp on Twitter in regards to if a DBA came into a situation with a SQL Server in an unknown configuration what one would do. The second was a comment a friend made about how “it can’t get any worse” and several of us cheekily corrected him saying it can always get worse. And of course I’m still dealing with my server that died last week.

To the question of what to do with an unknown SQL Server, there were some good answers, but I chimed in saying my absolute first thing would be to make backups. Several folks had made good suggestions in regards to looking at system settings and possibly changing them, possibly re-indexing, etc. My point though was, all that could wait. If the server had been running up until now, while fixing those might be very helpful, the lack of fixing things would not make things worse. On the other hand, if there were no up to date backups and the server failed, the owner would be in a world of hurt. Now, for full disclosure, I was “one-upped” when someone pointed out that assuming they did have backups, what one really wanted to do was a restore. I had to agree. The truth is, no one needs backups, what they really need are restores. But the ultimate point is really the same, without a tested backup, your server can only get much worse if something goes wrong.

I’ve had to apply this thinking to my own dead server. Right now it’s running in a Frankenbeast mode on an old desktop with 2GB of RAM. Suffice to say, this is far from ideal. New hardware is on order, but in the meantime, most things work well enough.

I actually have a newer desktop in the house I could in theory move my server to. It would be a vast improvement over the current Frankenbeast; 8GB of RAM and a far faster CPU. But, I can’t. It doesn’t see the hard drive. Or more accurately, it won’t see an OS on it. After researching, I believe the reason comes down to a technical detail about how the hard drive is setup (namely the boot partition is what’s known as a MBR and it needs to be GPT). I’ll come back to this in a minute.

In the meantime, let’s take a little detour to mid April, 1970. NASA has launched two successful Lunar landings and the third, Apollo 13 is on its way to the Moon. They had survived their launch anomaly that came within a hair’s breadth of aborting their mission before they even made orbit. Hopes were high. Granted, Ken Mattingly was back in Houston, a bit disappointed he had been bumped from the flight due to his exposure to rubella. (The vaccine had just been released in 1969 and as such, he had never been vaccinated, and had not had it as a child. Vaccines work folks. Get vaccinated lest you lose your chance to fly to the Moon!)

Stack of Swiss cheese slices showing holes lined up.

A routine mission operation was to stir the oxygen tanks during the flight. Unfortunately, due to a Swiss Cheese effect of issues, this nearly proved disastrous when it caused a spark which caused an “explosion” which blew out the tank and ruptured a panel on the Service Module and did further damage. Very quickly the crew found themselves in a craft quickly losing oxygen but more importantly, losing electrical power. Contrary to what some might think, the loss of oxygen wasn’t an immediate concern in terms of breathing or astronaut health. But, without oxygen to run through the fuel cells, it meant there was no electricity. Without electricity, they would soon lose their radio communication to Earth, the onboard computer used for navigation and control of the spacecraft and their ability to fire the engines. Things were quickly getting worse.

I won’t continue to go into details, but through a lot of quick thinking as well as a lot of prior planning, the astronauts made it home safely. The movie Apollo 13, while a somewhat fictionalized account of the mission (for example James Lovell said the argument among the crew never happened, and Ken Mattingly wasn’t at KSC for the launch), it’s actually fairly accurate.

As you may be aware, part of the solution was to use the engine on the Lunar Module to change the trajectory of the combined spacecraft. This was a huge key in saving the mission.

But this leads to two questions that I’ve seen multiple times. The first is why they didn’t try to use the Service Module (SM) engine, since it was far more powerful and had far more fuel and they in theory could have turned around without having to loop around the Moon. This would have saved some days off the mission and gotten the astronauts home sooner.

NASA quickly rejected this idea for a variety of reasons, one was a fairly direct reason: there didn’t appear to be enough electrical power left in the CSM (Command/Service Module) stack to do so. The other though was somewhat indirect. They had no knowledge of the state of the SM engine. There was a fear that any attempt to use it would result in an explosion, destroying the SM and very likely the CM, or at the very least, damaging the heatshield on the CM and with a bad heatshield that would mean a dead crew. So, NASA decided to loop around the Moon using the LM descent engine, a longer, but far less risky maneuver.

Another question that has come up was why they didn’t eject the now dead and deadweight, SM. This would have meant less mass, and arguably been easier for the LM to handle. Again, the answer is because of the heatshield. NASA had no data on how the heatshield on the CM would hold up after being exposed to the cold of space for days and feared it could develop cracks. It had been designed to be protected by the SM on the flight to and from the Moon. So, it stayed.

The overriding argument here was “don’t risk making things worse.” Personally, my guess is given the way things were, firing the main engine on the SM probably would have worked. And exposing the heatshield to space probably would have been fine (since it was so overspecced to begin with). BUT, why take the risk when they had known safer options? Convenience is generally a poor argument against potentially catastrophic outcomes.

So, in theory, these days it’s trivial to upgrade a MBR disk to a GPT one. But, if something goes wrong, or that’s not really the root cause of my issues, I end up going from a crippled, but working server to a dead server I have to rebuild from scratch. Fortunately, I have options (including now a new disk so I can essentially mirror the one disk, have an exact copy and try the MBR->GPT solution on that one) but they may take another day or two to implement.

And in the same vein, if it’s a known SQL Server, or an unknown one, you’re working on, PLEASE make backups before you make changes, especially anything dramatic that risks data loss. (and I’ll add a side note, if you can, avoid restarting SQL Server when diagnosing issues, you lose a LOT of valuable information in the DMV tables.

So things CAN get worse. But that doesn’t mean there’s any need to take steps that will. Be cautious. Have a backout plan.

Life in a Time of Coronavirus

With apologies to Gabriel García Márquez.

Life in the past week has definitely take a turn. We’ve gone from, “this might be bad” to losing about 30% of the market value of the stock market, and basically the country is shutting down.

I’d like to quote R.E.M. and say “It’s end of the world as we know it, and I feel fine” but the truth is more complex. Physically, I feel fine. I don’t think I have the Coronavirus, but of course I can’t say for sure.  I’m not really worried about myself. I’ve been working from home for years and so already had reduced the vector of working in crowded offices. But, of course my wife has been working in an office (though tomorrow her job will become “work from home”) and my son just came home from college for a break of now unknown length and my daughter’s school started a mandatory closure with some sort of undefined “remote teaching”. It’s still unclear what teachers will do what, but I hope by the end of the week they’ll be able to have a more robust teaching rubric in place.

I’ve been thinking a lot about toilet paper lately. We picked up some more rolls, just in case, but we’re far from hoarding (unlike the story of one family of four I read about on Facebook that apparently was caught trying to bypass the rules at a supermarket and buying 16 packs of 24 rolls of toilet paper: yes, they were trying to buy a total of 384 rolls of toilet paper in one day!)

But I’d by lying if I didn’t say there was a certain about of dread on my mind. Things are going to get worse before they get better.  I’ve been monitoring a site out of Johns Hopkins that seems to have accurate and fairly up to date data on the spread of the Coronavirus. The numbers aren’t great.  If the spread continues according to some models, we could be looking at a death toll in the US of 500,000-1 million or more.  These are staggering numbers. Now, to be clear, with social distancing and other measures, I have reason to hope the numbers will be 1/10th of those numbers, but even that’s a good sized number.

And of course there’s the aforementioned drop in the value of the stock market, and I honestly think it will only get worse.  If the worse case death tolls come in, we’re looking at a fundamental shake-up of our economy. Couple that with some of the possible mid-term effects as people face bankruptcy due to income loss and longer term changes that may result as a result of social changes. For example I’ve seen one headline suggesting that cinemas may simply not make a comeback after people stop going and just watch them at home. This is all scary and worrisome. And it’s bigger than toilet paper.

But more importantly, I’ve been thinking about families. I’ve written about this before and I’ve mentioned #SQLFamily. With Social Distancing being the current buzzwords, it’s put a damper on getting together with people. I know it’s so tempting to call up some friends and say, “hey, let’s get together and play games” but that sort of negates the point of social distancing.

My families, virtual and my biological one give me hope and cause to celebrate. On the RPI based chat program I use, Lily, it’s been great to see how one whole discussion is pretty much focused on a fact-based exchange of ideas. Even those of us on separate ends of the political spectrum are basically exchanging facts and mostly keeping emotions in check. This has been a useful place to learn a lot.

And on Twitter and elsewhere, it’s been remarkable to see #SQLFamily come together. Last Friday, and coming again this Friday, one of our members hosted a Zoom Chat where #SQLFamily members could just hang out and chat. Yeah, we talked about TP, and power outages in Johannesburg, and other topics, but it was mostly fun small talk. It was a reminder, that there are real people behind the Twitter handles and tweets. I’ve seen my #SQLFamily members send tweets about the success of their own family members and of their own hopes and fears.

Having gone to a technical college, and usually surrounded by folks who are self-identified geeks, sometimes it can be tempting to think we’re all just emotionless people driven by facts and data, human version of Star Trek’s Mr. Spock or Data, but the reality is, the families I’ve surrounded myself with are an amazing, resilient, group of people. And I think that’s probably true of most of us. It’s tempting to think “my group is special” and in some ways every group is, but at the end of the day, I think what unites us is greater than what separates us. Yes, fortunately I think my virtual families tend to make decisions a bit more based on facts than some groups, but we still share the same humanity deep down.

So, is there a tinge of dread on the horizon of my mind, yes. But I also see the sun rays of hope peaking above the clouds and know that the next weeks, months and possibly year or more will be rough. Some of us may lose loved ones. And I hate to type that, but it’s true. But, life will go on and we’ll find a new normal and we will do so by maintaining our relationships, physical and virtual.

My advice, during these times, reach out, expand your virtual relationships. Find hope and happiness where you can and share your fear, sadness, and sorrow when you need to.

Do small acts of kindness.

And I make the following offer:

If you’re down and need to talk or even just a cheer-up hit me up on twitter @stridergdm or if you know me on Facebook, private message me. If you want to join me on Lily, let me know, I’ll set you up with an account and a client. It’s mostly RPI folks, but not exclusively. If you really need it, we can even to a Zoom chat to talk about anything, from the role of the little known Saturn IV stage to talking about the Hudson River Chain at West Point during the Revolutionary War to recipes for air fryers, I’m there.

I’m going to close with a bit of randomness, because, well I think we need it.

A random cow sighting at a local Walmart.

A random cow sighting at a local Walmart.

 

Brake (sic) it to Fix it!

Last week I wrote about getting my brakes fixed. Turns out I made the right choice, besides shoes and pads, I needed new calipers.  Replacing them was a bigger job than I would have wanted to deal with. Of course it cost a bit more than I preferred, but I figure being able to make my car stop is a good thing. I had actually suspected I’d need new calipers because one of the signs of my brakes needing to be replaced was the terrible grinding and shrieking sound my left front brake was making. That’s never a good sign.

As a result I started to try to brake less if I could help it. And I cringed a bit every time I did brake. It became very much a Pavlovian response.

About two weeks ago, a colleague of mine said, “Hey, did you notice the number of errors for that process went way up?” I had to admit, nope, I had not. I had stopped looking at the emails in detail. They were for an ETL process that I had written well over a year ago. About 6 months ago, due to new, and bad, data being put into the source system, the ETL started to have about a half dozen rows it couldn’t process.  As designed, it sent out an email to the critical parties and I received copies.  We talked about the errors and decided that they weren’t worth tracking down at the time.  I objected because I figure if you have an error, you really should fix it. But I got outvoted and figured it wasn’t my concern at that point. As a result, we simply accepted that we’d get an email every morning with a list of rows in error.

But, as my colleague pointed out, about 3 months ago, the number of errors had gone up. This time it wasn’t about a half dozen, it was close to 300. And no one had noticed.  We had become so used to the error emails, our Pavlovian response was to ignore them.

But, this number was too large to ignore. I ended up doing two things. The first, and one I could deploy without jumping through hoops was to update the error email. Instead of simply showing the rows of errors, it now included a query that placed a table at the top that showed how many errors and in which tables. This was much more effective because now a single glance can easily show if the number of errors has increased or gone down (if we get no email that means we’ve eliminated all the errors, the ultimate goal in my mind.)

I was able to track down the bulk of the 300 new errors to a data dictionary disagreement (everyone raise their hands who has had a customer tell you one thing about data only to discover that really the details are different) that popped up when a large amount of new data was added to the source system.

I’ve since deployed that change to the DEV environment and now that we’re out of the end of the month code freeze for this particular product, will be deploying to production this week.

Hopefully though the parties that really care about the data will then start paying attention to the new email and squawking when they see a change in the number of bad rows.

In the meantime, it’s going to take me awhile to stop cringing every time I press my brakes. They no longer make any bad sounds and I like that, but I’m not used to to absence of grinding noises again.  Yet. In both cases, I and my client had accepted the normalization of deviance and internalized it.

I wrote most of this post in my head last week while remembering some other past events that are in part related to the same concept.  As a result this post is dedicated to the 17 American Astronauts who have perished directly in the service of the space program (not to diminish the loss of the others who died in other ways).

  • Apollo 1 – January 27th, 1967
  • Challenger – STS-51L – January 28th, 1986
  • Columbia – STS-107 – Launch January 16th, 2003, break-up, February 1st, 2003.

 

 

The Soyuz Abort

Many of you are probably aware of the Soyuz abort last week. It reminded me of discussions I’ve had in the past with other space fans like myself and prompted some thoughts.

Let’s start with the question of whether Soyuz is safe. Yes but…

When Columbia was lost on re-entry a lot of folks came out of the woodwork to proclaim that Soyuz was obviously so much safer since no crew had died the ill-fated Soyuz 11 flight in 1971. The problem with this line of thought was that at the time of Columbia, Soyuz had only flown 77 times successfully vs 89 successful flights since the Challenger Disaster. So which one was safer? If you’re going strictly on the successful number of flights, the Space Shuttle. Of course the question isn’t as simple as that. Note I haven’t even mentioned Soyuz 1, which happened before Soyuz 11 and was also a fatal flight.

Some people tried to argue that the space shuttle was far less safe because during the program it had killed 14 people during its program life vs 4 for Soyuz.  I always thought this was a weird metric since it all came down to the number of people on board. Had Columbia and Challenger only flown with 2 on each mission, would the same folks argue they were equally safe as Soyuz?

But we can’t stop there. If we want to be fair, we have to include Soyuz-18a. This flight was aborted at a high altitude (so technically they passed the Karman Line and are credited with attaining space.)  Then in 1983, Soyuz T-10a also suffered an abort, this time on the pad.

So at this point I’m going to draw a somewhat arbitrary line as to what I consider a successful mission: the crew obtains an orbit sufficient to carry out a majority of their planned mission and returns safely. All the incidents above, Soyuz and Space Shuttle are failed missions.  For example, while Soyuz-11 and Columbia attained orbit and carried out their primary missions, they failed on the key requirement to return their crew safe.

Using that definition, the shuttle was far more successful. There was one shuttle flight that did undershoot the runway at Edwards, but given the size of the lakebed, landed successfully.  We’ll come back to that in a few.

Now let me add a few more issues with the Soyuz.

  • Soyuz-5 – failure of service module to separate, capsule entered upside-down, and the hatch nearly burned through. The parachute lines also tangled resulting in a very hard landing.
  • TMA-1 – technical difficulties resulted in the capsule going into a ballistic re-entry mode.
  • TMA-10 – Failure of the Service Module to separate caused the capsule to re-enter in an improper orientation (which could have lead to a loss of the crew and vehicle) which ended up causing the capsule also re-enter in a ballistic re-entry mode. The Russians initially did not tell the US.
  • TMA-11 – Similar issue as TMA-10, with damage to the hatch and antenna that was abnormal.

And there have been others of varying degree. I’m also ignoring the slew of Progress failures, including the 3 more recent ones that were launched on a rocket very similar to the current Soyuz-FG.

So, what’s safer, the Soyuz or the Space Shuttle?  Honestly, I think it’s a bit of a trick question. As one of my old comrades on the Usenet Sci.space.* hierarchy once said, “any time a single failure can make a significant change in the statistics, means you really don’t have enough data.” (I’m paraphrasing).

My personal bias is, both programs had programmatic issues (and I think the Russians are getting a bit sloppier when it comes to safety) and design issues (even a perfectly run shuttle program had risks that could not have been solved, even if they might have prevented both Challenger and Columbia).  However, I think the Russian Soyuz is ultimately more robust. It appears a bit more prone to failures, but it has survived most of them. But, that still doesn’t make it 100% safe. Nor does it need to be 100% safe.  To open the new frontier we need to take some risks.  It’s a matter of degree.

“A ship in harbor is safe, but that is not what ships are built for.” – John A. Shedd.

A spacecraft is safe on the ground, but that’s not what it’s built for.

In the meantime, there’s a lot of, in my opinion naive, talk about decrewing ISS. I suspect the Russians will fly the Soyuz TM-11 flight as scheduled. There’s a slight chance it might fly uncrewed and simply serve to replace the current Soyuz TM-9 capsule, but it will fly.