1. Make sure your User Server and Data Servers are not running
   • Exit the OpenSpirit Launcher and select the bottom radio button to shutdown the User Server and all data servers.
   • If the OpenSpirit Launcher is not running, start it and then Exit as described above.
2. Create an empty file in your UNIX home directory called osp.debug. (touch ~/OpenSpirit/osp.debug)
   **note this file is just a trigger to add debug information into the regular OpenSpirit log files, nothing is written to this file.
3. Start the OpenSpirit Launcher and rerun your workflow.
4. Execute Step 1 again.
5. Execute the script $OSP_HOME/bin/etc/tarOSPlogs.sh and send the output file to support@openspirit.com.
6. Delete the ~/OpenSpirit/osp.debug file created in step 2, and delete the file created in step 5.

Note: Turning on debugging is not recommended unless you have been instructed to do so by OpenSpirit Support. Debugging output can generate massive log files, and server performance will be degraded.

If you have a data server that runs on the PC (Kingdom, Petra...) then to run in debug mode you need put an osp.debug file in C:\Documents and Settings\pc-id\OpenSpirit.

Just keep in mind that this should be an empty file, and the extension MUST be ".debug". After you run your workflow, the debug log files will be located in C:\Documents and Settings\pc-id\OpenSpirit\logs.

Here are some reasons why the Launcher might not be able to find your already-running UserServer, if it's running on a Unix machine.

• You must register a master account with OpenSpirit before you can run the UserServer. If the account's login ID for the Windows account does not match the UNIX ID, the Launcher will prompt you as to whether you will register as a new user (a new master account) or register an alias to an existing account. If you registered as a new user, you cannot go back and change it to an alias. You must delete the account, and then restart the Launcher on Windows to register the account as an alias. The OpenSpirit installation's Administrator account has a tool available for this, called the User Manager (userMgr.sh). Ask the Administrator to delete the Windows account, then re-register it as an alias to the UNIX account.
• When OpenSpirit is installed on a Windows machine, it sets two system environment variables that tell the underlying ORB layer how to communicate with the ORB daemon (OSP_HOST and OSP_PORT). These values are critical. The OSP_HOST value should be the IP address where the OpenSpirit shared services are running (this was determined when OpenSpirit was installed/configured on the Unix machine), and the OSP_PORT must match the port number that was entered when OpenSpirit was installed. If the OSP_HOST is a symbolic hostname, as opposed to an IP address, then the Windows machine often cannot properly resolve the hostname. This can be fixed by changing the hostname to an IP address, or by adding it to the system hosts file (usually in C:\WINDOWS\system32\drivers\etc\hosts ).

All the OpenSpirit servers are Java servers. To inspect what is happening with the server at any point in time, users can locate the server process id and issue the following command:

kill -QUIT   < process id >

This command will send a SIGQUIT signal to the Java process. This process will temporarily halt to check and print all deadlocks, dump thread stacks, and dump lock registry to the server log file before resuming execution.

The Java ORB has some Java VM properties for clients to set on their Java, CORBA servers:

-DORBwarn= < number > where number is between 0 and 2, inclusive. The default is now 2.

• 0 is to print nothing
• 1 will print the user defined CORBA exceptions and their stack traces
• 2 means to print both user defined and system CORBA exceptions as well as their stack traces.

-DORBdebug= < true | false >

False is the default. This option turns on additional ORB vendor debug messages.

Both of these options are set when you turn on debugging by creating a file called $HOME/osp.debug. See the FAQ for turning on debugging information in the servers.

To initiate these options for OpenSpirit Java programs running on the PC, edit a file in your PC's installation to set them for all programs. See the the FAQ on running OpenSpirit on a PC using VPN.

This recommendation appears because the account that owns the installation may at times require tasks that demand maintenance of the Oracle table space that is used by OpenSpirit.

Being in the DBA group does not give the account any special Oracle privileges; it just helps to define a division of responsibilities. If your policies and procedures do not allow or require this then it is not necessary.

Yes, there is. Below is a compressed file (storePassword.zip) that contain two files, a script and an jar file. You need to install this patch into your OpenSpirit Unix master installation. Below are the instructions:

1.   Install or use an existing OpenSpirit v3.1.x Master installation

2.   Verify Shared Services are down ($OSP_HOME/bin/runOSServices.sh stop)

3.   Unzip the storePassword.zip file into the $OSP_HOME/bin/etc directory. Two new files should appear:

      $OSP_HOME/bin/etc/storePasswords.sh

      $OSP_HOME/bin/etc/storePasswords.jar

4.   Setting the OSP property to disable UNIX password storage query

       a.  cd to $OSP_HOME/bin/etc

       b.  Run the storePasswords.sh script as follows:

               ./storePasswords.sh false

 5.   Restart the Shared Services

         ($OSP_HOME/bin/runOSServices.sh start)

 NOTE: OSP_HOME is the top level OpenSpirit master installation directory

                                 storePassword.zip