Make Mine MAPPER #29 -------------------- by Rob Haeuser ----------------------------------------------------------------- Why does everything have to go wrong on Monday morning, especially in winter? It's not like I enjoy having to stick my head in a microwave to thaw it out, just so I can think, on a day so blinking cold that you can't spit for fear of freezing your lips shut. Winter really should be banned altogether. Mondays, too, for that matter. Who needs 'em? And cold Mondays, to boot! Starting off with Tuesday would suit me just fine. I've been thinking on this one for quite a while now, and I believe I have an answer. Nuke Antarctica. No joke. Take all the nuclear weapons, dig a damn big hole in Antarctica slanted at just the right angle, set 'em all off simultaneously to create a big rocket engine effect, and the power blast would slow the planet down, correcting the unnatural axial tilt instigated by major asteroid collisions in the past. This would bring all major land masses back to a more tropical climate, lengthen the day by at least an hour-and-a-half, and set the stage for a good old-fashioned expedition to the center of the earth, 'cause, believe me, there's gonna be one big hole to be climbing down! Jules Verne would be proud! Maybe Mondays are cursed because we at TDHS usually do major stuff on Sundays. Like this last one, when we finally went to level 36 on one of our MAPPERs. Yes, folks, we have recently joined reality. Not without some minor headaches, mind you, which, if you haven't migrated (or is it migrained?) to 36 yet, can be avoided. In all fairness, there was an innocent little blurb, hidden somewhere obscure, like the manual or the readme screens, that briefly burbled something to the effect: "Oh yeah, by the way, DEPN$ is going from 3 to 4 characters, saps." Heh. Seems harmless enough. Sort of like the guy who spots the iceberg looming just a bit too close to the ship's bow saying: "Ooh! Look at the pretty sparkles!" Wait a minute. I don't think he truly appreciates the depth of the moment. Or at least that of the ocean underneath. But back to the blurb. What is a DEPN$? Looks funny with a question mark right behind it, too. Ya see, MAPPER's programming language, Run Design (catchy name, eh?), has these things called Reserved Words. Each one contains a pre-defined value supplied by the machine. These values include things like the date and time, your user- id, the station you're on, and on and on. Last time I counted there were about 164 of 'em, including a little gem called DEPN$. When you sign into MAPPER, you enter a number along with your user-id and password. That number is the department you are attempting to access, and to MAPPER, it is simply a pair of rids (reports) somewhere in a secure area, each in a different drawer. There is a rid for authorized users and a rid for available runs. When you execute a run that accesses DEPN$, it will contain the number you keyed in at signon. When you execute a run, it must be in the rid corresponding to your DEPN$, or it must be registered with global access. There are other functions in MAPPER using the department number equals a rid mentality. Unisys' version of the cabinet-switch run, for example, has always used a rid per department. Unfortunately, many years ago, when TDHS was first getting started with MAPPER, a single rid was set up to control all cabinet-switching. Even today, we only have 500 or so users per MAPPER who actually switch around. Others simply sign into a different department, gaining access to a different cabinet and set of runs. I guess the feeling was that it was too much trouble to have a hundred rids hanging around just for a few hundred users. So we wrote a local version of what was then known as the mode-switch run, then set up a rid with user-id, department number, and the authorized modes as fields, and went merrily on our way, writing lots of utility runs that would use the mode-switch authorization table (MSAT). Only problem is, at the time, DEPN$ was a three-character reserved word, and, you know what? Yep. We made the field the same size. Makes sense, doesn't it? So we end up with twenty-some-odd runs all whacking on this rid, each one using DEPN$, along with user-id, to verify that the user actually can beat up on a particular cabinet. We also use the MSAT to indicate certain levels of security for certain things (certainly is vague, isn't it?). Needless to say, once the number of runs hitting the MSAT exceeded twenty, I began to seriously consider the need for a shared subroutine to do the access, 'cause I was getting tired of writing the same few lines of code. I actually wrote the subroutine, but, alas, never fully implemented it. So what about DEPN$? We knew that it was always right- justified, that it would never contain leading zeroes, and that it was THREE characters. Yeah, right. So all the values in the MSAT are nice, right-justified, non-leading-zeroed, three-character numbers. Have I belabored this point sufficiently? So bright and early Monday morning the phones began to melt down as everybody reported that this wasn't working and that wasn't working, and oh, by the way, we can't mode-switch, either, nyah, nyah. I hate it when that happens. Believe me, the cause was not immediately obvious. Anything that had used a three-character field for department had the potential to fail. For example, I have a little utility called the Universal Color Utility (UCU). It gives users the ability to select personal screen color combinations that are then displayed by any run that wishes to access the color preference table. UCU stores preferences by user-id, department number, and station, and, yes, the number was three digits. What happens is this: when attempting a find or search, you define a field's starting position and length, and what to look for in the field. MAPPER will attempt a match from left to right between the field and the target value, in this case either DEPN$ or a variable loaded with it. Department " 75" (space-seven-five) became " 75" (space- space-seven-five), the find would attempt to locate the first three characters, a space-space-seven, along with a user-id and station, and would fail. It could get especially weird if you had multiple departments, like 7 and 75, 'cause then, if in 75, you'd get the functionality of department 7 instead. And if you had a single digit department number, like 7, MAPPER would end up looking for three blanks (the 7 is in the fourth column now), and we all know what that means. Anything goes. A space is in essence a wild card, matching anything, so the first occurrence in the table would be found, even if the d-num was 999. The only way I found this out was by using the run debugger against our mode-switch run. Walking through the code to the point where it attempts a find, I had it display the value of USER$ and DEPN$, and just happened to notice that new little fourth character so innocently hanging there to the left. Boing! Ah, Monday mornings! Wonderful to wake up to a little puzzle every now and then. I just wish we'd get a bigger microwave so I could fit my cup in there with my head. It's terrible drinking hot tea cold, don't you think? ----------------------------------------------------------------- Rob Haeuser has over 17 years of Data Processing experience. He has been the MAPPER Coordinator for the Texas Department of Human Services since 1983. Covering MAPPER topics ranging from technical to tacky, his never-ending quest is for truth, justice, and the MAPPER way.