At 12:34 PM 11/3/1999 -0600, Jeff Woods wrote:
>It's ugly, but how about sizing the detail set just small enough to make it
>a non-jumbo set; then add as many record as will fit using autodefer; then
>expand the set with your favorite Jumbo aware database change utility and
>then add the rest.  The "rest" will still be slow, but at least the first
>4GB should move along as expected.  If there's 5GB of data, this may be
>worth it.  If it's 40GB, then nevermind.

Good work-around idea. Converting standard to jumbo master is a relatively
quick task so even with the extra steps this should be faster than building
the dataset through XM.


>The only other thing that comes to mind would be to experiment with trying
>to detach the posixland files from XM.
>
>As I recall there's a call that can attach a file to the XM, but I don't
>recall off the top of my head if there's a user-documented way to detach a
>file from XM.  I'm not even sure if there's a user-documented call to
>attach one, as I also don't recall how to do it at the moment, but I'm
>thinking there is and I'm just blank on how.

There is no user-callable method to detach from XM.  I seem to recall that
one uses FSETMODE to attach a file to XM by enabling the file for 'serial
write'... but I don't have my notes tonight so I can't be sure.


>The other possible tactic might be to try modifying the file label (or file
>label extensions or elsewhere stored, again I don't know off the top of my
>head where :) information of the files using PM debug or some such tool so
>that the flag(s) that indicate it is attached are off.  I'd strongly
>suggest using AUTODEFER on the database using DBUTIL before doing
>this.  This would seem to be the most "iffy" solution, but once figured out
>and documented could probably be used on every jumbo chunk file in short
>order.  And it's much less a kludge than my first suggestion.

Nope, won't necessarily do it.  If the GUFD entry is still valid it'll
still be attached to XM when opened as the existing GUFD entry will be used
when the file is opened and it won't be refreshed from the file label.
You'd need to 'flush' the GUFD entry or possible change the UFID for the
file which will cause the GUFD entry to not match and a new one built upon
opening the file, picking-up the XM data from the label.  And if you're not
real careful, you may lose any pending transactions in XM which have not
been posted to the file.  Would not suggest playing around with this,
especially
if a production file/IMAGE dataset....

Consider getting the patch(es) from HP when they are available...