|
|||||||
|
|||||||
|
|
|
|
|
|
|
|
 |
 |
 |
 |
|
Servers >> Landmark
Why did my OpenWorks or SeisWorks Data Server fail to start? There are a few possible reasons as to why your OpenWorks/SeisWorks Data Server fails to start. Check the data server log file for possible clues. If the problem is transient in nature, it could be that it is an OpenWorks license issue (i.e., too many people using too few licenses). If the problem starts right after the data store configuration, the problem may be traced to an invalid entry in the configuration such as OWHOME, ORACLE_HOME, TNS_ADMIN, OWSYSSID, etc. The administrator will want to make sure that any directory path entered in the Configuration Tool is accessible from its client environment using the syntax that he enters. Check with your administrator to make sure that the configured values are correct. If changes are made in the Configuration Tool that impact the data store being accessed by the data server,.then you must stop and restart your data server(s).
Why am I getting a Project definition file (.pds) not found in my Seisworks server? I'm getting an error similar to the following in my SeisWorks dataserver log; Caught exception ERROR: throwing the There are few possible reasons as to why this error may be occurring:
The most likely problem is the permissions on the xxxxx.pds file, do a 'chmod 666' and change it to -rw-rw-rw, and after doing that, the problem should be cleared up.
The OpenWorks data server uses the OpenWorks devkit to access the OpenWorks database. The devkit connects to the database the first time the database is accessed and the connection is maintained from that point on. If the database is restarted, or if the network goes down since the data server connected to the database, the data server can no longer retrieve data from the OpenWorks database. To correct the problem, you must restart the data server.
How do I make the OpenWorks Event Gateway work with multiple OpenWorks versions? As you probably know, running multiple OpenWorks installations simultaneously can be difficult. To assist in this, Landmark has provided the -i option to differentiate between sessions, but applications which are run outside of the OpenWorks Launcher don't automatically get that information propagated to them. Currently, this affects only the OpenWorks Event Gateway. The OpenWorks data servers are currently able to avoid the problem by not joining a session, but they can only avoid joining a session because they are not interested in sending or receiving OpenWorks events. Until Landmark differentiates between their versions more completely, the Gateway must compensate by examining the X root window properties Landmark uses for establishing communications between applications within a session. If a session is running that uses the same database instance, the Gateway will join that session. If not, a default session identifier of '985' for OpenWorks 1998.5 and '981' for OpenWorks 98p is used. Running more than one session against the same database instance will directly specify the session identifier in a file from your home directory, called ".osp_ow_session_instance". Now put the session identifier into that file by itself. It is only used if there are multiple sessions running against the same instance.
Why do I need two OpenWorks licenses when I run the OpenWorks Event Gateway? When you run OpenWorks applications, it checks out one license for each 'session' you run. Hence, if you run multiple versions of OpenWorks, each in its own named session (using the -i option), you will use one license for each session. In OpenSpirit, to avoid problems encountered when running in a multi-version environment, the OpenSpirit data servers for OpenWorks unset the DISPLAY variable before running. As far as OpenWorks is concerned, this places them in their own 'session' and hence requires a separate license. When you run the Event Gateway, however, it MUST set the DISPLAY and join a session to send and receive events. This session presumably has already been established by running the OpenWorks launcher as well as other possible applications. Thus, it is actually using the license that was already checked out when you started the OpenWorks applications, not the one used by the data servers. This technique can be changed, though it has not yet been fully tested. You must change the script in the OpenSpirit installation that is used to start the data server for OpenWorks. The script name is runOw****Server.sh, where **** is the version number. Two lines must be changed: Uncomment the line that calls the findOWSessionID function and comment out the line reading unset DISPLAY. (They should be close together.) See also: How do I make the OpenWorks Event Gateway work with multiple OpenWorks versions?
Why do I need two OpenWorks licenses when I run OpenSpirit and OpenWorks applications together? The reasoning here is the same as in the FAQ about two licenses being required to run the OpenWorks Event Gateway, and the fix is the same. See also: How do I make the OpenWorks Event Gateway work with multiple OpenWorks versions?
I've made a project set with a Seisworks 2003 (or OpenWorks 2003) project in and when I try to start up the Tab Selector in OpenSpirit I'm getting the following error: ld.so.1: /.../bin/sw2003java: fatal: libCstd.so.1: open failed: No such file or directory This is a known issue with OpenSpirit v2.3.4, involving the OpenWorks/SeisWorks 2003 data servers, which can be corrected in several ways. You can try some of the following:
After installing the file the OpenWorks/SeisWorks 2003 data servers will function normally.
If you cannot seem to get connected to OpenWorks R2003 and have tried to build the connection URL with OWSYSP instead of the OpenSpirit account that you created and still have the same problem, then try the following tst. Un-gzip and un-tar the following file into your OSP_HOME directory: This tester connects externally to an OpenWorks 2003 Oracle instance. You must supply the OpenSpirit data store name for a configured OpenWorks 2003 data store on the command line when invoking the script testOWJDBC.sh. For example, if your data store name is "owdb". $OSP_HOME/bin/testOWJDBC.sh owdb The script should be run from the same UNIX account that is being used to run the OpenWorks data server. The script sets the environment to pick up the type 2 JDBC driver in $OSP_HOME/external/Oracle/oci8 rather than the default driver. This is the driver used by the OpenWorks 2003 server to access the query manager account. If the tester cannot connect then you can un-gzip and un-tar this new driver: into $OSP_HOME and try the test again with the new URL tester. If the test still doesn't connect, please contact support@openspirit.com for further assistance.
IUnit errors are produced when trying to start a newly created OpenWorks 2003_12 project. The error looks like: Cannot obtain distance unit for project 'OW_SPIRIT'; call to untGetUnitAbbr('-1') returned 177600004. This is a bug from Landmark when creating new OpenWorks 2003_12 projects. In the unpatched OpenWorks 2003_12 the horizontal and vertical units code is created incorrectly. Old projects migrated from OpenWorks 98 or OpenWorks 2003 do not have this problem because their values were copied across. Only new projects created on the unpatched OpenWorks 2003_12 have this problem. This bug was fixed by Landmark in the patch 2003.12.0.1 push release. The patch from Landmark will fix any new projects created, however, you will have to use SQL to update a table for the newly created OpenWorks 2003_12 projects created before the Landmark patch is applied. According to Landmark: This is Defect 170663 fixed in the patch 2003.12.0.1 push release (This should be a CD you received around May or June 2004). The values in these tables for new projects created in 2003.12 will need to be updated. After applying the fix, new projects should be properly created. In order to fix the existing 2003.12 projects your OpenWorks administrator
must update the effected tables using SQL. The SQL should look like:
This is just a comment for the above line: Set the unit_id = 2, if the linear distance unit is feet. Depending on what Oracle account you use, you might have to put the
project name in front of the table name ow_prj_unit so it would look
like:
Some systems have a limit on the number of file descriptors a user can have open. This is particularly prevalent in SeisWorks 2d projects. Your OpenSpirit SeisWorks data server log will have something like: Created LineGeometry2d: sak_master 708648 This problem is most likely caused by the customer having too few file descriptors. A SeisWorks program is being executed to register the OpenWorks 2d line to the SeisWorks 2d project. This Landmark executable requires many file descriptors. Login into your UNIX account and execute one of the following commands:
It should look similar to one of the following: mickey:/users> ulimit -a
By default, OpenSpirit uses SeisWorks methods that take advantage of a SeisWorks memory cache. This results in faster performance but requires a lot of memory. The bigger the brick/compressed volume the more memory it will use. There are some workflows (e.g. copying the entire huge volume: 2000x3000x2251) where the SeisWorks server process space eventually gets over 2GB. The SeisWorks server crashes due to exceeding the maximum address space for 32-bit architecture (e.g. 2.174GB). Starting with OpenSpirit 2.8.1, the client has the ability to turn off the memory cache. To turn off the SeisWorks caching, first make sure you have OpenSpirit
2.8.1, or later. When you are sure, you have OSP 2.8.1,or later, edit
the $HOME/OpenSpirit/osp.config file and add the following line:
|
|
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
