So up and out this morning to take in "IMAGE/SQL and TPI" by Gerry Johnson. Mostly I learned that keyworded indexes are not provided to Allbase in an attach but that other third-party indexes are. Also, that it is wise to use "update statistics" in isql when making any DBE changes as that is a big help to the optimizer. Next to the MPE Performance Panel with Bill "It Depends" Lancaster moderating. 6.5 performance did come up. There appear to be three problems. First, there are some specific situations, mostly having to do with heavy I/O on small boxes that has some significant slowdown. Second, if your box is on the edge of disaster anyway, 6.5 might push it over the edge. I think that the number given was "no less than 128M of memory". Last, there was a problem introduced in 6.5PP1 which had a significant performance impact on SORT and there is a patch soon to be out which we'll want to put on top of PP1. The patch number was given, but I didn't get it down. I think that Neil Armstrong had it, perhaps he could give it here. There was quite some talk about number of spindles as well. The upshot being what seemed general agreement that a usage of about 4 or 4.5G per drive is about right and that more than that can degrade performance. It was recommended to go ahead and buy whatever you can get (4.5s can be hard to find) and just configure it to only use 4.5G-worth of the drive. Steve Macsisak gave some numbers which perhaps someone else has jotted down. My vague recollections are that on a given drive, you want to be using it at no more that 50% of it's rated average throughput for decent response and 25% for excellent performance and that when I/O rose above that, more spindles was a good move. Then off to the Ballroom of a live link to New York and the rollout of Superdome. Once again, a presentation completely innocent of MPE references. Sigh. I was pretty comfortable with that, as Superdome *is* a shot at the high-end UN*X market, until Carly said that what was important was open industry standards and proceeded to list of Windows, HP-UX and Linux as their three *non-proprietary* OSes. I mentioned a disappointment that MPE wasn't to go on Superdome at the 3000-L lunch and there was general agreement around the table that MPE doesn't *need* Superdome to accomplish the same amount that HP-UX will be accomplishing on it. I spent an hour each side of lunch wandering the Expo and, to my surprise, getting a solution or two ;-), and then off to Alfredo's talk. It was entitled "IMAGE/SQL Database Foundations" and was filled with all kinds of wonderful things. An Alfredo talk is a wonderful thing and this one was no disappointment. Probably the best line of the talk was when he was talking about not having access to a private 747 as the President does and someone in the crowd recommended using Carly's jet instead. Alfredo replied that he didn't think that that would be much help as it evidently couldn't get from Philadelphia to New York :-). I finished my HPWorld day with the IMAGE and HP SQL Roundtable with Ken Paul leading out. Jon Bale, bless his heart, has had to hold the fort as the only HP database person in attendance. They had arranged for two other DB folks to be there, but the one from Bangalore evidently had visa troubles and the one stateside was called away due to some other emergency, so he's standing alone, and doing a fine job of it. Ken Sletten, absent though he was, managed to ask if Oracle's moving off the box would result in any more resources going toward IMAGE and Allbase work. The short answer is no. The long answer is that that change really doesn't free up a whole lot of resources at HP, as there weren't many being used by that program recently. The question came up of including the 9th module of Allbase with IMAGE/SQL. Dave Wilde had already answered that pretty well at SIGIMAGE--we need to get paid sometime. They can't just give Allbase away. And I think that that's fair. The DSEM and Prefetch options came up. It is, if I've understood correctly, Ken Paul's considered opinion that enabling a database for DSem and Dumping is a safe and intelligent thing to do across the board, but that there are situations, particularly those high memory pressure, where enabling Prefetch can actually decrease performance, so that should be done as needed. Prefetch basically gets all the information needed for the DBUPDATE (or whatever) into memory prior to locking the semaphore so that the actual semaphore lock time is as short as possible. Under high memory pressure, some of that stuff can get flushed to disc and has to be regotten while the semaphore is locked, thus *not* shortening the lock time and requiring double I/O. Not pretty. Also, this flag is obviously not going to help at all in single-user updating, as shortening the lock time doesn't matter. That said, for OLTP when memory is available, Prefetch may well speed things along. Well, that's about all I'm remembering after this long a day. Oh, yeah, one more big thing. I finally met the famous Wirt Atmar and proceded to tell him that I'd be at his talk tomorrow (it's really on Thursday, which I knew, but, well, uh, that's where the title of this message came from :-). Actually, it's been good to add to the list of known faces: Joseph Rosenblatt, Lane Rollins, Tom Brandt, Mark and Julie Bixby, and numerous others. And now, before I blither much more, I'll wrap this up and head for bed. Ted -- Ted Ashton ([log in to unmask]), Info Sys, Southern Adventist University ========================================================== To Thales the primary question was not what do we know, but how do we know it. -- Aristotle (ca 330 BC) ========================================================== Deep thoughts to be found at http://www.southern.edu/~ashted