Is this a dependency required by LMS/CM UT? It's rather ambiguous that its absence is currently preventing the browser GUI from exporting the UT data, while CLI export is fine. The latter route is not an option for most end-users, nor desirable from the administrative standpoint.

It is a dependency required by utcli on Solaris. We recommend people install the SUNWCall cluster which includes this executable.

Would a dummy (empty) native2ascii make the GUI export successfully, the error message notwithstanding? I suppose there's a reason this binary or the full SUNWCall package was no longer installed on our Sol 10 build.

An empty file would still cause breakage. At the very least, you'd need something like the attached.

Thanks. If a blank one won't suffice, I might as well try to justify the bona fide native2ascii.

The option currently on my table is to have SUNWj5de installed into an alternate location (outside of /usr/java/bin or /bin), and point LMS/RME's JAVA_HOME variable to that location. My chief concern with this approach is this would address the "native2ascii" issue but introduce a host of other "[binary] not found" problems. The SUNWCall package is very large, and it's by design that it's not fully installed.

This would not work. The solution is to make sure a native2ascii is in the PATH. This is why the symlink or executable needs to be in /bin or /usr/bin. In a future release, it will be included in /opt/CSCOpx/campus/bin.

Could casuser's PATH be modified to include /custom/location/native2ascii? That would seem the least painful solution, if possible.

You would have to modify PATH in the pkgparam file for CSCOmd.

Great! I'll give that a shot. Would dmgtd need to be restared to pick up the PATH change? Could this workaround potentially get overwritten by later LMS patches?

Yes and yes.

The PATH mod works great on my test box. Which release would come bundled with native2ascii, RME 4.3?