An important tool to use prior to SFG migration - sfgdbcheck
Ekmekvar 2700053NMH Visits (3393)
The Sterling File Gateway (SFG) product documentation explains the specifics of what to do in order migrate a SFG instance, but misses something in the planning stage. There is a tool named sfgdbcheck that can be used to tell you how well prepared you are to begin a migration. For the more recent versions of SFG, the tool appears in the
/<install>/bin directory as sfgdbcheck.sh for installations with a Linux operating system or in the \<install>\bin directory as sfgdbcheck.cmd for installations with a Windows operating system. The examples below will use the Linux style forward slashes in the names of paths.
The sfgdbcheck tool has a query function that searches through the database for SFG partners that are "inconsistent", meaning they are missing one or more objects that should be associated with a SFG partner that is well formed. It is run from a command line and it should be specified to output the results to an XML file. The sfgdbcheck query should be run prior to determining your schedule for a SFG migration. If the query returns either no inconsistent partners or only a very small number, then there should be no reason to add lots of padding to a migration schedule. On the other hand, if the query returns hundreds or even thousands of inconsistent partners, then you are going to need to do a great deal of work in order to get ready to do a migration and your migration schedule will need some padding.
In order to run the query function of sfgdbcheck tool, open a command prompt, then change directories to the /<install>/bin directory. After that type in something like the following and press the Enter key.
for Linux ./sfgdbcheck.sh -o inco
In the above, "inc
name do not have to be in the above order either. The only inflexible part of the file name is the file extension. It should always be .xml.
Once you have the output, look near the top for the following XML tag.
If you see a number like 15 there, you are in pretty good shape, but if the number is 1500, you are in pretty bad shape. If the number is 0, then there are no inconsistent partners, so you are in great shape.
There are multiple things that can make a partner inconsistent. The most import of them are as follows. A single asterisk in front of an item below means that this is something that can be fixed. Items with two asterisks in front are things that currently cannot be fixed. In that case it will be necessary to get as many of the partner details as possible, remove that partner from the resource tag for its community prior to exporting the community, and manually recreate that partner on the target system.
* having no association to a community [displayed as CommunityName=""]
For partners that are either a consumer only or a producer only, a consistent partner should have one of each of the double-asterisk items above, so it would show with, for example, the below if that item is okay.
Partners that are both a producer and a consumer should have two of each of the double-asterisk items, so would show with, for example, the below if that item is okay.
Also, even though the below normally appears as blank in the output, it is not something to be concerned about.
Here are other things that it is important to know about the sfgdbcheck tool and its output.
> The most important thing is that the tool has other functions besides the query function outlined above. Use of the other functions has the possibility of causing considerable damage if done incorrectly. Due to that, if a customer ever uses any of the other functions without direct supervision by IBM personnel, IBM reserves the right to not fix any problems that are created by doing so.
> There are multiple different ways in which partners become inconsistent, including, but not limited to:
> Of the things listed above that can make a partner inconsistent, any given inconsistent partner may have only one thing wrong with it, but may alternatively have any number of things wrong with it.
> If the inconsistency for a partner is one of the double-asterisk ones that cannot be fixed mentioned above, it will likely prevent the partner from working properly. Fortunately, the one-asterisk items are much more common the the double-asterisk items. Among the one-asterisk items above, the partner can still work fine with most of them. The one that can affect the daily usage of a partner is having LoginID="", but it will depend on how the partner is configured and used. The other one-asterisk inconsistencies will usually only be a problem at migration time, not in daily use of the partner.
> More often than not, if there are a lot of inconsistent partners and the great majority of them all have the same inconsistency, it will be because of a flaw in the overall partner implementation process being used, and that flaw will need to be identified and the process changed.
> The LoginID="" and MailboxName="" inconsistencies can be fixed in the GUI without supervision by IBM once you know how.
We encourage you to use sfgdbcheck as a tool to estimate how much time a migration may take. Please open a support case with IBM if you get sfgdbcheck output with inconsistent partners.