Make Mine MAPPER #20 -------------------- by Rob Haeuser Data Storage: Who Cares? and... Another Bug Squashed ------------------------------------------------------------------- Fancy stuff, those super-ram-dram-cram-it-in-cache disks. And have you seen robo-tapes at work? It makes us lowly humans seem downright pokey, Joe. But isn't that the way it's supposed to be? What century is it, anyway? What?!! Still the twentieth? You see, I grew up on comic books, er, I mean science fiction. Yeah, that's it. Science. You see, I was gonna be an astronaut. Yeah, that's it. An astronaut. And I was gonna go to the moon. No Mars. Or Jupiter. Yeah, that's it. Jupiter. I was gonna head up the first expedition to Jupiter. Spaceship? No problem. Invent one. But then there's that trajectory thing. You know how much data it takes to calculate all that stuff? Yep. Bunches. What? Not enough memory? Big deal. Roll it out to disk. What do you mean, "What's a disk?!" Oh yeah, I forgot, this was before the word "computer" had entered the dictionary. Well, so somebody finally invented the ultimate disk, eh? At least that's what we'd all like to think. Elsewhere in this issue you'll see numerous discussions on the data storage thing, from both the hardware and software angle. But as for me, you see, I don't care! Ha! Just gimme the data, dude, and I mean right now! No nano lag allowed! To be truthful, that's just the run designer in me talking. The coordinator part is cringing, agog in disbelief that any run designer could possibly not care about data storage. It's especially painful when that run designer is myself! It's like two programs both trying to lock the same record: too bad, but somebody's gotta give. Pass the Doctor Jekyll juice, Igor! Heh, heh! Heh, heh! Whenever these little internal conflicts erupt, I try to break the problem down into it's logical components. Beats going to a shrink. As far as the data storage issue, we can boil it down to just a few key elements: 1) Who stores it? 2) What is stored? 3) Where is it stored? 4) When is it stored? 5) Why is it stored? 6) How is it stored? 7) Who cares? Of course, the ultimate dream is for the "who", "what", "where", "when", "why", and "how" to be handled automatically. Yeah, well, it ain't there yet, at least not for us programmers. Ah, but we can create the illusion for our users: that's why they call us automatons, isn't it? Sorry, I meant automaters... and not somebody with a car fetish, either! Sheesh! There was a time when MAPPER's own internal database file structure (notice I didn't call it flat!) was your only option when storing data. It is usually quite sufficient, I might add, even for very large applications (please refer to the Make Mine MAPPER articles "Mega-Databases: Tricky But Possible" and "Database Structure: the Secret to Success" published in the February and June 1991 issues of Unisys World, respectively). After awhile, a TIP interface was added, allowing access to any file that TIP could handle. But that was just the TIP of the iceberg. And then along came MRI (MAPPER's Relational Interface - not the line from the popular song of the sixties). Suddenly the world of externally managed databases was a viable option when designing MAPPER applications. MRI level 36R1A has two modes: basic and extended. Basic mode allows access to a local Relational Database Management System (RDMS 1100). Extended mode allows access to both local and remote RDMS 1100, remote ORACLE, remote INFORMIX, SYBASE, and DB2 databases. Combined with MAPPER-to-MAPPER and MAPPER-to-TIP connectivity, the variability of file formats available is more than sufficient for any serious programmer's needs. Enter the Designer Workbench, stage right. Now, a single interface can be used to access the entire data universe, mainly through MAPPER, of course. Where the data lives, even the location of programs being executed and the images being displayed, becomes a question for analytical speculation. Was it real or was it Memorex? Only your hairdresser knows for sure. As long as we're mixing and mashing metaphors, how's about we skew the data storage thing all over the grill, or is it the barby, doll? Oh, boy! We're wandering now! Hey, who's this? This guy looks like he's been wrestling crocodiles. "That's called walk- about, mate. And that's skewer, not skew." "'Scuse me. I guess I meant look at it from a twisted, obscure, almost-completely- unrelated point of view, okay?" Who arranges for these cameo spots, anyway? Warning! The following discussion may be too obscure for the uninitiated. To be initiated, please send me $10.00 cash. Only kidding. Make it twenty. Or at least that's what I'd like to get for every bug I've squashed. Hey! Talk about bugs! An obscure little critters popped up the other day... Or rather, it didn't pop up. At least that's what the run designer was saying. You see, he was trying to store some data in a result and display it on the screen using the SC (screen control) function. Store some data; data storage: get it? Hey, I told you it was obscure. Some of our terminals are, to be kind, candidates for the Smithsonian, and aren't very good at complicated things, like reverse video, for example. So, to support all makes and models, some run designers will wrap the screen input fields with a special character to help identify the location and size. In this case, the left and right brackets ("[" and "]") were used. "My bracket broke." "You mean you have a broken bracket? Sounds like a job for super-mechanic! I know this little old lady that can virtually lift cars just by watching soaps. She doesn't even use jacks. One-handed, too. She holds it up in one, and fixes it with the other. Amazing. Only thing is, her hours are from 11 a.m. to 2 p.m. That's when the soaps are on. Oh, you mean you have a run bug? Might you be just a bit more specific?" "Glad you asked. Run this run." Obviously a man of few words. "See. All the fields have their little brackets except this one...nnn...nnn..nnnyyyaaaahhhh!!!!" Poing! Damn! I think his spring went out again. "Okay, okay. I'll look at it while you rewind. Lord knows, you better. Those springs hanging out your ears are sharp enough to take somebody's nose off!" So check out Figure 1. ------------------------------------------------------------------- FIGURE 1 -------- @LDV V1H2,V2H4,V3H7,V4H9,V5H12,V6H6=DATE1$,V7H2,V8H8,V9H16,V10H1,\ V11H6=DATE1$,V12H3,V13H9,V14H5,V15H3,V16H6,V17H2,V18H12,V19H1,\ V20S32,V21S32,V22H5,V23H6=DATE1$,V24I4,V25I4, . . . etc. forever @BRK RER,M,T,R 1 RSR,M,T,R 1 . set error routine, get global vars DEF,1, . . . DEF,2, . . . DEF,3, . . . DEF,4, . . etc, etc, etc. FLD,2, , , , FLD,3, , , , create a screen box PC,2,22;'' The Ultimate Screen '' position cursor; brag PC,+2,12;'' Input 1 ['';FLD,,,,2,,3;PC,,-1;] create input field! " " " " " " " " ditto for about six more fields " " " " " " " " - - more code here to build a function bar and transmit point - - @BRK SC,-0 T V1,V2,V3,V4,V5,V6,V7,V8,V9,V10 . ------------------------------------------------------------------- Note the line that creates the input field. The FLD command creates it, but, because the cursor automatically moves one character position beyond the end of the field, we have to issue the "PC,,-1" command to back it up. Then the "]" character should be picked up as data and displayed. And it is, for every field but one! The fields before and after it were just fine. So I go into my "when all else fails, throw code at it" mode. I added a few extra characters after the bracket. They didn't display. I moved the characters to the right far enough to be outside the box, and they showed up! A clue? Nah! I added characters all over the place, and the only spot that they absolutely refused to display was between the end of the rotten little field and the border of the screen box! When all else fails whip out the run debugger, folks. It'll work wonders. A small detail needs to be brought to light. Please note that the SC command "SC,-0 T V1,..." uses the "T" option, which instructs MAPPER to use the listed variables to pre-fill the input fields with data as the screen is being displayed. And now for a clue: it was the sixth field with the missing bracket. Got it yet? Yep, good old run debugger. As I was browsing through the code, I monitored V6, the variable used to pre-fill the field in question. Note the line of code that loads the variables. V6 should be loaded with the current date in the format YYMMDD (date1$). But what I saw was the literal string "DATE1$". Hmmm. The source of all our misery, literally minutes of brain- burning, hair-uprooting, finger-cracking, gut-burbling, and, dare I say, nerve-wracking agony, was the fact that the most simple of functions, that lowly little LDV, you see, is missing the "W" option! "W", of course, as in Word, or, more specifically, Reserved Word, for which "DATE1$" qualifies. Is a puzzlement! Sure enough, adding the "W" option fixed the problem, and the missing bracket misseth no moreth. Apparently, MAPPER really doesn't like a dollar sign in the last character position of an input field, because it would display in any other position just fine. As to exactly why MAPPER ignores subsequent data, and only up to the screen box border, to boot, is, as they say, academic. In the meantime, for all of you lucky enough to be in San Francisco for the USE conference, remember this: don't try to store too much data online - you know, the one between your ears. You can always buy the audio tapes. Have a good time!