MUMPS, etc. (1)

Irony is listening to the morning radio show on the drive to work and pulling into your spot waiting to hear the answer to the question “87% of Americans have trouble doing this in the morning”, waiting and waiting, to find out the answer is “get to work on time”. Whoa.

BW3′s boneless wings with Honey BBQ sauce is the shiznit.

I am having the fortunate opportunity to work with the Database from Hell. Ladies and gentlemen, I present to you MUMPS, a 40 yr old database program that will not die, and that I get to indrectly work with. I am really using a KB_SQL implementation of it, but all of the retardation of using an archaic program from the 60s shines through. I spent the greater part of the afternoon trying to figure out how to get the damn thing to “create” a date programmatically. All I wanted to do is get the first of the current year (Jan 1) and the first of the current month. I have the current day. I can get the current year. I can get the current month. But can I tell it “Jan 1 of the current year” and have it create a date based on that? Of course not. Goddamn stupid thing. Every other modern database/programming language has something like this, or at least a workaround. Bah! Don’t even get me started that all dates are actually stored internally as the number of days/seconds from 12/31/1840. That makes perfect sense, too.
Oh, but the fun doesn’t stop there. Variable names are limited to 9 characters. Two of those have to be “: X” (without the space because gay-assed WordPress converts colon-crap to smileys which is normally cool but doesn’t work with this so it pisses me off). So variable names are actually limited to 7 characters. What the hell? Oh, and they can’t have underscores or other weird characters.

There is some arbitrary length (as in number of lines of code) that a SQL query can be. No one knows what it actually is, but “when you start getting a really long query, you should probably start saving often and backing it up”. Why? Because if you go over the limit, not only does the query crash, but it also destroys the actual query so that you can’t even open it up again. I.e, you have to do it all over again. Excellent. This was reasoned to me because it apparently allocates slots of memory to the query when it is run. They are numbered, starting at 00 and incrementing 01, 02, 03, 04, etc. So what happens when you get to 09 and it’s still going? It rolls over to 010!
01
02
03
04
05
06
07
08
09
010
Oh. My. God. So what happens is the “10th” chunk writes over the first chunk, screwing the pooch and causing holy hell to break out. Why would you want to go from 09 to 10 when you can logically go to 010? Jeesh.

The whole thing is like some sick bastardization of modern SQL.

On an unrelated (or is it?) side note, I learned about using bitwise operators to do IF…THEN statements today. Saw some code and it threw me for a loop – didn’t know what i was looking at. We did some bitwise stuff as an exercise in class back in the day, but never really applied it. This basically fed options into a binary number and performed conditions based on that. I don’t know why you wouldn’t just use IF statements for something like that. It’s kind of strangely beautiful to see the code – it makes sense, yet is so confusing if you don’t know what you’re looking at (ie, HARD TO MAINTAIN IF YOU DIDN’T ORIGINALLY WRITE IT). At least now I know, right?

Seacrest out.