Invalid Command Name "makeUpocInstance"?

I saw a similar error when someone ran “mktclindex” in $HCIROOT/tclprocs.  Maybe that’s what happened to you.

As David mentioned running a mktclindex when in the $HCIROOT/tclprocs directory has the undesired effect of removing valid entries from the file $HCIROOT/tclprocs/tclIndex because some of the source TCL files are located in different directories.

Here are some of the entreis that will get removed that you can check for to see if they are missing from your $HCIROOT/tclprocs/tclIndex file; there maybe others but this will help you know if someone did a mktclindex in $HCIROOT/tclprocs.

What I did to help protect against someone running mktclindex in $HCIROOT/tclprocs was as follows:

cd $HCIROOT/tclprocs

cp -p tclIndex tclIndex_2008.09.09_original

chmod 555 tclIndex

If you confirm your $HCIROOT/tclprocs is missing the Java entries then you will need to try and recover the original tclIndex entires or file perhpas from HealthVision or cloverthech if you can specify which version of cloverleaf you need it for.

I have the original one for Cloverleaf 5.6 rev2 that runs on AIX 5.3.

I am struggling with the same error (CIS 5.4 Rev 1). I verified that all the Java entries are in the tclIndex, so this is not my problem. Even the Test tool gives me the error.

I have a case pending with HV Support, but they haven’t found the source of the problem yet.

sourceFilter /opt/quovadx/qdx5.4/integrator/tclprocs/../tcl/lib/tfc/cloverleafJava.tcl: Failed to source filtered file: couldn’t load file “/opt/quovadx/qdx5.4/integrator/bin/libcljava.sl”: exec format error

invalid command name “makeUpocInstance”

   while executing

“makeUpocInstance $className TPS $__userArgs”

   (procedure “cljTPS” line 14)

   invoked from within

“cljTPS {MSGID message0} {CONTEXT sms_ib_data} {ARGS {{CLASS HL7TPS}}} {MODE run} {VERSION 3.0}”‘

/usr/lib/dld.sl: Can’t shl_load() a library containing Thread Local Storage: /opt/quovadx/qdx5.4/integrator/clgui/java/lib/PA_RISC/server/libjvm.sl

/usr/lib/dld.sl: Exec format error

I noticed the name of the files in your error messages are having a problem with filenames that end in “.sl”.

For example:

    libcljava.sl

    libjvm.sl

I’m on AIX and my files end in “.so” and not “.sl”

For example:

    libcljava.so

    libjvm.so

You might want to do the following to see if filenames really end in “.sl” or “.so”

    cd $HCIROOT

    find . -name “libcljava*”

    find . -name “libjvm*”

This will help you determine if the calling module has a “.sl” typo that needs to be corrected to “.so”.

You can also check the permissions of the file to be sure they are proper.

Mine have the following permissions

    -rwxrwxr-x     hci     staff     libcljava.so

    -rwxrwxr-x     hci     staff     libjvm.so

Russ,

Thanks four the suggestion.

When I got those errors, I checked for file existence and file permissions.

We are on HP-UX and the library files end with .sl

My files have the same permissions as yours.

So far we have not made any progress.

I meant “Thanks for the suggestion”. I should read before clicking “Submit”!!!

Deborah,

It appears that the GUI test tool is looking at QDXI_CLASSPATH to find the java classes, while the site may be looking at CLASSPATH.

Can you verify that all the java classes present in QDXI_CLASSPATH are also present in CLASSPATH?

Usually, I set up all my classes in CLASSPATH, then simply make QDXI_CLASSPATH equal to CLASSPATH.

If you add new classes to CLASSPATH, you need to make the updated environment variable available to the hci user. I am on HP-UX and I just add a line to .profile.local.end and export the environment variable.

I found that if I added new classes to QDXI_CLASSPATH, I needed to add a line to the .profile.local.end file, then stop and restart the host server (hciss -k h, hciss -s h) to make the new classes available to the GUI tester.

Please try updating your CLASSPATH and see if it helps.