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.
|
