Make Mine MAPPER #37 -------------------- by Rob Haeuser Rids In Wonderland ----------------------------------------------------------------- As Buckaroo Bonsai once said: "No matter where you go, there you are." Can't argue with that. Seems reasonable enough. Besides, who am I to question the wisdom of a fictitious brain- surgeon-rock-and-roll-star-physicist who can drive a car straight through a solid mountain? My response might be: "Yeah, well, no matter where you are, you better hope that it's where you wanna be, 'cause sometimes it ain't." It can get even worse. Sometimes, not only do you feel like you've been there before, but, if you're remembering correctly, you didn't want to be there then, either. Deja vu, with a twist of lemon, please. Shaken, not stirred. As I continue to stoke the flames of confusion, I might add that this is bound to make sense at some point. If you are a MAPPER coordinator or run designer, or simply have a passion for causing headaches for 'em, read on. Beware! The following bit of information may pop a little bubble that has been floating a security technique for who-knows- how-many applications. But first, a question. When can a report not be where you think it is? The answer is, unfortunately, a bit tedious. Besides, if I told you right away you might not bother to read the upcoming part about my utility package (plug, plug). A few months ago, as I was developing one of the utilities in GURU, I stumbled upon a situation that, at first, I tried like mad to resolve. Upon failing to do so, I then tried like mad to ignore it in the hope that it would go away. It hasn't. The first clue actually harks back years ago to a run that displayed a result with this phrase emblazoned right at the top: "Please do NOT XR this result." Well, gee, why not? "'Cause you'll clutter up the database, idiot!" Oh, ok... So you probably left it at that, never questioning why the run couldn't seem to make a blasted result immune to XR. Seems like you could just break into an odd cabinet, eh? And I don't mean take a crowbar to you're great-aunt's gargoyle-beheaded furniture, either. When a run is registered, it is either restricted to certain cabinets, or given access to "all" cabinets. It seems logical to me that if a run is given access to, say, cabinet 2, that it should also have access to cabinet 3, the read-only version of 2. And by the same token, why shouldn't the "all" include the odd? So, for years, I, and probably a number of run designers like me, have been either breaking into odd cabinets, or using them to rename reports prior to being displayed, confident that the magic of MAPPER would protect my databases from XR madness. Would that it were true. But, alas, my odds were even, my users XReth, and my database greweth. You see, in MASM MAPPER, if you give the run access to cabinet 2, and then break into 3, the run doesn't error, it simply breaks into 2 instead. How nice of it to do that. It assumes that you really didn't mean 3; you must have had a typo. Wow! Artificial intelligence! But, gee! I really did mean cabinet 3. And I don't want a bunch of XRed results cluttering up my blasted database, thank you very much! There may be a ray of hope for you MASM MAPPERites yet. Yes, you must register the run with access to cabinets 2 AND 3. Then the run can actually break into 3, and the result is protected from XR. Unfortunately, runs registered for all cabinets are generally in a different class. So far, I have been unable to come up with a true "all" that includes the odd ones without specifically stating them. How you produce results may have to be re-thought. For example, if you normally break into whatever cabinet the run is in, you may want to consider giving the run access to cabinet 1 specifically for places to break. Cabinet 1 contains enough drawer sizes and character types to meet most needs. If you use functions like search and sort on an odd cabinet, the run must be registered for that odd cabinet, or, once again, the result will be XRable. It gets even worse. OpenMAPPER for Windows (MFW) ignores the odd cabinet, even if the run is registered for it! No matter what I say, my results end up in the even cabinet, ripe for XRing. I haven't checked with Unix MAPPER yet, but I have found that if there is a variance between MASM MAPPER and MFW, then the Unix version tends to comply with MFW (darn it!). If you are running Unix, check it out. You will probably find the odd-cabinet syndrome running rampant there, too. This is truly a pain. But it sure explains the occasional bonsai rid; the one that crashed through all defenses and ended up smack dab in the middle of the mountain. ----------------------------------------------------------------- Rob Haeuser has more than 19 years of Data Processing experience. He was MAPPER Coordinator and Run Designer for the Texas Department of Human Services for ten years, and is now an independent contractor working in the Austin area. He also authored and is marketing a set of MAPPER run utilities called GURU. Covering MAPPER topics ranging from technical to tacky, his never-ending quest is for truth, justice, and the MAPPER way. Please direct all communications to: GURU Enterprises Attn Rob Haeuser 3212 Great Valley Drive Cedar Park, Tx. 78613 or call: 512-335-3862 (fax) / 512-331-0498 (voice)