These errors showed up when attempting a multitool mkreplica. The reason for the error is
unknown at this time. A dbcheck, checkvob and reformatvob came up clean.
Rational tech support suggested capturing the data via clearexport and deleting the VOB.
However, I don't recommend doing that unless it's an extreme case.
# ct checkvob -pool -source vob-storage-path
# cd vob-storage-path
# ct lock vob:vobtag
# dbcheck -a -k -p8192 vob_db > c:\temp\dbcheck.txt
I ran into this error again years later. This time support suggested, aside from running
the dbcheck, to reformat dump the VOB database and reformat load it. If that doesn't solve the
problem, try removing all the HyperSlink hyperlinks that may be in the VOB. This is possibly
related to defects CMBU00031152 and CMBU00031153.
# cd vobtag
# ct rmtype -rmall hltype:HyperSlink
Back to the INDEX.
multitool: Warning: Version mismatch, software:3.0, packet:1.2
This is simply telling you that you are using a 3.x feature level VOB on a
system installed with CC 4.x. It is only a warning and does not affect performance.
If you want to upgrade the 3.x VOBs to feature level 2, see
chflevel.
Back to the INDEX.
multitool: Error: Sync. packet packet was not applied to VOB vobstorage
This error can occur when attempting a "syncreplica -import" and there is a previous packet
that has not been applied to the VOB. That is, the first epoch number in this packet does not
immediately follow the last epoch number known to this VOB for that replica. There is a missing
packet update somewhere. You will need to
retransmit the missing packet from the originating VOB replica.
Back to the INDEX.
multitool: Error: Store-and-forward server "/usr/atria/etc/shipping_server" failed with status 1
This error occurred when syncing two replicas that are on the same server in the same
region. This is NOT a supported configuration. Having two replicas of a VOB in one region leads
to problems between views and such. However, it's unknown what the shipping_server was actually
complaining about, as the syncs were sent ok and applied correctly.
Back to the INDEX.
multitool: Warning: To avoid name conflict, generated name "replica-name:type-name" for metadata-type type object.
Because two sites can inadvertently name a type with the same name, the syncreplica import
renames the imported type. See
"Handle type naming conflicts"
for a work-around.
Back to the INDEX.
multitool: Error: Object is in unexpected VOB: "replica@vobtag".
While one has the ability to create multiple replicas of a VOB in a single command,
all of those replicas must be copies of the same VOB. For example, you cannot, in a single
command, replicate a UCM component and its PVOB.
Back to the INDEX.
multitool: Error: Unable to access "C:\Program": No such file or directory.
On Windows, if you give an argument to multitool, such as the path to an import packet and that packet's
path has any spaces in it, you will get this error message. Basically it thinks that the argument
ended between Program and Files in "C:\Program Files\rest-of-path". Simply run the command again
with double quotes around the path argument.
Back to the INDEX.
shipping_server.exe(PID): (client=sending-hostname)/ks/sysutil: Error: Can't exec "-d -o rcving-hostname": The system cannot find the file specified.
This error is seen in the shipping_server log file on a Windows machine. It occurred when
importing a sync packet automatically using the out-of-the-box (CC 4.2) receipt handler. For some
reason, the path to the incoming packet was not being passed to the receipt handler correctly. Since
there was a space in the path, the shipping_server didn't pass any of the packet name to it; hence the
extra spaces between the -d and -o in the error message.
The reason for the error is still unknown. The work-around was to use the scheduler to
import packets as specified times instead of automatically. Another work-around might have been
to move the shipping bays to the root of the C: drive, thus avoiding the space in "Program Files".
Also, ensure DOS "short name" resolution is set for the file system. It should be by default, but
can cause problems if disabled.
Back to the INDEX.
multitool: Error: Store-and-forward server "D:\Rational\ClearCase\bin\shipping_server" failed with status 1
Updated: 01/16/12
Version: 7.0.1.8
This error occurred when attempting to -fship a new replica.
The remote machine can be ping'ed. VOBs and views can be created on the remote machine,
so the albd is running. The two machines are in different CC regions. There are no Windows event
viewer error entries nor any CC shipping, error, or sync_export log error entries.
The problem was the remote server was running ClearCase, but the MultiSite component
wasn't installed. Unfortunately, there were no indications of the actual problem from the
sending side ... as usual.
Back to the INDEX.
multitool occasionally hangs on syncreplica -export
Updated: 04/03/12
Version: Windows XP, CC 7.0.1.8
This error occurred occasionally when running "multitool syncreplica -export ...".
There was no obvious error message. It just hung and the multitool command had to be killed
from within the Task Manager. This was accompanied by db_vista errors in the "syncmgr" log.
The solution was to increase the lock manager values from "a almd -f 256 -u 256 -q 1024"
to "-a almd -f 1018 -u 1024 -q 2048".
See http://www-01.ibm.com/support/docview.wss?uid=swg21125258
on how to change the values. Reboot after making the change.
Back to the INDEX.
multitool: Error: Cannot find replica creation packets with sequence numbers 1 through 1
Updated: 07/10/12
Version: Windows XP, CC 7.1.2.4
This error occurred when attempting to import an initial VOB replica. The PVOB imported without
issue.
The initial replica creation generated two packets for the VOB with "_1" and "_2" extensions
because the server was set to have a packet limit of 2GB. For an unknown reason the "-fship" option failed to
send the first 2GB packet, but did auto-send the second 1.5GB packet. The solution was to manually copy the
"_1" packet to the remote server.
Back to the INDEX.
multitool: Error: Replica "replica-name" already exists
Updated: 08/06/12
Version: Windows XP, CC 7.1.2.4
This error occurred when attempting to import an initial VOB replica.
The mkreplica import command was run and then aborted when it asked for a registry password.
The import command was run again without -public. However, it had already created the VOB storage
directory. To restart the import, unregister and then delete the VOB storage directory.
1) ct unregister -vob VOB storage directory
2) Stop the CC services.
3) Delete the VOB storage directory.
4) Restart the CC services.
5) Run the mkreplica import command again.
Back to the INDEX.
multitool: Error: Replica is not served by the local host
Updated: 02/14/13
Version: 7.1.2
This error occurred when attempting to run a syncreplica command from a computer other than the VOB server itself.
The syncreplica command can only be on the VOB server.
Back to the INDEX.
multitool: Error: Trouble opening VOB database: "VOB tag".
Updated: 08/28/13
Version: 7.1.2.4
This error was occuring for all VOBs that had incoming packets waiting.
The root cause is unknown.
Restarting CC didn't help. Restarting the server didn't help. Reinstalling CC worked.
Back to the INDEX.
multitool: Error: Bad oplog entry descriptor checksum. expected 0xf0ccfa59, found 0x72000000
Updated: 08/28/13
Version: 7.1.2.4
This error occurred when attempting to run a syncreplica import on a backlog of sync packets.
The root cause of the error is unknown. It may have had something to do with the error just above.
The solution was to delete all the packets in the ms_ship\incoming folder, reset the epoch numbers at the sending site,
and then resend new packets.
Back to the INDEX.
ejostrander@cox.net
Return to the home page .
This page last modified: 08/27/2020