Important dbcopy information (warning) regarding storelowercase switch
Over the past few months, I’ve had three different instances where customers reported to me that dbcopy was moving their files from the source location to the destination location. Since there is actually no specific switch in dbcopy to request a move, I was baffled. However, Novell has now figured out what the issue is!
If you run dbcopy with the -h switch, you see this particular listing:
-l Performs the GWCheck function of storelowercase only
When migrating to Linux, of course we want two things to happen: we want to migrate all files over converting them to lowercase, and when it’s over, we want a GWCHECK run that checks the guardian database (ngwguard.db) to ensure that this database also lists all files as lowercase. It is rare that an admin should need to run storelowercase on his/her own. A successful run of the -m switch against a post office includes the command to run the storelowercase, and so unless something goes wrong during the copy, it’s unlikely that this switch should need to be run manually. That said, because admins often run dbcopy -h to see what’s there, and see that lovely -l switch, it’s not totally surprising that some misunderstand the usage of this switch and decide to run the dbcopy with both -m and -l at the same time.
So, here’s the problem. A dbcopy with the -l switch should be run like this:
dbcopy -l -p <path to post office>
A general dbcopy to copy the post office in a migration typically looks like this:
dbcopy -m <source path> <destination path>
The dbcopy -l switch is designed to scan the post office directory to make sure all files are lowercase and then perform a gwcheck storelowercase operation at the end. During this process, there is actually some renaming and manipulation of the files in the post office, and when the -l switch is presented with both a source and destination path, it gets confused. At the end of the processing of the file, rather than putting the file back in the source directory, dbcopy errantly puts the file into the target directory.
When the 8.02 dbcopy ships, there will be a warning flag if someone attempts to run these two switches together. In the meantime, well just DON’T DO IT!
A TID is in the process of being created now, and when it is ready I will update here!
Danita
Thanks Danita, great explanation and very useful information.
Keep up the good work.
Hello Danita,
I have recently had a different issue with dbcopy. I am wondering if you have seen anything like this.
I was migrating from a NetWare source server to a SLES 11 x_64 virtual server. My dbcopy command looked like this:
First Pass:
dbcopy -f -m -k -p
Second Pass:
dbcopy -s -m -k -p
Customer also had a library.
dbcopy -b
What happened was that dbcopy transferred the offiles directory once using lower case on the destination and once using UPPER case on the destination. You can about imagine the issues this caused.
I had to open a case with Novell to resolve. It took 3 hours of unplanned down time but we did it. Thanks Kiran!
We have no idea what caused this issue.
Alas, if indeed you just did a
dbcopy -b
and not a
dbcopy -b -m
this would explain your issue. The blob copy will not automatically make things lowercase, so any time you are using dbcopy to ANYTHING Linux, remember that -m switch. That’s all I can think of that would cause your problem.
I once had a migration that we had to start all over, because someone decided to do a “repeat” of the first pass copy the next day (which is totally okay to do), but left out the -M switch. It was just easier to blow the copy on the Linux server away and start the migration all over at that point.