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.