Troubleshooting

You can use the following solutions to resolve common migration issues.

Running compiled migration scripts

You need to modify the common.properties file before you use compiled scripts. To use compiled scripts, make sure that the common.properties file in the $TOP/etc/default directory has the following setting:

script_execution_mode = compiled_only
You can disable script compilation for individual scripts by including the following directive at the beginning of the script:
script_execution_mode=not_compiled
However, disabling script compilation at the script level is not ideal because it leads to significant performance degradation. To avoid performance degradation when you use non-compiled scripts, change your server that is set to not_compiled rather than using the option of disabling compilation at the script level. If the server setting in the common.properties file is set to not_compiled, then the script compilation for individual scripts cannot be enabled with the script level directives.
Note: Using a combination of compiled and non-compiled scripts degrade performance, and is not ideal. However, if you must use this combination, there is a limitation: a non-compiled script can start functions in a compiled script, but a compiled script cannot start a function in a non-compiled script.

Common runtime errors and problems

There are known issues that you might encounter when you are running scripts. These examples illustrate some of those known issues and provide some insights on avoiding or resolving them.
Invalid argument type:
An invalid argument type occurs when you are passing the wrong type of argument to a function (for example, a HashMap when it requires a String). You can also receive an invalid argument type when IBM® Product Master cannot infer the type correctly. To resolve this issue, you might need to use a script operation such as checkString() to make the type explicit.
Mismatched argument types in comparisons:
If the same data type, such as ==, >, <, <=, does not appear on both sides of a conditional operator, the expression evaluates to false. If false, this does not result in an error message, but the corresponding code does not run. For example, the following does not work.
var id = “12345” ;
var my_id = item.getEntryAttrib(path to some attribute that is a sequence) ;
if ( id == my_id) {
// statements that need to be executed but won't be
}
The solution in this case is to explicitly use:
var id = “12345” ;
var my_id = checkString(item.getEntryAttrib(//some attribute that is a sequence),””) ;
if ( id == my_id) {
// statements to be executed
}
XML parsing:
The following code works in non-compiled mode and even in compiled mode when run from the script sandbox:
new XmlDocument(xmlDoc) ;
forEachXmlNode("item") {
// do the needful
}
However, in compiled mode, if this code is used in a script library function that is started by multiple users, then the statements inside the forEachXmlNode block do not run. However, there is no error message, but you can use the following code as a workaround.
var doc = new new XmlDocument(xmlDoc) ;
var xmlNode ; forEachXmlNode(doc, "item", xmlNode) {
//do the needful
}

Resolve runtime errors and problems

To resolve runtime errors on the appserver, see to the file svc.out in the appsvr log directory. Sometimes, examining the exception.log and the default.log might be helpful. With the Java™ file naming convention, it is easy to identify which script failed. The error message also identifies the line number in the generated Java file. To resolve the problem, view the generated Java file and scroll to the line where the runtime error occurred. The generated Java code now includes actual script code as comments every few lines. For example, consider the following portion of code from a sample-generated Java file:
// function checkIfPartyPartyTypeExist(party, partyType)
public static Object ScriptFunction__checkIfPartyPartyTypeExist(HashMap hmContext, Object party, Object
partyType) throws Exception
{
// var bRet = false;
Object bRet = (java.lang.Boolean) Boolean.FALSE; //
var rootEntry = party.getRootEntryNode();
Object rootEntry = GenGetRootEntryNodeOperation.execute(hmContext , (IEntry) party);
// var entryNodes = rootEntry.getEntryNodes(getCatalogSpecName() + "/Party Types/Party Type Code");
Object entryNodes = GenGetEntryNodesOperation.execute(hmContext , (EntryNode) rootEntry, (String)
BinaryOperation.execute(BinaryOperation.PLUS, ScriptFunction__getCatalogSpecName(hmContext), "/Party
Types/Party Type Code"));
// var entryNodesSize = entryNodes.size();
Object entryNodesSize = (java.lang.Integer) GenSizeOperation.execute(hmContext , (HashMap) entryNodes);
Each of the lines that begin with // in the comments previous are actual code from the corresponding IBM Product Master script. This indication makes it easy to identify where failure occurred in the script.
For recommended action on migration failures, see Troubleshooting migration issues.