I find I spend much of my copious spare time promoting HP, and extolling the virtues of MPE. I won't be doing that today :-o It may have something to do with the 13 hour MPE 5.0 migration we had yesterday. Well, that's not fair. I migrated two systems yesterday (the last of four). One systems migrated in 2.5 hours, a new land speed record. HP has done much to streamline and bullet proof AUTOINST and other tools, and the effort are showing . . . and welcome. Now if they could lend that talent out to the AllBase labs, we'd be doing well. I want to take just a second to suggest that the SQLMIG tool source code needs to be taken out and burnt on a sacrificial 980, along with the SQLMIG programmer. Here's the deal: We migrated all but one DBE without error. The last one, however, choked providing a less-than-helpful error message, noting only that it could not open a DBE file, and echoing out the FSERROR, which in turn noted that the file did not exist. Yes, I can see where it would be difficult to migrate a non-existent file. The only thing that could make this situation more difficult would be not knowing what file is missing. SQLMIG knew that this would add to end user frustration, and was playfully hiding the identity of the missing file from me. No amount of begging, threats or physical violence against the console would get SQLMIG to tell me what file was missing. No name, No UFID, no DBEFileSet, no nothing. What made this happy little scenario more difficult was that this host was the last of our boxes to be migrated. There was not a 4.0 system with F.? AllBase to be found. Why, you may ask, is that an issue? Well, when running under G.0, ISQL, SQLGEN, SQLUTIL and brethren refuse to work with an unmigrated DBE. Had there been a F.? System in house, I could have (a) copied over the database files, (b) run SQLGEN to find the list of DBE files registered in DBCON, then (C) compared that list against what was on disc to see what file was missing (the one SQLMIG refused to identify). The two things which I find so entertaining (a rim shot for heavy sarcasm) about this, aside from the mute SQLMIG program are that (a) HP does not provide a tool to PREVIEW a migration until (b) a point where you are committed. Unless I missed something in the migration manual, SQLMIG for G.0 could not have been restored on a F.? System to find these errors before committing to MPE 5.0 and AllBase G.0. Instead we entered a state where for a while, our only option appeared to be to back 5.0 out. Our 1,000+ on-line users of this system would not have been happy with an additional eight hour delay. HP and I fumbled around for a few hours trying to hex dump the DBCON file (very big), and HP was in the process of downloading it (very long), when I stumbled across an old an output from SQLGEN. I would have found it earlier except the programmer had fat-fingered the run, and the file name it was under started with "DEB" instead of "DBE". Anyway, it listed a DBE file that (a) did not exist on disc, (b) had been added to a DBEFileSet, but (c) had never had any tables or indexes built on it. The programmer had evidently decided (s)he didn't need the physical file anymore, and instead of DROPing the file in ISQL, and SQLUTIL PURGEing it, just fired up MPEX and blew it away. Which is what I will do to the programmer if they are foolish enough to admit to the error. Since there was no data in the file, having never had a table or index built on it, ISQL and our Pascal/C programs never complained. Hell, they never even tried to open the file. But SQLMIG dutifully attempted to migrate every DBE file, including those AWOL. Armed with a file name, I dropped over to the development system and found a version of said file. I copied the file to the production system, ran SQLMIG, and watched it blow up from a PRIVILEGED FILE VIOLATION. Seems the original file, the one our soon-to-be-deceased programmer PURGEd, was 2,601 pages long (anyone else notice the Image mindset at play). The development system file was 500 pages. So, I popped into MPEX, expanded the FLIMIT, then ran SQLMIG one more time. And it croaked, again with a PRIVILEGED FILE VIOLATION. At this point I took a wild, hopeful *guess* that (a) SQLMIG was basing all it's decisions on DBE file build metrics as recorded in the DBCON file -- not what was really on the disc, (b) that it thought the target file was 2,601 pages long, and (c) like all proper DBEFILEs, all the pages were full (i.e., EOF=FLIMIT). I also banked on SQLMIG (d) not doing any low level status checking of the contents of a DBEFile and FCOPYed the 500 test records out to a flat file, then back in again until the file was filled. A desperate gamble by a desperate man. And it worked! Amazing. I was relieved, HP was relieved (thanks Hal for standing by while I worked all this out) and our programmer was relieved . . . until he noticed that the data was a month old. I won't go through the details, but our home brewed backup system failed to store off a number of DBE files the night before, and a RESTORE during the migration effort put down a mixed set. Thus, in a set of 10 physical files that all composed a MIXED DBE fileset, some were current and some were not. ISQL didn't noticed this, but obviously lost it's way while climbing out onto a branch and misplaced a months worth of rows for lack of a coherent index. Thankfully Friday's backup was complete, and we lost only a day's worth of low volume data. BTW, the programmer who wrote the backup system that failed to catch the fact that DBE files were open and could not be stored, has been fed to a pack of blood thirsty end-users who lost a days worth of data. Burial plans have been canceled due to a sudden lack of a corpse. Hopefully HP will face this same problem once the programmer who decided that SQLMIG didn't need to print a tombstone, or printf() a file name has been identified (a side note: PICS confirmed that there are several outstanding SRs filed against this problem dating back several years. Given that this one outage kept over 1,000 end users out of a production database for over seven hours, I trust HP will now understand the economic imperative involved of expend some programmer time to put a *@%&#$! printf() statement in their code). Two other amusing little issues I'll pass your way before I return the bandwidth to our regularly scheduled programming. There has been a change in the memory management of either MPE 5.0 or some Pascal internals. In our case it is pointing up the seven or eight billion instance where programmers have not initialized strings of pointers. HP does not have a coherent explanation as to what has changed, but leave it to say that the probability of any random hunk of memory where a string/pointer is later allocated having a binary zeros has dropped dramatically, with an equally increase probability that the program will abort, and that tar-and-feather sales will at the local hardware store will increase. The other MPE funny is a change in the allocation of $OLDPASS files. Our programmers, bless their pointed little heads, tend to Super Tool extract files to $OLDPASS, then save the file to another group named GARBAGE which we empty every night). GARBAGE is on the MPEXL_SYSTEM_VOLUME_SET (WHICH_IS_A_STUPIDLY_LONG_NAME_FOR_THE_VOLUME_SET_WE_ REFERENCE_MOST_OFTEN). My guess is that under 4.0, $OLDPASS was always built in transient space (MPEXL_SYSTEM_ETC), and the SAVE could rename the file. Perhaps the space is allocated differently, or at least the file information is recorded on the local volumeset. HP hasn't figured this one out yet. Have a nice migration! I'm going to go get some sleep and let the scars heal, right after I burn the documentation for SQLMIG on the 980 at our local HP office. ======================================================================= Guy Smith Voice: 804-527-4000 ext 6664 Circuit City Stores, Inc. FAX: 804-527-4008 9950 Mayland Drive E-Mail: [log in to unmask] Richmond, VA 23233-1464 Private E-Mail: [log in to unmask] The thoughts expressed herein are mine and do not reflect those of my employer, or anyone with common sense.