UTF-8 not picked up by cloned OD56sp1/suse9 rcv

catorarn

Setup:
OD56SP1 on receiver on Suse9.2 Linux

On my Suse92/OD56SP1 test machine I managed to reset the file encoding type to UTF-8 while the locale on the server by changing
/usr/iw-home/OpenDeployNG/startod slightly.

This is what I have now:

else
# -- for Solaris and Linux
DEPLOYAPI_AGENT_CMD="$JAVA_EXE -Dfile.encoding=UTF-8 -Xss2m -classpath $JAVA_CLASSPATH -Djava.library.path=$JAVA_LIBRARY_PATH -Djava.rmi.server.hostname=$RMI_BIND_IP_ADDR -Djava.rmi.server.codebase=$JAVA_RMI_CODEBASE -Djava.security.policy=$DEPLOYAPI_POLICY_PATH -Dinterwoven.deployapi.locator=$DPELOYAPI_SERVICE_LOCATOR -Dod.home=$IW_ODHOME com.interwoven.deployapi.service.IWODServiceServer $DEPLOY_CFG_PATH"
fi
fi
$ECHO DEPLOYAPI_AGENT_CMD $DEPLOYAPI_AGENT_CMD

I am aware that this is an unofficial hack, but it is hopefully serving as a workaround until we get further down into the specifics on why on this machine the java vm is not picking up the locale as it should do. Question, you have more webservers (OD receivers on suse 7.1) cloned that do not have this issue? I wonder if OpenDeploy actually needs to be installed on a machine instead of cloned over.

Anyone can answer the question why the odstart file does not pick up the UTF-8 encoding type on one linux server while on all other cloned systems OD does not need an explicit reference in startod to startup with the server locale (which is on all systems the same en_US locale for all users).

thanks,

catorarn

Migrateduser

Support for SuSE Enterprise 9 is on the OD roadmap, but not supported. Feature request 56144 is on file to track demand.

Customers interested in this platform can let me know or contact Tech Support to register interest.

Todd Scallan
Director of Product Management
Interwoven
t: 408-530-7167
e: tscallan@interwoven.com