WOW Release Notes PDF

WOW R2003.3.1.
5
Release Notes and Administration Manual
Contents
Introduction ..................................................................................................................................... 2
Major Changes in Version R2003 ................................................................................................. 3
Previous Enhancements and Fixes............................................................................................... 5
Enhancements and Fixes in this Version (R2003.3.1.5)............................................................ 10
Pre-Installation Planning .............................................................................................................. 11
Installation..................................................................................................................................... 13
Configuring Security Options ....................................................................................................... 18
Configuring Multiple OW_PMPATHs .......................................................................................... 21
Configuring Multiple Oracle Instances ........................................................................................ 22
Configuring Subscription Tools and Email.................................................................................. 23
Customizing the WOW Interface................................................................................................. 24
Browsing Unix Directories............................................................................................................ 25
Adding External Links................................................................................................................. 26
OpenWorks QC/QA Queries ....................................................................................................... 27
Changing Default Well Name Display......................................................................................... 28
WOW Documenter....................................................................................................................... 29
Integrating with CDA .................................................................................................................... 33
Referencing External Documents for SeisWorks 2D ................................................................. 35
Creating Live Trace Outlines...................................................................................................... 36
Using ZGF Backdrops.................................................................................................................. 39
Customizing Choice of Color Maps............................................................................................. 40
Customizing the Well, Field and Lease Modules ....................................................................... 41
Customizing the Key Facts Module ........................................................................................... 42
Customizing the Comparison Module......................................................................................... 43
OpenJournal Integration .............................................................................................................. 44
OpenExplorer GIS Integration ..................................................................................................... 45
ArcIMS Integration........................................................................................................................ 47
Viewing CGMs in WOW............................................................................................................... 48
Maintenance and Troubleshooting.............................................................................................. 49
Appendix 1: Typical wow.env File ...............................................................................................50
Appendix 2: Summary of Important Files.................................................................................... 53
Appendix 3: WOW Architecture...................................................................................................57
Appendix 4: Apache Installation Options .................................................................................... 58
Appendix 5: Background on the Devkit Shell lmksh ................................................................. 69
July 2004 Part No. 159509 R2003

Introduction
WOW provides dynamic access to E&P data over the company intranet. The product
addresses one of the biggest challenges facing the E&P business: making the right data
available to business users in time to facilitate decisions. Because subsurface
professionals spend too much time on non-productive data management tasks, WOW
allows users to quickly find, document, manage and QC vital project data:
Find data fast: rapid web-based browsing of projects - great for familiarizing users
with a new project area.
Find data easily: a uniform interface shelters users from the underlying applications,
databases and systems.
Capture knowledge: allow users to document projects, providing context to enhance

the content.
Cleanup project data: a raft of functions for managing the underlying data.
WOW is part of Landmarks WebApps1 technology framework. It is a 'thin client'

application, which means that the majority of content is generated dynamically on the Web
server by reading the underlying databases, formatting and then sending results to the
Web browser. This means also that there are no client-side dependencies, i.e. plug-ins to
be downloaded or installed, considerably simplifying maintenance.
WOW coverage is considerable and expanding in both depth and breadth:
OpenWorks
SeisWorks
Z-MAP Plus
GeoProbe
VIP
OpenJournal
SEG-Y files
LAS files
OpenExplorer (ArcView) shapefiles and DBF files
Archives (from Corporate Data Archiver - licensed separately)
Geolog (licensed separately)
GeoFrame (licenses separately)
1
WebApps is the shared architecture and software directory name for the following products: WOW (including GeoProbe
and VIP modules), Corporate Data Archiver (CDA), WOW for Geolog and WOW for GeoFrame.
Geolog is a registered trademark of Paradigm Geotechnology B.V.
GeoFrame is a registered trademark of Schlumberger.
WOW R2003.3.1.5 Release Notes Page 2 of 71 July 2004

Major Changes in Version R2003
A number of configuration changes have been made to WOW for the R2003 release.
These are summarized below:
Use of Native Apache
Apache version 1.3 is now distributed as an optional package with the Solaris 8 operating
system. Consequently, WOW is no longer distributed with its own version of Apache, with
the following implications:
Root is required for part of the install. The installation script builds a root.sh file with
the required Apache configuration commands. Installation cannot be completed
without the execution of this script by root.
The Apache password file, required for WOW security, is now moved to the
/etc/apache directory and also requires root to be updated. This considerably
tightens WOW security.
Since Apache is now started as root, the default HTTP port of 80 can be used, which
in turn means that no port need be specified in WOW URLs.
The actual Apache cgi-bin directory, /var/apache/cgi-bin, is not used by WOW.

Since this directory is owned by root, Landmark has implemented the dynamic parts
of WOW as an alias to a non-root directory under the WOW installation:
<apache>/cgi-bin becomes <WOW>/cgi-bin, aliased to /cgi-bin-wow in the
browser (R2003.0 versions) or /bin (R2003.3 versions).
The actual Apache web root directory, /var/apache/htdocs, is not used by WOW.
Since this directory is owned by root, Landmark has implemented the static parts of
WOW as an alias to a non-root directory under the WOW installation:
<apache>/htdocs becomes <WOW>/htdocs, aliased to /wOW in the browser
(R2003.0 versions) or /wow (R2003.3 versions).
Restructuring of WOW Directories
The Apache change has enabled an overall simplification and rationalization of the WOW
directory tree, with the following changes:
The R98 WOW directory contained a TclApps and an apache directory; it is now a
single flat structure referred to as $WOW_HOME, set to $OWHOME/WOW (R2003.0
versions) or $OWHOME/WebApps (R2003.3 versions).
In general the directory structure of WOW has been modified to look more like any
other Landmark application, with install, conf, bin, templates directories etc.
All configuration files have been centralized in a new $WOW_HOME/conf directory.

These files have all been made more consistent to support future Web-based
modification. The most significant change is that the old <apache>/cgi-
bin/server_env file has been replaced by $OWHOME/WebApps/conf/wow.env.

Implemented R2003 OpenWorks Security Model
OpenWorks R2003 changed the Oracle access method considerably. Landmark has
modified WOW to support these changes, so that logins to the database are now always
as the WOW Oracle user rather than as the OpenWorks project. Additionally, LMSYS
logins are no longer used. The WOW user should not notice any difference.
New WOW Security Model
The R98 5-layer security model in WOW has been simplified to a 3-layer system. The
product now allows for:
Level A: universal read-only with named exclusions, no write-back allowed
Level B: universal read access with validated write-back
Level C: validated read and write-back (emulates native applications).
Level B or C security is now turned on by default during installation for the user doing the
install. See the Security section for more detail.
Simplified Installation Script
The WOW installation script $OWHOME/WebApps/install/WOWInstall now takes

command-line arguments as per standard Landmark applications, i.e. WOWInstall o
$OWHOME. The installation has been streamlined to ask fewer questions and complete
more activities, e.g. create Z-MAP Plus and OpenJournal directory links and turn on
security.
Rationalized style sheets / Dynamic framework
These changes will simplify the future enhancement of WOW, and make for a more robust
patch process.
Multiple OW_PMPATHs
The handling of multiple OW_PMPATHs has been made more generic. A simple custom
OW_PMPATH scenario is now the default, rather than CAI.
FlexLM Licensing / Source Code Compilation
R2003 WOW now uses regular FlexLM licensing. The browser simulates continuous
usage using the FlexLM linger function. Licenses are checked back in after 20 minutes of
browser inactivity. As part of this process, all Tcl source code in the procs and cgi-bin
directories is now compiled and is no longer viewable as plain text.
Improved Error Reporting
In the event of a WOW error occurring, the user now has access to the Apache error log
and the WOW environment through a link on the WOW top bar.

Previous Enhancements and Fixes
Version R2003.0.1
1. OpenWorks: added a navigation bar, similar to the SeisWorks module

2. OpenWorks: new summarize option to display data counts across all projects
3. OpenWorks: new option to run QC/QA queries across projects
4. OpenWorks: 5 new QC/QA queries
5. OpenWorks: truncate QC/QA results to 500 rows per query
6. OpenWorks: only display projects a user has access to if level C security
7. OpenWorks: added well lease name/number to well header and comparison
8. OpenWorks: added elevation type and value to comparison
9. OpenWorks: added field interests and lease status/type to filter options
10. OpenWorks: added axes to checkshot, wavelet and synthetic graphs
11. SeisWorks: horizon count on summary page corrected
12. Documenter: extended documenter remarks to 2000 chars
13. Documenter: added create and update user and date to all Documenter tables
14. General: added file filter, sort and save to all directory-parsing modules
15. Z-MAP Plus: display first 500 points of large DATA files
16. SEG-Y: added axis labels and decimate/interpolate options
Enhancement #132498: modified crontab to run at 4am on days 2-6

Enhancement #132800: allow sort, filter and save on OpenWorks external file listings
Enhancement #601120, 304814: increased documenter comments from 80 to 2000 chars
Enhancement #601147: added support for hyperlinks in seismic documentation
Enhancement #304809: scripts provided to move kdoc data between projects
Enhancement #304826: save MFD/ZGF contents to file/Excel
Enhancement #128370: save query results to file/Excel
Defect #133596: push for seismic does work
Defect #132823: fixed error in linediv message
Defect #130222: ZMAP dependencies on SeisWorks plist.dat removed
Defect #121936: Tcl script error with APM fixed
Defect #133138: ZMAP data files with no points now display OK
Defect #132456: improved documentation importing grids to ArcView
Defect #129005: prevent browsing above ZMAP/OJ start location
Defect #128920: browsing directories with + in directory path now OK
Defect #305035: checkshot label change
Defect #133596: push for seismic navigation works
Version R2003.0.1.1
Defect #135965: Push email points to wrong URL

Defect #136165: KDoc OWSYS copy sqlscript missing
Defect #136168: Incorrect URL sent from Push email
Defect #137632: Cannot compare projects without manage access to both
Defect #137990: ArcView extension points to wrong URL
Defect not reported: ZMAP->ArcView grid export fixed
Version R2003.0.2
1. GIS: add ArcView shapefile viewer module

2. GIS: view/save shapefile coordinates and database

3. GIS: save pictures with world files for use in ArcView GIS
4. LAS: add LAS viewing module with curve graphs
5. OpenWorks: option to export multiple curves in LAS format
6. OpenWorks: compare 2D navigation
7. OpenWorks: new pick analysis matrix view
8. OpenWorks: new curve analysis matrix view
9. OpenWorks: compute and display velocities from time-depth tables
10. OpenWorks: extend cross-project search to picks by name / interpreter
11. OpenWorks: add a vertical section view to position log graph
12. OpenWorks: filter leases by quad/block, class, status, type
13. OpenWorks: filter wells by log curve name, curve source, pick interpreter
14. OpenWorks: filter curve comparisons by curve type, picks by interpreter
15. Push: add WOW documenter data
Version R2003.0.3
1. OpenWorks: Coverage of TDQ models plus external binary data

2. OpenWorks: Ability to compare projects across SIDs
3. OpenWorks: QC/QA query results can be saved/download to Excel
4. OpenWorks: QC/QA queries now support seismic navigation queries
5. OpenWorks: Allow change of default well name display, e.g. UWI or CWN
6. SeisWorks: New workflow for 2D seismic handling
7. SeisWorks: Coverage of mapping (dts) files
8. SeisWorks: Export horizons to table/Excel with specified decimation
9. SeisWorks: Export seismic navigation to table/Excel with specified decimation
10. SeisWorks: Export single seismic trace to table/Excel
11. SeisWorks: New layout for accessing seismic/horizon documenter records
12. SeisWorks: Allow adding/deleting of Documenter R table entries through the browser
13. SeisWorks: Allow choice of short, project or directory color maps lists
14. Push: support for SeisWorks horizons and seismic
15. OpenExplorer: View and browse contents of .par files in Shapefile module
16. OpenExplorer: View contents and drill down into .apr file contents
17. OpenExplorer: allow editing of KRS document name, comments and hyperlink
18. General: New customizable left frame options for OE and Other Data
Version R2003.0.3.1
1. OpenWorks: added general support for multiple Oracle instances

2. OpenWorks: added optional filter of wells by pick name
3. OpenWorks: display tolerances in comparison results (#130055)
4. OpenWorks: option to save project counts summary page (#136085)
5. SeisWorks: live trace outlines now write ZGF to1st OW_PROJ_DATA dir (#131112)
6. SeisWorks: for 3D, optional rigorous command-line live trace outlines (#133197)
7. SeisWorks: for 2D, added line navigation detail drilldown
8. SeisWorks: for 2D, list lines which have interpreted a specified horizon
9. SeisWorks: for 2D, display a line/proclev matrix for the master project
10. SeisWorks: for 3D, added line name to seismic image preview
11. SeisWorks: simple support for viewing .cd file headers (#142005)
12. SeisWorks: added tabular editing of horizon/seismic documenter records
13. SeisWorks: ability to set up bulk horizon rename/delete actions
14. Z-MAPPlus: added XML-based MFD/ZGF documenting through the browser
15. General: Allow editing of all WOW configuration files through the browser

1. Trapped bug when the push_output directory does not exist
2. Trapped bug when KDoc OWSYS extension not created
3. Fixed general pointset display error
4. Fix to allow very large velocity models to be viewed
5. Fix to script Do3DSeismaps generating live trace outlines (#143709)
Version R2003.3.1
General configuration changes: the WOW parent directory has been renamed from
wOW to WebApps. In addition, the WOW htdocs directory is now aliased to wow rather
than wOW, and the cgi-bin directory is now bin rather than cgi-bin-wow. The various
devkit shells have been replaced with a single integrated lmksh shell.
WOW R2003.3.1 is a point product release. WOW must be reinstalled.
1. OpenWorks: added support for executing WOW QC/QA queries with variables
2. OpenWorks: editing/documenting of OpenWorks remarks columns in the browser
3. OpenWorks: module to match wells between projects with different UWI conventions
4. OpenWorks: add row counts to VC_ and R_ tables
5. OpenWorks: project comparison will now compare counts for well-related data types
6. OpenWorks: batch utility to do coordinate transformation on a file (#133205)
7. OpenWorks: project comparison will warn if CRS is different between projects
8. OpenExplorer: improved KRS handling with editing of metadata tables in the browser
9. OpenExplorer/OJ: allow linking of OpenJournal documents to the KRS
10. SeisWorks: option to save live trace outlines to shapefiles
11. SeisWorks: changed approach to handling multiple districts using cookies
12. SeisWorks: seismic info now shows bricking/compression parameters
13. SeisWorks: 3D horizon info shows horizon file size, owner, create and modify dates
14. SeisWorks: navigation info now shows project depth unit and datum
15. SeisWorks: 2D navigation info now shows 2D project total line length
16. SeisWorks: 2D horizon info now approximates %coverage using line counts
17. SeisWorks: documenter now defaults 2D horizon file owner from horizon header
18. SeisWorks: documenter now auto-populates horizon create date
19. General: Linux port
20. General: support for viewing CGMs added requires client configuration
21. General: quick view of DGN files in WOW (excluding text)
1. Large ZMAP non-grid datasets can now be displayed without memory issues
2. Fixed error when viewing grids, pictures and datafiles with a '+' in the name
3. Fixed error when executing a stored OpenWorks query with more than one variable
4. SeisWorks seismic info no longer opens all volume extents
5. Fixed ZMAP to ArcView grid converter failure - requires ArcView3 feature (#150909)
Version R2003.3.1.1
1. OW: added extra attributes to KRS document detail display

2. OW: support for non-float32 log storage and TVDSS logs (#149557)
3. SW: added sorting of 2D seismic lines
4. SW: added option to reference external text file for each 2v2 file (#156392)
5. AV: functionality to convert ZMAP to ArcInfo grid formats moved into WOW
6. Other: Added file for implementing NIS passwd authentication

1. OW: LAS export of selected curves was picking the wrong curves (#152838)
2. OW: Extra customizable well header attributes (#152389)
3. OW: Fixed incorrect well_table.dat.default (referenced log_crv_hdr)
4. OW: Fixed QC/QA query with variables bug where no text value entered
5. OW: Fixed errors with aperiodic and negative-valued curves (#153874/153880)
6. SW: Incorrect top navigation bar when viewing 2D master project files (#601453)
7. SW: Fixed unsupported BulkHrzRename/Delete functions
8. SW: Fixed inconsistencies and documentation for seis2png/seis2png2 (#154712/4)
9. SW: Fixed seismic display of 3dvs with a '+' in the name (#156285)
10. SW: Fixed 2D navigation save to only save specified line, not all (#156280)
11. SW: Fixed error in locating colormaps where COLOR_SOURCE1=project (#158714)
12. SW: Can display SEG-Y files > 2Gb, but not file attributes (#156891/153133)
13. ZM: Don't create .xml files unless user documents the MFD/ZGF (#157845/154350)
14. AV: Replaced corrupted ArcView extension file wow.avx (#153028)
15. AV: Changed storage of WOW GIS image backdrops to subdirectory (#157154)
16. OJ: OpenJournal browser was not detecting R2003 OJ projects
17. OJ: Fixed errors in OpenJournal search and links (#153134)
18. Other: Fixed stylesheet errors for Netscape 7
19. Other: fixed WOWInstall URL display error and permission check (#305984/158689)
20. Other: Improved WOW left frame cosmetics (#157878)
Version R2003.3.1.2
General integration changes: In this release the integration between WOW and
Corporate Data Archiver (CDA) is significantly improved, as described below.
1. WOW is now a prerequisite for CDA. The CDA web interfaces now check out a WOW
feature, rather than a CDAWEB feature. Clients with CDAWEB licenses will obtain a
WOW license for every CDAWEB license.
2. An Archives option has been added to the WOW left frame which will display the
CDA lite web interface, allowing users to browse archive data alongside live projects.
3. It is now possible to create control files and execute the archive creation from the
WOW OpenWorks and SeisWorks project summary pages, provided the site has a
CDARCHIVER license. This executes the same functions as the Unix archiver GUI
4. Thumbnails generated in a throwaway project called 'Stubs' are reused in the WOW
horizon and seismic documentation pages, simplifying the documentation process.
The large images are reused in the seismic and horizon detail pages.
5. It is now possible to create horizon and seismic lists in WOW, via a paginated GUI
which displays a user-modifiable number of objects at a time. These page views will
also reuse thumbnails from an existing Stubs project.
6. Horizon and seismic list-deletion command-line utilities are provided to delete all
objects in lists created using the above list builders.
7. A GeoProbe Information Manager module has been added, which provides
functionality for browsing, searching, documenting, cleaning up and archiving
GeoProbe project data. The archival component supports rich metadata extraction
both in the Archiver GUI and from within the WOW browser.
8. An ArcGIS .dll has been added, providing substantially the same functionality as the
current WOW ArcView extension. This allows users of ArcGIS to launch WOW/CDA

in context by clicking on objects in shapefiles created by OpenExplorer and CDA. See
$OWHOME/WebApps/gis/arcgis.pdf for further information.
Other enhancements and bug fixes:
1. OW: fixed error in comparison saving well list to project 2 (#159311)

2. OW: added pick observation number to pick export page (#160600)
3. OW: show correct TD table used on pick export page (#160601)
4. OW: Add UTM zone to CRS info display
5. SW: fixed no data found error in SeisWorks subscription module (#162020)
6. SW: Increased SeisWorks trace length limit from 4001 to 7001 samples
7. SW: fixed 2D live trace outlines: was highlighting the wrong line in yellow
8. SW: Improved performance on SeisWorks multi-horizon documentation page
9. SW: added caching of 2D seismic file names to speed up 2D proclev listings
10. Other: Improvements to ASCII viewers to show all data, and to download/save
11. Other: Increase length of ASCII files displayed in WOW to 1000 lines (#161549)
12. Other: LAS viewer option to view raw data and to download/save file
13. Other: Standardized date formats as YYYY-MM-DD, e.g. 2003-07-23
Version R2003.3.1.3
1. Changed SeisWorks project details table to display in right frame

2. Added option to sort/save SeisWorks project details table
3. Allow 3D volumes with master grid mismatches to process
4. Added support for displaying 3D traces (crosslines)
5. Added project name to SeisWorks live trace outline shapefile
6. Added option to seismic detail popup to change seismic
7. Added option to ZGF viewer popup to change picture
8. Added option to MFD viewer popup to change file
9. Added original coordinates/CRS to OpenWorks 3D survey report
10. Added option to display all OpenWorks 3D surveys in a table
11. Added link from SeisWorks 3D navigation page to OW survey page
1. Fixed SeisWorks timeslice image creation failure

2. Fixed SeisWorks time slice label and added line/trace axis labels
3. Fixed seismic trace annotation bug when internal X = line
4. Flipped seismic images color mapping to match SeisWorks
5. Removed hyperlinks from WOW SeisWorks project summary if count=0
6. Fixed SeisWorks documenter error when using apostrophes
7. Added SeisWorks documenter field length checking
8. Fixed error in saving OpenWorks QC/QA results for > 500 rows
9. Fixed saving OpenWorks QC/QA query results with variables
10. Fixed hyperlink from OW pick/curve matrixes to multi-well detail
11. Added warning if pick/curve matrixes > 256 columns (Excel limit)
12. Changed OpenWorks well comparison to handle null poslog offsets
13. Remove most dependencies on knowing OWSYS/OWSYSP passwords
14. Fixed OpenWorks velocity model error on small TDQ models
15. Detect ZGF pictures with 0 XY coordinates and scale
16. Fixed ArcGIS extension incorrect hyperlink
17. Fixed GeoProbe pointset processing error
18. Fixed SEGY file viewer showing zero file size

Version R2003.3.1.4
1. GeoProbe: Added support for viewing GeoProbe 'Pictures' directory

2. SW: Added generate stub link on seismic/horizon 'page' views
3. SW: Added ability to drill down into subdirectories on SeisWorks files page
4. SW: Added support for jpg/png images in SeisWorks files page
5. SW: Allow Apache user to delete subscriptions for deleted projects (#170392)
6. OW: Added display of well dipmeter data (#172540)
7. OW: Added CRS name to OpenWorks project create info table
8. OW: Moved OW project create info to main frame; added sort/save options
9. OW/SW: Added default display of OpenJournal docs on OW/SW summary pages
10. Other: CGM file display changes.
1. GeoProbe: Changed volume count to only list .vol files

2. GeoProbe: Handle volumes with corrupt real-world coordinates
3. GeoProbe: fix for >2Gb volumes
4. OW: Fixed form error in well log curve comparison
5. OW: Fixed error in poslog comparison when not present in both projects
6. OW: Removed dependencies on owsysp password (#162136)
7. SW: Added underscores to live trace outline shapefile (dbf) titles
8. SW: Changed navigation GIS image from png to jpg (#160693)
9. OJ: Fixed OpenJournal search bug if space after text string
10. ZM: Fixed error displaying grid images from read-only MFDs
11. ZM/OJ/GeoProbe/Other/CDA: tightened security on level C file access
Enhancements and Fixes in this Version (R2003.3.1.5)
WOW R2003.3.1.5 is a patch release. It requires WOW R2003.3.1 to be installed first.
Bug fixes and enhancements:
1. Added support for browsing VIP data covering these VDB data types per case:
case headers
plot classes with graphs of variables vs. time with observed data where present
initialization variables with maps of variables per layer
recurrent variables with maps of variables per layer per timestep
ternary diagrams of initial and recurrent variables
lists of grids, timesteps and perforations with start/end flow type.
2. OW: Added original XY locations to OW project comparison
3. OW: Added save 2D line list following OW project comparison
4. OW: Extend cross-project well search to also search the well remark
5. OW: Fixed error in saving results of OW well header comparison
6. OW: Fixed parsedir error displaying very small files
7. OW: Fix error adding KRS documents with apostrophe in name/comment
8. OJ: Automatic OJ link on OW/SW summary pages now handles exact match

Pre-Installation Planning
Minimum Requirements
The minimum requirement for the WOW server and for the WOW Documenter is:
Server Hardware: Sun Blade 100 or Pentium PC, 512Mb RAM, 100Mb free disk space
Operating System: Solaris 8 or Redhat Linux 7.2, patches as per R2003
Application Software: OpenWorks R2003.
Please note that WOW is a server-side application. There is no client-side (web browser)
installation or configuration:
Client Hardware: not restricted
Operating System: not restricted
Web Browser: version 5.5 and above of Internet Explorer and Netscape.
We assume the site has an internal network with PCs, installed web browsers, and a
mechanism for domain name lookup as described in point 4 below. See also Appendix 3
for a description of the product architecture.
Other Pre-installation Considerations
Important note: WOW stores SeisWorks project metadata in the OWSYS tablespace. On
R2003 upgrade, be sure to export this information BEFORE shutting down R98 Oracle.
The export and subsequent import in R2003 OWSYS is described in the Customizing
WOW Documenter section.
Before installing, you need to choose or confirm the following:
1. A system on which to run the Apache2server. Apache is a lightweight daemon

process that does not require a particularly powerful server.
2. Apache is usually, but not always, installed with the operating system.
If installed, directory /etc/apache (Solaris) or /etc/httpd (Linux) will exist. To
confirm that Apache is installed, type:
pkginfo | grep Apache (Solaris)
rpm -qa | grep apache (Linux)
There should be a number of Apache packages installed. If not found, please request
your System Administrator obtain and install it see Appendix 4 for more details.
Important note: The version of Apache shipped with Solaris lacks recent security
enhancements. Landmark strongly recommends upgrading Solaris Apache - see
Appendix 4 for more details.
3. We assume that Apache is NOT already running on the selected system and that the
default port 80 is available. If Apache is running, i.e. from a previous installation of
WOW, you must stop it before continuing (as root):
cd /etc/apache (Solaris)
cd /etc/httpd/conf (Linux)
cp httpd.conf httpd.conf.orig
2
This product includes software developed by the Apache Software Foundation (http://www.apache.org).

/usr/apache/bin/apachectl stop (Solaris)
/usr/sbin/apachectl stop (Linux)
4. An install location, typically $OWHOME/WebApps, but may be any NFS-exported

filesystem, e.g. /apps/WebApps.
5. A user who will run the Apache server. This should be a user with read-write
access to most of the OpenWorks and SeisWorks projects typically a data
loader or administrator. Do NOT use root or oracle for security reasons. You
should run the install script as this user, from within a Landmark environment. This
may require temporarily opening up of permissions on the following directories:
$OWHOME
$OWHOME/bin
$OWHOME/revisions
6. The domain name for the site. This will default correctly during installation if the site
uses DNS to allow the resolving of domain names. To test this, type: nslookup
<hostname> in a Unix xterm or at the DOS command prompt. The value returned by
the Unix domainname command is not the correct domain name. If nslookup
returns an error, you will need to determine whether the host name is visible across
the site network. To do this, type ping <hostname> from a DOS prompt on a PC. If
the host is recognized, use the host name with no domain specified; if not, use the full
IP address obtained from the local /etc/hosts file or from NIS using the Unix
command ypcat hosts | grep <hostname>.
7. Root access IS now required to execute the root.sh script for Apache configuration.
8. See Appendix 4 if you require anything other than a single standard Apache root
installation. Appendix 4 addresses options for changing the Apache server and port,
obtaining the Apache package, and installing multiple Apache instances.
Licensing
In WOW version R2003 and above, regular FlexLM licensing is used with a feature name
of WOW. The product simulates a typical user session using the FlexLM linger function.
Whenever a user clicks on a link in WOW, the license is refreshed for a further 20 minutes.
The license is checked back in after 20 minutes of inactivity.
See your R2003 installation instructions and Release Notes for how to install licenses,
and/or email license@lgc.com to obtain a valid license key.
You should install licenses BEFORE installing WOW, as the installation script checks out a
WOW license feature.

Installation
The latest WOW point product release can be obtained on CD. The CD version is in
Landmark Release Manager (CD Installer) format under the product name WebApps, and
includes the Corporate Data Archiver.
Alternatively, the latest WOW point product release can be obtained from the Landmark ftp
server isite.lgc.com, directory /products/WOW/Releases as a compressed tar
file. Contact your customer support representative for isite login details. The current
patch level is R2003.3.1.5.
The overall installation process consists of installing the latest point product release, then
applying and subsequent patches, as described in this section.
Manual Method
Login to the chosen server as the chosen user.
Source the Landmark environment if not done by default:

source $OWHOME/templates/.lgclogin
Create and cd to the installation location ($WOW_HOME):

mkdir $OWHOME/WebApps
cd $OWHOME/WebApps
Untar the media:

gzip dc /loc/WebApps_2003.3.1.0_release.tar.gz | tar xvf
Run the installation script:

cd install
./WOWInstall o $OWHOME
CD Installer Method (WebApps)
Login to the chosen server as the chosen user.
Insert the WOW CD into the server CD drive
Change directory to the CD install directory and execute the setup script:
cd /cdrom/cdrom0/install
./setup
Enter value for $OWHOME if requested. The Release Manager user interface will
appear. Choose Install for WebApps. Accept the default location of
$OWHOME/WebApps. Click on Start to extract the media.
After files are extracted, continue with the installation script as documented below.
Stage 1 Installation Parameters
The installation script prompts for the following parameters:

WOW server hostname: the name of the system on which Apache will run: see pre-
installation considerations. This is referred to as <hostname> hereafter.
WOW server full URL: if DNS is configured this will default successfully, if not, enter
http://<hostname>.
WOW user: defaults to the user name you are using to run the install script: see pre-
installation considerations.
WOW users group: the default group of the user running Apache. Confirm the
default.
WOW_HOME: the location where you have extracted the WOW software, by default
$OWHOME/WebApps. Confirm the default value.
ORACLE_HOME: the ORACLE_HOME location, default taken from the environment.

Confirm the default value.
ORACLE_SID: the ORACLE_SID location, default taken from the environment.

Confirm the default value.
OWSYSSID: the default OpenWorks projects ORACLE_SID location in a multi-

instance environment, defaults to ORACLE_SID if not set in the environment. Confirm
the default in single instance sites otherwise check with your data administrator.
OW_PMPATH: the default configuration directory for OpenWorks and SeisWorks

projects, default is $OWHOME/conf if not set in the environment. It is important to set
this to a sensible default if the site uses multiple OW_PMPATHs.
LM_LICENSE_FILE: the location of the OpenWorks license file, defaults to

$OWHOME/lam/license.dat if not set in the environment.
Administrators email: this email address is used in error messages when Apache
has internal errors. Specify the system administrators email.
Email suffix: the part of your company email following the @, e.g. oilco.com
Data administrator(s) email: a comma-separated list of email addresses for the data
administrators, to whom error form output will be sent. The forms will only work if Unix
email is configured to work internally see the Notes on WOW email section and
check with your system administrator.
Security level: choose level B or C. See the Security section for more detail.
Review: check the options specified; exit and re-run if there are any errors.
During this stage the $OWHOME/WebApps/conf/wow.env file is created containing all

the variables required by WOW. This is the single most important configuration file for
WOW; see Appendix 1 for an example and Appendix 2 for a list of all configuration files.

Stage 2 Configuring WOW Shells/Documenter
During this stage the installation script modifies environmental variables in the WOW tree,
loads the WOW Documenter (kdoc) OWSYS extension and runs tests on the main WOW
shell (lmksh). See Appendix 5 for further background on the devkit shells.
Stage 3 Configuring Apache
The installation of Apache must be run as root. This step will create a root.sh file for
execution as root in a separate xterm. We assume that the selected system is NOT
already running Apache and that the default port of 80 is available.
The root.sh script does the following:
Creates the Apache configuration file httpd.conf in /etc/apache (Solaris) or

/etc/httpd/conf (Linux).
Starts Apache
Creates an example password file, containing the installation user only (with
username as password) and further configures WOW for level B or C security. See
the Security section for more detail.
Copies the WOW default index.html to the Apache web root directory.
Run $OWHOME/WebApps/install/root.sh as root before continuing. You should get

a message indicating that Apache has been started successfully.
To check the installation, run netscape or other Unix browser, typing in the indicated
URL, e.g. http://<hostname>.<domainname>. This should display an Apache
message saying It Worked!. To test PC connectivity, try the same URL in a PC browser.
Stage 4 Finalizing the Install
Location(s) for Z-MAP Plus browsing: you will be asked for zero, one or many
directories containing Z-MAP Plus data. If a single location is chosen, it will be linked
to $OWHOME/WebApps/htdocs/zmap_data. If you request multiple locations, these
will be linked into $OWHOME/WebApps/htdocs/zmap_data. In many sites these
data can be quite widely scattered, so WOW provides a convenient grouping
mechanism.
Location(s) for OpenJournal data browsing: you will be asked for zero, one or
many directories containing OpenJournal data. Details as above, using location
$OWHOME/WebApps/htdocs/openjournal_data
Location(s) for OpenExplorer data browsing: you will be asked for zero, one or
many directories containing shapefile data. Details as above, using location
$OWHOME/WebApps/htdocs/openexplorer_data
Location(s) for Other data browsing: you will be asked for zero, one or many
directories containing SEG-Y or LAS data. Details as above, using location
$OWHOME/WebApps/htdocs/other_data

Location of Subscription directory: specify a location where the results of
subscription requests will be written. This is any directory with ~100Mb free disk
space. The directory will be created if it does not exist and linked to
$OWHOME/WebApps/htdocs/push_output. It also creates a sample crontab file in
$OWHOME/WebApps/install/wow_crontab. See the Subscription section later in
this document.
A message will indicate complete installation. Try the final URL in the browser, i.e.
http://<hostname>.<domainname>. Once the license is installed (see next section)
WOW should be fully functional. See the Troubleshooting section if errors are
encountered.
At this point an option is provided to continue with Corporate Data Archiver installation.
See the CDA release notes for further details.
Notes on KRS Implementation
OpenExplorer knowledge reference system (KRS) documents can be loaded and viewed
through WOW. The (manual) steps described below are applicable if you use the KRS:
Name and value of KRS variable: KRS documents can be stored relative to an
environmental variable, which helps sharing documents between Unix and PC
filesystems. In $OWHOME/WebApps/conf/wow.env, specify the name of a KRS
environmental variable and its value, e.g. KRSDATA with value /data/krsdocs.
Location(s) for general links: for the KRS and in general it is often useful to allow
your Unix data disks to be viewed as part of the WOW system. Directories specified
(e.g. /data or /interp) can be linked into the web root /var/apache/htdocs.
This operation must be performed as root. NEVER use / as this is a security risk.
Patching the Installation
WOW patches are designed as simple compatible additions or replacements of existing

files in the software directories. Patches are provided as a series of compressed tar files,
available from the Landmark ftp server isite.lgc.com, directory
/products/WOW/Supported_Patches. Contact your customer support representative
for isite login details. The current patch level is R2003.3.1.5.
Since R2003.3.1, a new rolling patch has been introduced. The objective is to fix bugs
with days and update a continuous rolling patch, so customers do not have to wait
months for the next official patch. This patch is on isite, directory
/products/WOW/Rolling_Patch.
To install a patch, copy it to your install location, typically $OWHOME/WebApps. See the
associated README for detailed installation instructions.
Current patch level can be obtained by clicking on About on the WOW browser interface.

Patch history:
R2003.0.1.0 foundation release (April 2002)
R2003.0.1.1 patch, requires R2003.0.1 (May 2002)
R2003.0.2.0 point product release, includes R2003.0.1.1 (Jun 2002)
R2003.0.3.0 point product release, requires R2003.0.2 (July 2002)
R2003.0.3.1 patch release, requires R2003.0.3 (Oct 2002)
R2003.3.1.0 point product release, includes all previous versions (Jan 2003)
R2003.3.1.1 patch release, requires R2003.3.1.0 (May 2003)
R2003.3.1.2 patch release, includes R2003.3.1.0 (Aug 2003)
R2003.3.1.3 patch release, includes R2003.3.1.x (Dec 2003)
R2003.3.1.4 patch release, includes R2003.3.1.x (Apr 2004)
R2003.3.1.5 patch release, includes R2003.3.1.x (Jul 2004)
This is the end of the compulsory installation process.
To modify the default security sections or to add additional users, read the Security section.
If the site uses multiple OW_PMPATHs, read also the OW_PMPATH section.
If the site has multiple Oracle instances, read the Multiple Oracle Instances section.
If the site has WOW Documenter (kdoc) records from R98, see the Customizing WOW
Documenter section.

Configuring Security Options
This discussion applies to the WOW browser client only. The Unix Documenter GUI obeys
identical Unix file permissions as SeisWorks, HrzUtil or any other SeisWorks utility.
There are a number of different options for implementing security in WOW, from universal
read-only access to enforcement of access rights, as if the user was trying to access the
actual Unix project. Specified tight projects can be restricted entirely. In the current
release, the application is largely read-only. The default is therefore a generally open
approach, but with all write-back options requiring authentication (level B).
Security Levels
Level A Universal read-only with named exclusions: Any user that can login to
any system over the company network can access all OpenWorks, SeisWorks and
Z-MAP Plus data, read-only, except for named exclusions. Nobody can see named
exclusions, which protects sensitive data. The main advantage of level A security is that it
is a low-maintenance approach, but it does require a company to have an open approach
to sharing technical data. The main disadvantage is that even legitimate users cannot
access restricted projects. Also, access to all write-back functionality (e.g. list creation,
WOW Documenter and Subscriptions) is denied under Level A security.
Level C Full emulation: As above, but users are required to login at all times. The
authenticated username is then used to validate access at an individual project level,
exactly as if the user is logging on to a Unix workstation in the site. This is as secure as the
underlying applications, but at the expense of extra administration to maintain the
password file. Extra administration is also required to grant casual users access (e.g.
Team Leaders, Drillers etc.). To access WOW, casual browsers will need to:
have Unix accounts
be added to Oracle as external users
be granted browser access to required OpenWorks projects
be granted read-write access to required SeisWorks project directories (SeisWorks
does not support read-only execution)
be granted read-only access to required Z-MAP Plus directories and files.
Level B Full emulation, but on a subset of functionality: An intermediate option, this

provides full emulation but only on the write-back modules (e.g. creating well lists,
adding/deleting KRS documents, adding/updating SeisWorks documentation). Universal
browsing is thus encouraged without having to provide a password, but as soon as an
attempt is made to write back to the database (e.g. loading a KRS document), the user is
prompted for a login and password. This is the default security level.
Important note: To enjoy the full functionality of WOW, Level B or above security is
strongly recommended.
Configuring Security Level A
Access is restricted to projects and directories by modifying files in the

$OWHOME/WebApps/conf directory as described below.
OpenWorks: modify the OW_PROJ_WHERE_CLAUSE in

$OWHOME/WebApps/conf/wow.env to restrict projects to those that have a particular

name or comment. Modifying this requires a degree of SQL knowledge; please contact
support if in doubt.
SeisWorks: the $OWHOME/WebApps/conf/restricted_plist.dat file lists the

names of any tight SeisWorks projects. They will appear in listings but will not be further
accessible.
Z-MAP Plus/OpenJournal: the

$OWHOME/WebApps/conf/restricted_dir_list.dat file lists the names of
any tight Unix directories. These will appear in listings but will not be further accessible.
The file already contains the main operating system directories such as / /usr /etc
/bin etc. It should also contain the web root, to prevent server-side browsing of restricted
directories.
Adding Users to the Apache Password File
Adding users requires root access for permission to edit files in /etc/apache.
Updating the password file from an existing source. A default password file is created
during installation with only the install user added. The format for the password file is
identical to that of a Solaris passwd file, except that only the first two fields (user and
encrypted password) are used. Apache uses the same crypt function as Unix, so one
method of adding users is:
ypcat passwd > /etc/apache/.wp (Solaris)
ypcat passwd > /etc/httpd/conf/.wp (Linux)
If you use this method, you should edit the file and delete users based on various criteria
such as group membership etc. Note that it is not considered secure to use the actual
/etc/passwd file itself.
For additional security, the password file name and location can be changed, and made
readable by the Apache server user only.
Updating the password file manually. You can also add new users manually using the
htpasswd facility, e.g. to add user demo, passwd demo:
/usr/apache/bin/htpasswd b /etc/apache/.wp demo demo (Solaris)
/usr/bin/htpasswd b /etc/httpd/conf/.wp demo demo (Linux)
Use the additional c flag when creating a new passwd file, or help for complete usage.
Important note: it is the site's responsibility to keep the password file up-to-date, e.g. by
scheduling a cron job to refresh it at regular intervals. If you uses NIS, it is possible to
authenticate directly using an optional Apache module - see Appendix 4 for details.
Changing Security Level between B and C
1. Modify the .htaccess file: Edit the $OWHOME/WebApps/cgi-bin/.htaccess file.

For level C security, comment the <FilesMatch></FilesMatch> lines. For level B
security, uncomment the <FilesMatch></FilesMatch> lines.
cd $OWHOME/WebApps/cgi-bin
vi .htaccess
# For level C security comment <FilesMatch></FilesMatch>

#<FilesMatch (input|delete)\.cgi$>
AuthType basic
AuthName "WOW Unix" (a descriptive name for the authorization form)
AuthUserFile "/etc/apache/.wp"
Require valid-user
#</FilesMatch>
# For level B security uncomment <FilesMatch></FilesMatch>

<FilesMatch (input|delete)\.cgi$>
AuthType basic
AuthName "WOW Unix" (a descriptive name for the authorization form)
AuthUserFile "/etc/apache/.wp"
Require valid-user
</FilesMatch>
2. Update wow.env:
vi $OWHOME/WebApps/conf/wow.env and change SECURITY_LEVEL to B or C.
Protecting Static Documents
The WOW security model is largely aimed at preventing access to dynamic pages created
on the fly in WOW. This section explains how to protect certain static documents, e.g. an
OpenJournal project, which requires selective security. The restricted dir list mechanism
described for level 2 security provides blanket protection for certain directories, but even
legitimate users cannot get to these directories.
One possibility is to set up a custom .htaccess and password file for the specified
directory. Apache will then authenticate all access to static files in that directory. Notes that
this will have no effect on WOW dynamic pages, e.g. ZMAP browsing. To implement this:
1. Create a password file. Use the htpasswd utility to create a passwd file. The
example below creates a file called ojpasswd with user tight, passwd oj2001:
htpasswd bc /etc/apache/.ojpasswd tight oj2001
2. Create an .htaccess file. Create a file with contents as listed below:

AuthType basic
AuthName "Tight OJ Projects"
AuthUserFile "/etc/apache/.ojpasswd"
Require valid-user
3. Copy .htaccess to the required directory. Place the file into all directories that
require the same security policy.
4. Configure Apache to recognize the .htaccess file:

vi /etc/apache/httpd.conf (Solaris)
vi /etc/httpd/conf/httpd.conf (Linux)
Change AllowOverride from None to AuthConfig within the <Directory />
stanza (approx. line 390).
5. Restart Apache:
/usr/apache/bin/apachectl restart (Solaris)
/usr/sbin/apachectl restart (Linux)

Configuring Multiple OW_PMPATHs
Many Landmark sites, in particular those with large numbers of SeisWorks projects,
subset their SeisWorks configuration files using multiple OW_PMPATHs. Each
OW_PMPATH contains a unique plist.dat, dir.dat and lgcenv.cf.
The most common scenario is to have a number of conf_xxx subdirectories under

$OWHOME in parallel to the default Landmark $OWHOME/conf directory, e.g. conf_sns,
conf_nns, conf_wos etc. Or a completely new directory may be created, e.g.
/data/conf with subdirectories of sns, cns, wos etc.
Some companies use a site-specific customized environment called Common Application

Interface (CAI). Although supported on a site-by-site basis on existing installations,
Landmark is no longer offering CAI to new sites. WOW installations can however be
configured in CAI environments.
In both custom OW_PMPATH and CAI situations, it must be possible to uniquely identify
the names and locations for the OW_PMPATH directories. These should be added to the
wow_distlist.dat file in $OWHOME/WebApps/conf.
cd $OWHOME/WebApps/conf
cp wow_distlist.dat.default wow_distlist.dat
vi wow_distlist.dat
######################################################################
#
# This file contains a list of SeisWorks districts. It comprises:
# - district
# - associated OW_PMPATH location
# - a common name for the district
# - associated OWSYSSID
#
# You MUST ensure that all OWSYSSIDs referenced are in wow_sidlist.dat
#
######################################################################
d1 /data3/bruce/conf_d1 "District D1" owprod
dr /data3/bruce/conf_dr "GOM Regional" owexplor
dx /data3/bruce/conf_dx "GOM Deepwater" owexplor
all /data3/bruce/conf_all "Composite" owprod
Alternatively, the WOW Apache owner can configure this file through the browser by
clicking on Admin on the WOW top bar.
Note the dependency on wow_distlist.dat (described in the next section).

All SeisWorks projects in a district must belong to the same Oracle instance.
Once configured, the district is set on a per-client basis by clicking on Change District/SID
on the WOW top bar. This sets a cookie that stores the instance name locally and
remembers it until changed by any user on the same client. This option will also change
the SID to match that required for the chosen district.
It is also important to set a valid default OW_PMPATH in the wow.env file in

$OWHOME/WebApps/conf - typically $OWHOME/conf.

Configuring Multiple Oracle Instances
Dynamic support for multiple Oracle instances (ORACLE_SID/OWSYSSID) is

incorporated with WOW since release R2003.0.3.1. This enables users to browse data in
multiple instances, and to carry out cross-project comparisons between instances.
The Instance Configuration File
To enable multiple instance functionality, edit

$OWHOME/WebApps/conf/wow_sidlist.dat and list entries of ORACLE_SIDs
containing OpenWorks projects. Ensure that all entries are also in the Oracle
tnsnames.ora file, located in $TNS_ADMIN or $ORACLE_HOME/network/admin.
cp wow_sidlist.dat.default wow_sidlist.dat
vi wow_sidlist.dat
##############################################################################
#
# This file contains a list of Oracle SIDs available for project comparison
# Note: SIDs referenced below MUST be added to the tnsnames.ora file
# in $TNS_ADMIN or $ORACLE_HOME/network/admin
#
##############################################################################
owden Denver (local)
owcal Calgary
owabz Aberdeen
#owstv Stavanger (offline)
owhst Houston
Once configured, the instance is set on a per-client basis by clicking on Change

District/SID on the WOW top bar. This sets a cookie that stores the instance name locally
and remembers it until changed by any user on the same client.
Alternative Options
Before configuring WOW for multiple instances, note that WOW supports without
configuration the specific cases where OpenExplorer Advanced Project Management
(APM) is configured, or where the remote project facility is used. Under these
circumstances the OWSYS tablespaces are either replicated by Oracle or manually.
WOW may run against either of the instances, and projects from the other will be visible
and can be accessed.
Note also that the following are also possible:
Install an Apache server per Oracle instance. Although this sounds inefficient, Apache
is a considerably lighter process than Oracle and does not add much overhead.
The $OWHOME/WebApps/conf/wow.env variable for ORACLE_SID and/or

OWSYSSID variable can be changed if necessary, to point to another instance. Only
one instance can be browsed at a time by this method.

Configuring Subscription Tools and Email
The subscription or push tools allow users to request automatic notification by email in the
event that data are changed or added within a registered area of interest by specified
project, geographic area or data type.
These tools allow users to establish, view and modify their subscriptions directly through
html forms. A series of cron jobs execute queries, which compose emails providing users
with a list of new/changed data from WOW.
To configure the subscription tools, you need to set up a cron job to run as the Apache
user. A default crontab is configured during installation. With contents in
$OWHOME/WebApps/install/wow_crontab,. This can be added manually to other
users using the crontab command:
setenv EDITOR vi
crontab -e
0 4 * * 2-6 /your/OWHOME/WebApps/bin/DoPush Daily
0 4 * * 1 /your/OWHOME/WebApps/bin/DoPush Weekly
0 4 1 * * /your/OWHOME/WebApps/bin/DoPush Monthly
Notes on WOW Email
The subscription module described above, as well as the data error and feedback forms,
rely on Unix email to be configured. Many sites are configured such that mail sent from
Unix will go to the recipients in-house PC email system. Few allow external email
connections.
To test whether your site is configured for internal Unix->PC email, type:
nslookup mailhost
If this command returns an error, WOW cannot send mail to your PC email account. If it
returns a valid IP address for the mailhost, try a test email as follows:
/usr/lib/sendmail i -t
To: <your email address>
Subject: Test Email
This is a test email sent by WOW
<ctrl-D>
The email should appear in your PC email within a few minutes.
If internal Unix->PC email is not configured, you do have the option of selecting a pure
Unix email address (same as Unix account name) as the email recipient during
installation, but this is not recommended.

Customizing the WOW Interface
Although WOW will install and run out of the box, it is designed to form part of a larger
subsurface E&P portal. For example, the portal would cover project databases via WOW,
other internal databases, links to EDMS systems, external links etc. WOW behaves
identically to any other Web site that contains a combination of static and dynamic content.
This means that WOW URLs can be called from or embedded in any other Web page.
Knowledge of html and Web authoring is required to create Web pages that invoke WOW
components. The static pages that provide the default WOW interface reside in
$OWHOME/WebApps/htdocs. Landmark recommends that you do NOT modify these
files. Rather, create a new Web page that calls the relevant WOW file or dynamic URL
directly.
The home page for the Apache installation is /var/apache/htdocs/index.html

(Solaris) or /var/www/html/index.html (Linux). This file is replaced with the WOW
home page on installation, but any client-provided page may be used. In this case, the full
WOW URL is http://<host>.<domain>/wow/, with the trailing slash required by
Apache.
To revert to the simpler URL http://<host>.<domain> without the /wow/ (if the
Apache server is not used other than by WOW), replace the default Apache index.html file
with the WOW index.html (as root):
cd /var/apache/htdocs (Solaris)
cd /var/www/html (Linux)
cp index.html index.html.orig
cp $OWHOME/WebApps/htdocs/index.html .
The WOW left frame menu is partly customizable. This allows site administrators to add
links below the WOW links, by modifying a simple configuration file. See
$OWHOME/WebApps/conf/wow_menu.dat for details.
cp wow_menu.dat.default wow_menu.dat
vi wow_menu.dat
##############################################################################
#
# This file contains metadata for adding links to the WOW left frame
# It consists of the following tab-delimited fields:
# Name: short name for the link, e.g. "Landmark Graphics"
# URL: fully-specified URL, e.g. http://www.lgc.com
# Note: use double quotes for entries with a space in the name
#
##############################################################################
"Landmark Graphics" http://wow.lgc.com
"E&P Home Page" http://www.oilco.com/eandp

Browsing Unix Directories
Recognizing specific file types
The Z-MAP Plus, OpenJournal, OpenExplorer and Other Data modules run the same file-
and directory-parsing function. The function is hard-coded to recognize certain file types,
e.g. MFDs and ZGFs, as well as certain structures, e.g. OpenJournal projects. There are
also two special categories for files of the following types:
files that are composed only of ASCII characters
files that are universally recognized by Web browsers, e.g. with extensions of .html,
.tif, .gif, .jpg etc. These are referred to as mime types.
If there are ASCII file types (e.g. .vel for velocity surveys) which you would like to be able
to view through WOW, then do the following:
cp ascii_file_extensions.dat.default ascii_file_extensions.dat
vi ascii_file_extensions.dat
And add in file extensions as indicated.
A similar approach can be adopted for common mime types using the file
$OWHOME/WebApps/conf/web_file_extensions.dat.
Alternatively, the WOW Apache owner can configure these files through the browser by
Important note: WOW is a server-side application, i.e. files are processed on the web
server and results (html or images) sent to the Web browser. This is the only way in which
files like MFDs, ZGFs, seismic and horizons can be displayed. Standard mime types
behave differently: they are supported directly by the browser and are therefore
downloaded and processed locally. This requires that files be addressable via a URL, i.e.
they must reside below the Web root. See Finalizing the Install for how to achieve this.
Exposing additional directories
The Z-MAP Plus, OpenJournal, OpenExplorer and Other Data modules run the same file-
and directory-parsing function, which looks for a specific hard-coded start directory:
Z-MAP Plus: $OWHOME/WebApps/htdocs/zmap_data

OpenJournal: $OWHOME/WebApps/htdocs/openjournal_data
OpenExplorer: $OWHOME/WebApps/htdocs/openexplorer_data
Other Data: $OWHOME/WebApps/htdocs/other_data
If there is an obvious single start point for a data type, e.g. /oe_gisdat2 for
OpenExplorer, simply create a link to this location, e.g.
ln s /oe_gisdat2 $OWHOME/WebApps/htdocs/openexplorer_data
If there are multiple candidates, create the parent directory and then create links inside this
location to the multiple start directories, e.g.
mkdir $OWHOME/WebApps/htdocs/other_data
ln s /data/misc/vendors/segyfiles

$OWHOME/WebApps/htdocs/other_data
ln s /export/home/fred/lasdata $OWHOME/WebApps/htdocs/other_data
By simply creating and deleting links to data, directories may be exposed or hidden
rapidly. If the parent directory or link does not exist, an error message will be returned.
Adding External Links
The Links button allows a site to rapidly integrate other intranet or Internet data,
information and knowledge sources within WOW. Essentially this provides a mechanism
for adding hypertext links to a web page without needing to update static html the page
is generated dynamically from a simple configuration file. Links can also be searched,
sorted and saved to Excel.
The configuration file is $OWHOME/WebApps/conf/wow_links.dat. This contains one

link per line with four space-delimited fields (see example below).
Important note: the format of this file has changed from pipe-delimited to space delimited.
Name: a descriptive name for the information source, e.g. DEAL
Description: a full description of the source
URL: the full hypertext link to the information source
Icon: an optional logo file, which if specified should exist in

$OWHOME/WebApps/htdocs/logos
###############################################################################
# This file contains metadata for the other sources (links) page in WOW
# It consists of the following pipe-delimited fields:
# Name: short name for the link
# Description: longer descriptive name (up to approximately 255 chars)
# URL: fully-specified URL, e.g. http://www.lgc.com
# Logo (optional): name of logo image (place in $OWHOME/WebApps/htdocs/logos)
# Category (optional, not yet supported): type of link, e.g. info vendor
#
# Do not edit the line below
Name Description URL Logo Category
#
# The Tag line allows html tags to be passed, e.g. uniform image height.
# Comment this line to allow images to display at their default sizes
Tag height=50
###############################################################################
CDA UK seismic and well data http://www.cdal.com cda_logo.jpg
DEAL Index of UKCS geotechnical data http://www.ukdeal.co.uk deal_logo.jpg
LIFT Promoting asset opportunities http://www.uklift.co.uk lift_logo.gif
DTI Released UK well/license/prod data http://www.og.dti.gov.uk dti_logo.gif
IndigoPool.com E-business portal for O&G http://www.indigopool.com ip_logo.gif
Landmark E&P software vendor http://www.lgc.com lmk_logo.gif

OpenWorks QC/QA Queries
The QC/QA module allows the storage and execution of SQL queries against OpenWorks
projects. It differs from the stored queries in OpenWorks in that queries are global, i.e.
they are stored once without needing to be copied between projects. Multiple queries can
be run sequentially against a single project, or a single query can be run across multiple
projects. The objective is to run a series of queries that provide a project health check, e.g.
wells without KB, wells without TD etc.
Important note: The QC/QA logic as expressed in these queries may not apply to all
sites, or made need modification based on local conditions. These queries are not meant
to be universally applicable and infallible. Although a standard suite is provided as listed
below, these may be copied to a site-specific version and edited. Editing the queries as
provided is not recommended, as edits will be overwritten by subsequent updates.
A suite of standard queries is provided.

Fields with 0 or null XY/LatLongs
Leases with blank names
Pick counts
Project data counts
Seismic surveys
Well checkshots with suspicious datums
Well curves > TD
Well curves with decimal/percent issues
Well curves with min/max values outside left/right scales
Well curves with possible duplication
Well curves with suspicious min/max values
Well curves with unknown units
Well list counts
Well picks > TD
Well picks with possible duplication
Wells with 0 or null Lat/Longs
Wells with 0 or null XYs
Wells with 0 or null datum
Wells with 0 or null datum and pick/crv/log/poslogs
Wells with 0 or null total depth
Wells with blank common well names
Wells with directional survey but no poslog
Wells with poslog / TD mismatch
Wells with unknown status or symbol.
Queries can be edited or added to this list by copying a .sql file to the
$OWHOME/WebApps/dat/sqlscripts directory. Files should follow a certain format to
execute properly within the browser:
Important points to note:
The first line must contain REM title: this is displayed as the title in the browser.
The second line must contain REM dtype: this tells the browser what to create
the hyperlink to. Currently well, field, lease and seis (navigation) data types are
supported. Set dtype to some other value if not a simple well, field or lease query.

The first attribute selected must be the primary key for that data type, i.e. well_id,
field_id or lease_id. This first attribute then appears as a hypertext link in the browser.
To turn off this behavior, set dtype to some other value.
The final line must contain a / and nothing else.
Support for standard SQL*Plus variable substitution is provided (&varname syntax).
The advantage of this format is that files can be created and tested in standard SQL*Plus
the REM lines are treated as remarks and ignored, and the final / is the standard SQL
terminator. If a query parses and executes in SQL*Plus, it will execute in the browser.
An example QC/QA query is provided below:
REM title: Wells with 0 or null total depth

REM dtype: well
select
well_id ID,
well_uwi "UWI",
well_name_free "Common Well Name",
final_td "TD"
from
well_master
where
final_td is null
or
final_td = 0
order by
well_name_free
/
Changing Default Well Name Display
By default WOW displays wells using the common well name attribute WELL_NAME_FREE.
The default can be overridden for the site by setting an environmental variable
WELL_NAME_SQL in the wow.env file, e.g.:
vi wow.env
add line: WELL_NAME_SQL=well_uwi; export WELL_NAME_SQL
The default is common well name, i.e.:

WELL_NAME_SQL=well_name_free; export WELL_NAME_SQL
The site administrator can provide any SQL fragment that is queryable as an attribute, i.e.:
well_uwi
current_well_lease_name || | || current_well_lease_no
current_company || | || current_well_lease_no
Note that the attribute is also used to control well display order.

WOW Documenter
Running WOW Documenter
The WOW Documenter allows the user to store extra information about SeisWorks
interpretations. It provides a spreadsheet-style, multi-object interface to the same
functionality within the WOW Web interface. The WOW Documenter requires the user
have at least l_interp access to the associated OpenWorks project.
SeisWorks R2003.12 and above have adopted the WOW Documenter model. Use of the
WOW Unix GUI will therefore be phased out in a future release.
To run the WOW Documenter (kdoc):
prompt> source $OWHOME/WebApps/templates/dotlogin

prompt> kdoc
Alternatively, you can type the full path to the kdoc script, i.e.
prompt> $OWHOME/WebApps/bin/kdoc
For the R2003 version, kdoc is also a link in $OWHOME/bin, i.e. it can be run from any
OpenWorks xterm simply by typing kdoc. A sample launcher.dat entry is also
provided in $OWHOME/WebApps/templates/launcher.dat.extra.
The graphical user interface is illustrated below:

Customizing WOW Documenter
The WOW Documenter stores SeisWorks meta-information in an extension to the

OpenWorks datamodel. Project information is stored in OWSYS, while horizon and
seismic information is stored in the associated OpenWorks project. All table names begin
with PIM_ or PIMR_. The Documenter GUI can be customized in the following ways:
Many of the standard lists of values (LOVs) that appear in pop-up menus or list boxes
can be modified.
The default column titles for attributes can be modified.
Modifying LOVs
The table below summarizes the LOVs under site control. Not all LOVs are editable, e.g.
lists of seismic, mapping and horizon files are determined in real time. These lists can be
modified by clicking on the modify lists of values link on each SeisWorks project summary
page. Note that changes made in this manner apply to the OpenWorks project with which
this SeisWorks project is associated and hence to all associated SeisWorks projects.
LOV name Schema.Table.Key Defaults
status project.pimr_status.hrz_flt_status final, junk, old, working, DeleteMe,

RenameMe, UNKNOWN
hrzclass project.pimr_hrz_class.hrz_class filtered, imported, interpolated, seed, zap,

UNKNOWN
polarity project.pimr_polarity.polarity SEG normal, SEG reversed, UNKNOWN
phase project.pimr_phase.phase minimum, zero, UNKNOWN
seisclass project.pimr_seis_class.seis_class attribute, far offset, inversion, mid offset,

migration, near offset, psdm, psdm(time),
pstm, r0, sail, stack, velocity, UNKNOWN
application project.pimr_application.application Charisma, IESX, Post/PAL, SeisWorks,

Z-MAP Plus, UNKNOWN
interpstatus owsys.pimr_interp_status.interp_status active, dormant, archived, UNKNOWN
pcompany owsys.pimr_company.company ...
Optionally, three lmksh functions are provided to manage these LOVs. See Appendix 5
for further background on using the lmksh shell.
1. GetLOV <swproj> <lovtype>: returns a list of LOVs for the specified SeisWorks
project and LOV type
2. InsertIntoLOV <swproj> <lovtype> <value>: inserts a new value into the

LOV for the specified SeisWorks project LOV type

3. DeleteFromLOV <swproj> <lovtype> <value>: deletes a value from the LOV
for the specified SeisWorks project LOV type
Example:
prompt> rlmksh
lmksh{1}% OWSetup; SeisSetUp
lmksh{2}% set lda [OWoralogon]
lmksh{3}% GetLOV colt polarity
{SEG normal} {SEG reversed} UNKNOWN
lmksh{4}% InsertIntoLOV colt polarity UK Normal
lmksh{5}% InsertIntoLOV colt polarity UK Reverse
lmksh{6}% DeleteFromLOV colt polarity SEG normal
lmksh{7}% DeleteFromLOV colt polarity SEG reverse
lmksh{8}% oralogoff $lda
lmksh{9}% exit
Changes are made to existing extensions. To modify the lists at the point at which the
datamodel extension is first created, you need to modify the file
create_pim_project_extension_custom.sql in
$OWHOME/WebApps/kdoc/sqlscripts. This requires SQL knowledge contact your
data administrator if in any doubt.
Modifying Column Titles
The labels given to each Documenter attribute are controlled by metadata stored in Oracle
column comments, and may be modified. Once the datamodel extension is created,
modification involves editing the appropriate SQL file then running the appropriate lmksh
function. For example, to change the project tab Quad/Block title to Area:
prompt> cd $OWHOME/WebApps/kdoc/sqlscripts
prompt> vi update_pim_owsys_comments.sql
- replace the string Quad/Block with Area
- save and exit
prompt> lmksh
lmksh{1}% UpdateOwsysExtension
For horizons and seismic edit update_pim_project_comments.sql and run the

lmksh function UpdateProjectExtension. To ensure consistency between existing
projects and those yet to be created, it is important to make the same changes in
create_pim_project_extension.sql. See the README in
$OWHOME/WebApps/kdoc/sqlscripts.
Removing the Documenter Tables
Internal lmksh procedures are provided should it be necessary to remove the WOW
Documenter tables within each project:
lmksh{1}% RemoveProjectExtension <owproj> (repeat for each project)

lmksh{2}% RemoveOwsysExtension

Moving Records Between OpenWorks Projects
If the SeisWorks-OpenWorks project association changes, i.e. if the SeisWorks project is

moved between two overlapping OpenWorks projects, then the WOW Documenter
records pertaining to that SeisWorks project need to be transferred from the old to the new
OpenWorks project as follows:
prompt> cd $OWHOME/WebApps/kdoc/sqlscripts
prompt> sqlplus /@$ORACLE_SID @kdoc_swproj_transfer
<source OW> <target OW> <SW project>
Important note: run this SQL script as a user that has MANAGE access to both
OpenWorks projects.
Moving Records Between OWSYS Tables
Clients with existing WOW Documenter data under R98.x may wish to import the project
records that are stored in the OWSYS tablespace, as described below.
1. Make a copy of the R98 owsys.pim_prj_info table

sqlplus owsys/owsys@<R98OWSYSSID>
create table temp_pim_prj_info as select * from pim_prj_info;
exit
2. Export the R98 OWSYS Documenter tables

exp owsys/owsys@<R98OWSYSSID> file=kdoc.dmp
tables=temp_pim_prj_info,pimr_company,pimr_interp_status
grants=n
Check that records are exported and that the import terminates successfully.
3. Delete the automatically created records from the R2003 OWSYS

sqlplus owsys/owsys@<R2003OWSYSSID>
delete from pim_prj_info;
delete from pimr_company;
delete from pimr_interp_status;
exit
4. Import data into the R2003 OWSYS

imp owsys/owsys@<R2003OWSYSSID> file=kdoc.dmp full=y ignore=y
Check that records are imported and that the import terminates successfully.
5. Copy data from temp_pim_prj_info to pim_prj_info

cd $OWHOME/WebApps/kdoc/sqlscripts
sqlplus owsys/owsys@<R2003OWSYSSID> @kdoc_owsys_copy
6. Drop the temporary table after checking results

drop table temp_pim_prj_info;
Important note: Execute this process before loading new data to the Documenter tables.

Integrating with CDA
Corporate Data Archiver (CDA) can be used to generate throwaway stubs which produce
image thumbnails for re-use within WOW. These options are provided for OpenWorks,
SeisWorks and GeoProbe projects. This functionality is designed to facilitate a project
cleanup operation, e.g. deleting empty horizons and intermediate processing seismic
volumes. Note that a CDARCHIVE license is required in order to exercise this option.
The option to generate, regenerate or view an existing archive stub is provided on the
OpenWorks and SeisWorks project summary pages. Clicking this link brings up a CDA
control file editor. Once created, the stub can be previewed directly. Use an archive project
name of Stubs to create thumbnails in a fixed location, for re-use in the WOW horizon
and seismic list builders.
Important note: for sites not wishing to allow archive generation through the browser, add
the following line to $OWHOME/WebApps/conf/wow.env:
ARCHIVE_BROWSER_FLAG=REQUEST; export ARCHIVE_BROWSER_FLAG
This will replace the link to generate archive with a link to request archive generation,
which sends email to the CDA administrator.
The SeisWorks horizon and seismic list builders are accessible from the page links on the
SeisWorks project summary page. They allow browsing horizons and seismic a page at a
time, drilling down to view details or selecting objects to save or append a list.
The web interface is illustrated below:
Thumbnails generated in the 'Stubs' projects will also appear in the horizon and seismic
documentation pages in WOW, making the process considerable easier.

List-based Deletion
Command-line scripts are provided to delete lists of horizons and seismic created using
the WOW page view list builders.
Important note: these routines are inherently destructive. Make sure you have a current
project backup before executing.
To configure batch deletion scripts (one-off operation):

cd $OWHOME/WebApps/bin
ln s lmksh_wrapper HrzListDelete
ln s lmksh_wrapper SeisListDelete
To execute the deletion:

HrzListDelete <project> <listname>
SeisListDelete <project> <listname>

Referencing External Documents for SeisWorks 2D
The WOW Documenter model allows attributes and comments to be added against the
proclev, rather than against an individual seismic line 2v2 file. Therefore all lines that
share the same proclev, e.g. mig080001, share the same documentation. In some
circumstances however it may be preferable to reference a unique document for every line
that has a certain processing level. For example, there may be a vendor-provided
acquisition and processing report containing velocity data for each 2v2 file.
The OpenExplorer KRS document reference also cannot be used to store a document
related to a non-OpenWorks object such as a SeisWorks 2v2 file.
To overcome these limitations, WOW provides a simple mechanism to allow the display of
plain text files on a per-2v2 basis. To enable this, create a file <masterproject>.docs
inside the 2D master project system directory. This file should contain a simple lookup list
between 2v2 file name and external documentation file name, e.g.:
#
# File <masterproject>.docs
# File contains a list of 2v2 name vs. external text file.
# Place this file in the master project system directory.
#
CAGC-001-UA7A_________mig00000101.2v2_glb /fullpathto/CAGC01U7.filt.Veritas.01.txt
CAGC-001-UA10_________mig00000101.2v2_glb /fullpathto/CAGC01U10.filt.Veritas.01.txt
CAGC-001-UA10_________mig00000101.2v2_glb /fullpathto/CAGC01U11.filt.Veritas.01.txt
The file <masterproject>.docs can be generated via simple Unix commands and
then edited to add in the text references as appropriate, e.g.
ls *01.2v2_glb > <masterproject>.docs
Blank lines, lines beginning with # and lines with only one entry are safely skipped.
If the <masterproject>.docs file exists, the SeisWorks 2D seismic line selection page
will allow launching of the relevant line directly. The option to view the associated text file is
provided as a link below the seismic header table.

Creating Live Trace Outlines
The Live Trace Algorithm
The algorithm is designed to display the actual extent of 2D or 3D seismic traces, rather
than the navigation extents. In the 2D case, the output shows exactly which lines or parts
thereof have the specified processed level.
In the 3D case, the output attempts to show the exact shape or outline where traces exist
within the rectangular project limits. The 3D algorithm operates by walking clockwise
around the outside of the survey, until it returns to the starting point. The algorithm does
not read every trace, which makes it considerably faster, but it consequently cannot handle
the following scenarios:
Internal holes within the survey
Non-contiguous pieces of seismic data
Surveys where e.g. every 2nd line or trace is loaded
Zero-valued traces (real traces with zeros, as distinct from absent or null traces)
The algorithm therefore produces reasonable outlines in the majority of cases, but will not
always succeed.
Customizing the Algorithm
WOW aims to dynamically create Web pages or images on the fly, i.e. without resorting to
static, pre-created files. Seismic trace outlines present a real challenge in this regard. 3D
volumes containing many millions or traces may not complete within the patience
threshold of a typical user.
A batch mechanism is therefore provided to auto-generate the live trace outlines as png
images, ESRI shapefiles (3D only), ASCII coordinate files (3D only) or ZGF pictures (3D
only). Pre-generated png images in the project system directory will display by default in
WOW.
Options are provided to generate outlines in these formats for a single volume, all volumes
within a project or for all projects. These functions can be run within lmksh or linked to
lmksh_wrapper and run in an xterm, as described in Appendix 5.
To generate a single outline for 2D or 3D: use the lmksh proc seis2png, e.g.
lmksh{1}% SeisSetUp
lmksh{2}% seis2png devnor 3 mig0801.3dv 25 15 50 50 800 40 tmp.png
lmksh{3}% seis2png devnor 3 mig0801.3dv 25 15 50 50 800 40 tmp.shp
lmksh{4}% seis2png devnor 3 mig0801.3dv 25 15 50 50 800 40 none tmp.zgf
outline
Note that the output file extension determines the output type. Note also the different
syntax for ZGF file output. See the next section for a simpler mechanism for generating
outlines over all volumes in a project.

Arguments are:
<proj> SeisWorks project name

<2/3> 2 for 2D, 3 for 3D
<seismic> seismic file name or proclev, e.g. mig0801.3dv or mig080001
<stride> look-ahead factor (default 25 traces 3D only)
<delta> thinning distance (default 10 traces 3D only)
<lineinc> line increment for symbol posting (default 100 3D only)
<traceinc> trace increment for symbol posting (default 100)
<xsize> approximate image size, in pixels (default 500)
<padding> padding around image, in pixels (default 40)
<outfile> output image file name (default stdout).
An alternative 3D-only algorithm that does read every trace is currently under
development. Although it is considerably slower, it can handle internal holes within the
survey, non-contiguous pieces of seismic data, and decimated surveys. To test this
algorithm, use the lmksh proc seis2png2, with same arguments as seis2png:
lmksh{1}% seis2png2 devnor 3 mig0801.3dv 0 2 50 50 800 40 tmp.png
Generating Outlines for all Volumes in a Project
To generate outlines for all volumes for a project, use Do2DSeismaps or

Do3DSeismaps. This includes a clobber argument (3D only), allowing you to regenerate
all images (clobber) or only regenerate if the seismic has been modified since the last live
trace outline was created (noclobber). Note that an output file name need not be specified
as the png, ascii or zgf file is placed in the project sys directory with the following naming
convention:
png image: <sysdir>/<swproj>/<swproj>.<seismic>.png
ASCII file: <sysdir>/<swproj>/<swproj>.<seismic>.asc
ZGF file: <owprojdata>/<owproj>/<swproj>_outlines.zgf

(Each seismic volume produces a single picture within the ZGF file.)
Shapefile: <sysdir>/<proj>/<swproj>_outlines.shp
(Each seismic volume produces a single shape within the shapefile.)
Do2DSeismaps arguments are:

<xsize> approximate image size, in pixels (default 500).

Do3DSeismaps arguments are:
<fmt> png, asc, zgf or shp
<clobber> default is noclobber, i.e. only regenerate if the seismic has changed
<stride> look-ahead factor for 3D (default 25 traces)
<delta> thinning distance for 3D (default 10 traces)
<lineinc> line increment for symbol posting (default 100 ignored for 2D)
<xsize> approximate image size, in pixels (default 500).
Examples:
lmksh{1}% Do3DSeismaps devnor png (generates default png pictures)
lmksh{1}% Do3DSeismaps devnor png clobber 25 10 50 50 800
(overwrite the defaults with new parameters).
Generating Outlines for all Projects
Finally, to generate outlines for all 2D or 3D projects, the scripts

$OWHOME/WebApps/bin/ DoAll2DSeismaps.sh and DoAll3DSeismaps.sh will
run on the command line with options as shown below. For 3D, specify the c flag to
clobber; skip it for noclobber.
prompt> DoAll2DSeismaps.sh -t <traceinc> -x <xsize>
prompt> DoAll3DSeismaps.sh c f <format: png|asc|zgf|shp>

s <stride> -d <delta> -l <lineinc> - t <traceinc> -x <xsize>
Computing Lat/Long Outlines
To convert the ASCII live trace outlines from XY to Lat/Long coordinates, you can run a
general purpose command-line conversion on an ASCII file as follows:
ConvertFileXYtoLL <owproj> <filein> <fileout> <X column> <Y column>
The utility takes as input a columnar ASCII file and computes/inserts latitude and longitude
for the specified column IDs containing the X and Y coordinates. The CRS information is
taken from the specified OpenWorks project. You will need to delete or insert a # before
any header lines in the ASCII line. The reverse ConvertFileLLtoXY can also be used.

Using ZGF Backdrops
The SeisWorks navigation, live trace outline and horizon map displays can be enhanced
through the use of ZGF cultural backdrops. This allows the maps to include wells, fields,
leases, bathymetry, coastlines, shipping lanes etc. whatever is in the specified ZGF
picture.
ZGFs are ideal for cultural backdrops, in that they are the Landmark standard neutral
backdrop culture format. They are widely used across applications and can be created in
SeisWorks, StratWorks, Z-MAP Plus and via the Map Data Manager.
There is however no accepted default naming convention or even location for these files
they are often, but not universally, stored in the ZGF subdirectory of the OW_PROJ_DATA
directory of the associated OpenWorks project.
WOW therefore needs to provide a flexible, customizable way of specifying which ZGF
and picture to use for which SeisWorks project. Three locations are searched in order,
from most specific to most general:
1. WOW first looks for a file named .wow_backdrop in the SeisWorks system directory.
This is a simple ASCII text file containing two lines: the fully-pathed ZGF file name and
the picture name, e.g.
/data/seisworks/d0/colt/culture.zgf
GOM culture basemap
This allows any ZGF and any picture to be used, irrespective of file location.
2. If there is no .wow_backdrop file in the SeisWorks system directory, the next search
is for a file in the SeisWorks system directory named wow_backdrop.zgf. The first
picture from this file is displayed.
3. If there is neither a .wow_backdrop nor a wow_backdrop.zgf file in the

SeisWorks project system directory, the OW_PROJ_DATA ZGF associated
OpenWorks project directories are searched in order for a wow_backdrop.zgf file.
Again, the first picture from this file is used.
The advantage of option 3 above is that a single ZGF can be used as backdrop to all
SeisWorks projects associated with a single OpenWorks project. Options 2 and 1 allow for
increasingly more restrictive choices.
Important note: Unix filesystem links are all that is required to expose a cultural
backdrop. For example, if you already have existing ZGF files with arbitrary names:
cd <OW_PROJ_DATA>/<OpenWorks Project>/ZGF
ln s <actual ZGF name> wow_backdrop.zgf
Note also that the batch generation of seismic live trace outlines, using script
DoAll3DSeismaps.sh as described in the previous section, obeys the same rules as
defined above.

Customizing Choice of Color Maps
WOW utilizes SeisWorks color maps (.clm files) in 5 functions:
SeisWorks horizon display
SeisWorks seismic displays
SEG-Y image displays
OpenWorks grid displays
Z-MAP Plus grid displays
The choice of which color maps to use can be modified for the installation in the wow.env
file, by adding COLOR_SOURCE1 and COLOR_SOURCE2 environmental variables, e.g.:
vi wow.env
add line: COLOR_SOURCE1=PROJECT; export COLOR_SOURCE1
add line: COLOR_SOURCE2=DEFAULT; export COLOR_SOURCE2
COLOR_SOURCE1 applies to SeisWorks and has 3 options:
DEFAULT: a short hardcoded list. For horizons, the list is: rspectrum spectrum dipazim
blkwht whtblk. For seismic, the list is: blkwht whtblk blkwhtrd blkwhyel bluwhtbn
bluwhtrd grnwhtbn segfreq segphase segpolar segstg.
DIRECTORY: the contents of the directory $OWHOME/WebApps/dat/clm. You can

add color map files to this directory. You can delete SOME of the files, but not the
defaults listed above.
PROJECT: all color maps in the SeisWorks project system directory.
COLOR_SOURCE2 applies to SEG-Y, OpenWorks and Z-MAP Plus and has options of
DEFAULT or DIRECTORY as described above.
The recommended setting is DEFAULT as this produces the shortest selection lists and
therefore simpler user interfaces.

Customizing the Well, Field and Lease Modules
The lease module allows the editing of lease commitments, interests and remarks. Editing
can be turned off for sites that prefer read-only execution. Also, descriptive names can be
changed to take into account global differences, e.g. Lessee has meaning in the Gulf of
Mexico, whereas Block interests might be more applicable in the North Sea.
The file $OWHOME/WebApps/conf/lease_tables.dat controls lease module labels

and editing behavior. To customize the lease module:
cp lease_tables.dat.default lease_tables.dat
vi lease_tables.dat (see example below) and change labels/edit/multi flag.
# If present, the lease_tables file allows site-wide overwriting

# of the default lease table labels and editing behaviour.
# format: InternalKey TableName DetailFlag Label EditableFlag
# MultiLeaseSummaryFlag
# The 4th and 5th items (Label and EditableFlag) may be changed
# If EditableFlag is 'n/a', there is no edit functionality for the table.
# The 6th item controls appearance and can be edited if not n/a
document null YES Documents YES n/a
keyfact null YES "Key Facts" YES n/a
tract lease_tract NO Tract n/a n/a
boundary tract_boundary NO Boundary n/a n/a
lessee lessee NO Interests YES YES
lessor lessor NO "Lessor Interests" YES YES
commitment lease_commitment NO Commitments YES YES
narrative lease_narrative NO Remarks YES YES
Similar configuration files are used to control the labels and multi-object display properties
for wells, fields and basins. These cannot be edited at present through the browser.
$OWHOME/WebApps/conf/well_tables.dat:
Picks pick NO Picks n/a YES
Curves log_crv_hdr YES Curves n/a YES
Time-Depths time_depth_curve YES "Time Depths" n/a YES
Dir-Surveys dir_survey_hdr YES "Dir Surveys" n/a YES
Posn-Logs positional_log_hdr YES "Posn Logs" n/a YES
Synthetics synthetic_seismic YES Synthetics n/a NO
Lithology computed_lithology_hdr YES Lithology n/a NO
Casing casing NO Casing n/a NO
Cores well_core NO Cores n/a NO
Shows intrp_drilg_show NO Shows n/a NO
Tests well_test NO Tests n/a NO
Dipmeter dipmeter NO Dipmeter n/a NO
Paleo paleo NO Paleo n/a NO
Zone-Attributes strat_unit_intrp NO "Zone Attributes" n/a NO
Plugging plugging NO Plugging n/a NO
DST-RFTs dst_rft_gen NO "DST RFTs" n/a NO
Interests well_interest NO Interests n/a NO
Dates well_date NO Dates n/a NO
Alt-UWIs well_uwi_alt NO "Alt UWIs" n/a NO
Well-Study well_study NO "Well Study" n/a NO
Note-Pad well_note_pad NO "Note Pad" n/a NO
Remarks well_remark NO "Remarks" n/a NO
$OWHOME/WebApps/conf/field_tables.dat:
interest field_prospect_interest NO Interests n/a YES

Customizing the Key Facts Module
The key facts module allows users to add a note against wells, fields, leases and basins.
These notes are a collection of up to 20 long remarks, each up to 2000 characters in
length, associated with an individual well, field or lease. The key facts are implemented in
the OpenExplorer KRS model.
The attributes that may be edited are controlled on a site-wide basis by the following
configuration files. The required flag and display order flags are not yet implemented.
Important note: you should review and customize these before entering large quantities
of data.
$OWHOME/WebApps/conf/well_keyfacts.dat:
# Format: ColumnName(COL01-COL20) ColumnLabel Required(Y/N) DisplayOrder
# NOTE: column labels must be 25 chars or less!
COL01 "Well Prognosis" N 1
COL02 "Pre-Drill Risk Review" N 2
COL03 "Drilling Summary" N 3
COL04 "Tests / Shows" N 4
COL05 "Reservoir Review" N 5
COL06 "Postmortem" N 6
COL07 "Data Availability" N 7
COL08 "Scout Info" N 8
COL09 "Other Comments" N 9
$OWHOME/WebApps/conf/field_keyfacts:
COL01 "Exp/Appraisal History" N 1
COL02 "Geology" N 2
COL03 "Geophysics" N 3
COL04 "Reservoir Engineering" N 4
COL05 "Facilities" N 5
COL06 "Economics" N 6
COL07 "Development Plans" N 7
$OWHOME/WebApps/conf/lease_keyfacts:
COL01 "Exploration History" N 1
COL02 "License History" N 2
COL03 "Geology" N 3
COL04 "Geophysics" N 4
COL05 "Structure" N 5
COL06 "Plays" N 6
COL07 "Seismic" N 7
$OWHOME/WebApps/conf/basin_keyfacts:
COL01 "Exploration History" N 1
COL02 "Play Summary" N 2
COL03 "Stratigraphy" N 3
COL04 "Reservoir" N 4
COL05 "Source" N 5
COL06 "Seal" N 6
COL07 "Structure" N 7
COL08 "Timing" N 8

Customizing the Comparison Module
The Comparison module allows users to compare well, field, lease and navigation headers
as well as details on well position logs, curves, picks and time-depth tables.
In addition to the above, users may compare counts for any well-related reference data
types. For example, do the wells have the same number of casing points in two different
projects? The default option caters for cores, tests, casing, tubing, completions,
perforation, liners, packers, dipmeters, shows, paleo and mud reports.
The list is customizable using the default file well_comparison.dat.default in

$OWHOME/WebApps/conf. To modify the defaults, copy this file to
well_comparison.dat and add tables as indicated by the syntax description. Note
that any tables added must contain a well_id field.
# If present, the well_comparison.dat file allows the specification of

# additional well data types for the comparison of data between 2 OpenWorks
# projects. Comparison will simply be on counts per well.
#
# format: TableName Label
#
well_core Cores
well_test Tests
casing Casing
tubing Tubing
well_completion Completions
well_perforation Perforations
liner Liners
packer Packers
dipmeter Dipmeters
intrp_drilg_show Shows
paleo Paleontology
mud_report "Mud Report"

OpenJournal Integration
Publishing OpenJournals
The Publish form in WOW is designed to allow the automatic sharing of OpenJournal
projects in a two-tier system of working vs. published OpenJournal projects. Rather than
copying the published OpenJournals to a new location, the publication takes place in situ
by creating a .auto_publish file in the project directory.
When the user clicks on the OpenJournal link, then View published OpenJournals, this
will automatically search the OpenJournal project tree and build a table of published
projects whenever it encounters the .auto_publish file. Note that this search starts in
the OpenJournal project directory, $OWHOME/WebApps/htdocs/openjournal_data,
within which are links to all parent directories of OpenJournal projects.
The .auto_publish file is a simple ASCII file, which may be edited outside of WOW
with any text editor. The format is illustrated below:
Title: OpenJournal Tutorial Project

Author: Andrew Greig
Date: 2001/08/14
Category: Support
Keywords: Landmark,OpenJournal,Badleys,support,tutorial
Description: This OpenJournal contains a description of how to
use the product. It includes a detailed description of the Image
drag&drop and text annotation functionality.
If you intend to create this file outside of WOW, then take note of the following points:
a space is required after the : before the metadata itself
keywords are comma-separated without spaces after the comma
only the description may span multiple lines (must be last in the file).
OpenWorks/SeisWorks Integration
Any OpenJournal project linked into $OWHOME/WebApps/htdocs/openjournal_data

(see exposing additional directories) or a single subdirectory level below, will appear as a
hypertext link on the OpenWorks or SeisWorks project summary page in WOW, provided
its name begins with the name of the OpenWorks of SeisWorks project.
For example, if the SeisWorks project is named mc3d, an OpenJournal project named
mc3d_dataloading_history will automatically appear on the SeisWorks project
summary page. The name will be the internal OpenJournal title, rather than the project
(directory) name.

OpenExplorer GIS Integration
OpenExplorer uses ESRIs ArcView GIS software. WOW integrates with OpenExplorer
ArcView in the following ways, described in more detail in the subsequent paragraphs:
Saving WOW images for use as backdrops within ArcView
ArcView/ArcGIS integration, i.e. launch WOW by clicking on a data object in ArcView
Loading Z-MAPPlus grids into ArcView grid format
ArcIMS integration, i.e. integration with ESRIs Web mapping software
Saving GIS Image Backdrops
ArcView and GIS is aimed predominantly at vector data. It is however possible to load
raster images as backdrops to cultural information in GIS. WOW images can be exported
in an ArcView-compatible format for a number of data types:
OpenWorks grids
Z-MAPPlus grids and pictures
SeisWorks horizon, navigation and live trace outlines
Of the above, the most important are the raster types: OpenWorks and Z-MAPPlus grids
and SeisWorks horizons. There are alternative and better methods for viewing Z-MAPPlus
pictures and SeisWorks live trace outlines in ArcView.
In the relevant parts of WOW, select the Create GIS Image checkbox. This will save a .jpg
file and an associated world file with .jpgw extension, which provides ArcView with the
parameters required to geo-reference the image. The image can then be viewed in
ArcView as a theme, after loading the JPEG extension.
Important note: WOW will attempt to write images to

/oe_gisdat2/oegis/wow_images, or $OEGIS_DAT/wow_images. You should either
create an /oe_gisdat2 link on the WOW server, or add a definition of the OpenExplorer
OEGIS_DAT variable in wow.env, i.e.
vi wow.env
add at end: OEGIS_DAT=/data/oe_data; export OEGIS_DAT
ArcGIS Integration
An ArcGIS .dll provides substantially the same functionality as the current WOW ArcView
extension described overleaf. This allows users of ArcGIS to launch WOW in context by
clicking on objects in shapefiles created by OpenExplorer. For further information, see
$OWHOME/WebApps/gis/arcgis.pdf.

OpenExplorer ArcView Extension
WOW includes an ESRI ArcView 3.x extension for integrating with ESRIs ArcView 3.x
and ArcIMS 3.x products. For the extension to function correctly, the OpenExplorer GIS
extension should also be loaded to the project. The extension contains tools that allow the
user to launch WOW in context from data attributes contained in an ArcView 3.x working
view or ArcIMS map. Currently supported data types are wells, fields, leases, SeisWorks
3D projects, seismic lines and OpenWorks projects. The extension also allows the
importing of Z-MAP Plus grids into an ArcView theme.
The WOW GIS Tools extension requires the following environment variables to be set:
WEB_BROWSER: the browser execution command on your platform, e.g.

netscape.exe (PC) or netscape (Unix). This may need to be fully pathed on both
Unix and PC.
WEBSERVER_URL: full name of the WOW server (including http://), e.g.

http://oilco.houston.com
WOW_HOME: Path to the WOW software location, e.g. $OWHOME/WebApps.
AVHOME: Path to the ArcView software location, e.g. /oe_arcview3.
With the exception of the WEB_BROWSER variable, the extension attempts to read these
from your environment. When you first try to access any functionality you will be prompted
to review these settings and edit them if appropriate (usually simply clicking OK will
suffice). Additionally these variables can be set in the operating system environment (e.g.
in a users .login file), or at any time within the ArcView session, by using the
Environment' option on the WOW menu.
Integrating with ArcView
To run WOW in context from a working view:
1. Copy the GIS extension from the WOW install directory

($OWHOME/WebApps/gis/wow.avx) to either the users home directory or the
ArcView installation ext directory.
2. Run OpenExplorer GIS and load the WOW GIS Tools extension to an ArcView
project.
3. In a working view create themes from OpenWorks data (these should contain a valid
primary key, e.g. for a well, it is well_id).
4. Select a theme to query using WOW, by making it the active theme.
5. Launch WOW by clicking the 'star' (*) icon on the toolbar menu and selecting a data
object from within the view.
6. Set the appropriate environment, if required (see above).
7. WOW will then launch in a web browser window, showing the data summary page of
the data object selected. You can then continue to navigate within WOW as normal.

To import a Z-MAP Plus grid into ArcView
Important note: This functionality requires the ArcView Spatial Analyst extension to have
been installed with both AvSpatial1 and ArcView3 licenses available. Additionally, grids
are imported in an XY coordinate system - It is the users responsibility to ensure that the
Z-MAP Plus grid and the ArcView view are projected identically.
This functionality can be executed from a WOW grid detail page, or as described below.
1. Load the WOW GIS Tools extension to an ArcView project.
2. Select 'WOW > Convert ZMAP Grid to ArcView'.
3. Set the appropriate environment if required (see above).
4. Navigate to and select the MFD containing the grid.
5. Select the grid from the list.
6. Confirm or alter the name of the output grid, ensuring there are no upper case
characters in the name.
7. The grid is converted to ArcInfo grid format and can be imported to a projected view in
ArcView as either an image or as a grid. While both formats require the ArcView
Spatial Analyst extension to have been installed, importing as a grid additionally
requires the ArcView Spatial Analyst extension to have been loaded to the ArcView
project. Use the 'add theme' button to navigate to the location of the output data (it may
help to change 'Data Source Type' to 'Image Data Source' or 'Grid Data Source'.) and select the
grid. It should then appear in the legend of your working view. Turn it to 'visible' to view
the data.
ArcIMS Integration
The WOW GIS extension also provides functionality to prepare OpenExplorer-generated

shapefiles for use within ArcIMS, ESRIs web-based GIS server.
1. In an OpenExplorer GIS working view create themes from OpenWorks data (these
should contain a valid primary key, e.g. for a well, it is well_id).
2. Add hyperlink fields to your OpenExplorer themes using the Add ArcIMS Hyperlink option
on the WOW menu.
3. Setup your ArcIMS website in the normal way. You could use ESRI's View2AXL script
packaged with this extension to create an AXL file to use as a start point.
4. Enable hyperlinks on your ArcIMS themes by editing the ArcIMSparam.js file in

your ArcIMS website, change:
var useHyperLink=false to var useHyperLink=true.
5. Add hyperlink tags for each theme you wish to integrate, e.g.
hyperLinkLayers[0] = "Wells";
hyperLinkFields[0] = "WOW";

Viewing CGMs in WOW
There are two different methods of implementation: client-side plugin or server-side

conversion, with advantages and disadvantages for both methods. A number of vendors
provide functionality in this area, e.g. Zeh (http://www.zeh.com) and SDI
(http://www.sdicgm.com), of which a few are mentioned below.
Client-side Plugin
A plugin is an extension to the browser that allows it to recognize the specific file type, in
this case CGM, and provide corresponding functionality. The advantage of this is rich
functionality, i.e. zoom, pan, scaled hardcopy etc. However, the entire CGM needs to
download to the client; these files can be large which increases network traffic. The plugin
also needs to be installed on every client system, with increased effort to install and
upgrade.
WOW has been tested with Larson WebView CGM Pro for Internet Explorer on the PC.
The Solaris version for Netscape has not been tested. See http://www.cgmlarson.com.
To implement, download and install the plugin as per the vendor instructions. Then copy
$OWHOME/WebApps/cgi-bin/parse_cgm.cgi.clientside to parse_cgm.cgi
Server-side CGM to PNG converter
Rather than process the entire CGM locally, the server-side approach converts the CGM
into a highly compressed, lower-resolution Web format such as a jpeg or png which is
understood automatically by the browser.
The advantage of this approach is fast displays with much reduced network traffic. There
is also only a single (server) installation required, rather than on a per-client basis.
However the speed and simplicity are achieved by trading off against functionality. The
server-side approach is adequate for a quick look but not for submitting scaled hardcopy.
Command-line CGM to png converters are available from JustCroft

(http://www.justcroft.com) and EasyCopy (http://www.augrin.com/prod/ec/easycopy.html).
WOW implements a demo converter from SDI (http://www.sdicgm.com) in the default
parse_cgm.cgi.
To implement, download and install the application as per the vendor's instructions. You
will need to copy $OWHOME/WebApps/cgi-bin/parse_cgm.cgi.serverside to
parse_cgm.cgi and give it the right syntax and path for the converter you are using.
Complications
To view cgm files client-side, they must be published under the WOW Apache web root,
e.g. under the Other link in WOW (or the Z-MAPPlus, OpenJournal or OpenExplorer
links). Thus cgm files in e.g. SeisWorks must be viewed by a server-side mechanism. The
client-side version of parse_cgm.cgi in fact simply copies the cgm from server to client,
assuming there is a client-side plugin.
Due to the complexities of this issue and the range of possible configurations and software
tools, additional services may be required to fully implement CGM viewing in WOW.

Maintenance and Troubleshooting
Apache
Apache is a freeware web server developed by the Apache Software Foundation

(http://www.apache.org). Apache is the most widely used web server on the Web. It has
excellent performance, is lightweight, stable, and very reliable. It should require almost no
maintenance from a system administration perspective.
Apache runs as root under WOW R2003. If you use the standard version of Apache
distributed with Solaris 8, then the requisite commands to start/stop Apache on system
boot/shutdown will already be configured (for Solaris, see /etc/init.d/apache,
/etc/rc?.d/K16apache. For Linux, see /etc/init.d/httpd). Apache will start
automatically at boot time, provided httpd.conf exists and is correctly configured in
/etc/apache (Solaris) or /etc/httpd/conf (Linux).
To check Apache is running:

ps ef | grep httpd
If no processes are found restart Apache manually (as root):

/usr/apache/bin/apachectl stop
/usr/apache/bin/apachectl start (Solaris)
/usr/sbin/apachectl stop
/usr/sbin/apachectl start (Linux).
If Apache is not running, and cannot be restarted, check the error log file
/var/apache/logs/error_log. (Solaris)
/etc/httpd/logs/error_log (Linux).
WOW
Due to Apaches reliability, most errors are WOW errors and appear as an Internal
Server Error in the browser. The Apache log file provides an excellent diagnostic
medium. If a repeatable error occurs in some part of WOW, do the following:
1. Repeat the operation.
2. On the WOW top bar, click on Show Error. This will display the last 40 lines of the
Apache error log, as well as the complete environment and WOW version number.
3. Capture this text and provide the output to your support representative for diagnosis.

Appendix 1: Typical wow.env File
#============================================================================
# Name:
# wow.env - required environment for WOW applications
#
# Usage:
# sourced by lmksh scripts
#
# Description:
# sets up OpenWorks, Tcl/Tk, apache web server environment
#
#----------------------------------------------------------------------------
#============================================================================
# Check for OWHOME, ORACLE_HOME, ORACLE_SID and WOW_HOME
# Change value of variables here if required
# Set OWSYSSID if NOT the same as ORACLE_SID
# Set OW_PMPATH to a default location if NOT OWHOME/conf
# Set LM_LICENSE_FILE if NOT OWHOME/lam/license.dat
#----------------------------------------------------------------------------
OWHOME=/apps/ow; export OWHOME

WOW_HOME=/apps/ow/WebApps; export WOW_HOME
ORACLE_HOME=/data3/oracle; export ORACLE_HOME

ORACLE_SID=exprodat; export ORACLE_SID
if [ "${OWSYSSID:-""}" = "" ]; then

OWSYSSID=exprodat; export OWSYSSID
fi
if [ "${OW_PMPATH:-""}" = "" ]; then

OW_PMPATH=${OWHOME}/conf; export OW_PMPATH
fi
if [ "${LM_LICENSE_FILE:-""}" = "" ]; then

LM_LICENSE_FILE=${OWHOME}/lam/license.dat; export LM_LICENSE_FILE
fi
#============================================================================
# Set up Web server environment
# Change value of all variables here
#----------------------------------------------------------------------------
# Name of apache user

APACHE_USER=bruce; export APACHE_USER
# Fully qualified URL to web server

WEBSERVER_URL=http://exprotech; export WEBSERVER_URL
# Variables for configuring mail sent by forms

MAIL_TO="user1@company.com, user2@company.com"; export MAIL_TO
MAIL_SUFFIX=company.com; export MAIL_SUFFIX
# Security level
SECURITY_LEVEL=B; export SECURITY_LEVEL

# Where clause controlling subselect of OpenWorks projects
OW_PROJ_WHERE="where project_name not like '%TIGHT%'"; export OW_PROJ_WHERE
# Variable used by KRS to find documents (change both name and location)
KRS_VARIABLE=KRSDATA; export KRS_VARIABLE
KRSDATA=/data/krsdocs; export KRSDATA
#============================================================================
# WOW post-installation optional variables
# Uncomment and change value of variables here as appropriate
#----------------------------------------------------------------------------
# Colour map settings

#COLOR_SOURCE1=PROJECT; export COLOR_SOURCE1
#COLOR_SOURCE2=DIRECTORY; export COLOR_SOURCE2
# Well name display format (default is well_uwi)

#WELL_NAME_SQL="well_name_free"; export WELL_NAME_SQL
# Well header extra attributes (default is no extra attributes)

#WELL_HEADER_EXTRAS='permit_no "Permit",'; export WELL_HEADER_EXTRAS
# Debug flag (WARNING: debug information is not consistent and may be verbose)
#WOW_DEBUG=1; export WOW_DEBUG
# ArcView variables may be required for OpenExplorer integration

#AVHOME=${OWHOME}/OpenExplorer/arcview3/esri/av_gis30/arcview; export AVHOME
#OEGIS_DAT=/data1/oegis_data; export OEGIS_DAT
#============================================================================
# DO NOT CHANGE ANYTHING IN THIS SECTION
# auto-generated
#----------------------------------------------------------------------------
# Apache location (should not need to change)

APACHE_HOME=/var/apache
# Web root (should not need to change)

WEB_ROOT=${WOW_HOME}/htdocs; export WEB_ROOT
# Location of files relative to WEB_ROOT (should not need to change)

HTML_REL_LOC=/wow; export HTML_REL_LOC
# Location of the cgi-bin directory (should not need to change)

CGI_BIN_LOC=${WOW_HOME}/cgi-bin; export CGI_BIN_LOC
# URL to web server cgi-bin directories (should not need to change)

CGI_PARENT=${WEBSERVER_URL}/bin; export CGI_PARENT
# SeisWorks
if [ -d ${OWHOME}/SeisWorks ]; then
SEISHOME="${OWHOME}/SeisWorks"; export SEISHOME
fi
# SeisUtils
if [ -d ${OWHOME}/SeisUtils ]; then
SEISUTILSHOME="${OWHOME}/SeisUtils"; export SEISUTILSHOME
fi

# ZMAPPlus
if [ -d ${OWHOME}/ZMAPPlus ]; then
ZYCORHOME="${OWHOME}/ZMAPPlus"; export ZYCORHOME
fi
# set Tcl/Tk library locations

TCL_LIBRARY=${WOW_HOME}/tcltk/tcl8.3; export TCL_LIBRARY
TK_LIBRARY=${WOW_HOME}/tcltk/tk8.3; export TK_LIBRARY
# set LD_LIBRARY_PATH
LD_LIBRARY_PATH=${OWHOME}/lib:${OWHOME}/SeisWorks/lib:${WOW_HOME}/tcltk/lib
export LD_LIBRARY_PATH
#============================================================================
# Corporate Data Archiver environmentals
# Change value of all variables here
#----------------------------------------------------------------------------
# Name of OW project to store Archive database records

ARCHIVE_OW_PROJECT=EMPTY; export ARCHIVE_OW_PROJECT
# Email address of the Archive administrator

ARCHIVE_ADMIN_EMAIL=${MAIL_TO}; export ARCHIVE_ADMIN_EMAIL
# Stub directory
ARCHIVE_STUB_DIR=/data1/archive_stub; export ARCHIVE_STUB_DIR
# Stub URL
ARCHIVE_STUB_URL=http://exprotech/wow/archive_stub; export ARCHIVE_STUB_URL
# Staging directory
ARCHIVE_STAGE_DIR=/data1/archive_stage; export ARCHIVE_STAGE_DIR
# Default tape device

ARCHIVE_TDEVICE=/dev/rmt/0n; export ARCHIVE_TDEVICE
# Tape device capacity in Mb

ARCHIVE_CAPACITY=40000; export ARCHIVE_CAPACITY
#============================================================================
# CDA post-installation optional variables
# Uncomment and change value of variables here as appropriate
#----------------------------------------------------------------------------
# Archive in browser flag: ARCHIVE is the default, REQUEST means send email only
#ARCHIVE_BROWSER_FLAG=REQUEST; export ARCHIVE_BROWSER_FLAG
# Flag to print timestamps in archiver log file: 1=on 0=off (default)

#ARCHIVE_TIMESTAMPS=1; export ARCHIVE_TIMESTAMPS
# Default control file location for opening/saving (default is user HOME dir)
#ARCHIVE_CTL_LOC=${ARCHIVE_STUB_DIR}; export ARCHIVE_CTL_LOC
#============================================================================
# End of script
#============================================================================

Appendix 2: Summary of Important Files
The following table summarizes the main files used by WOW and Apache.
File/Directory Description
/etc/apache (Solaris):
/etc/httpd/conf (Linux):
httpd.conf Main apache configuration file
.wp Password file used for Apache authentication
/usr/apache/bin (Solaris):
/usr/sbin (Linux):
apachectl Starts and stops Apache
httpd The Apache web server
/usr/apache/bin (Solaris):
/usr/bin (Linux):
htpasswd Creates/adds Apache passwords
/var/apache/logs (Solaris):
/etc/httpd/logs (Linux):
access_log Stores all Apache server accesses
error_log Stores all Apache server errors for diagnostics
/var/run (Solaris):
/etc/httpd/logs (Linux):
httpd.pid Process ID of the Apache parent process
$OWHOME/WebApps/bin Directory containing WOW executables and wrappers
$OWHOME/WebApps/cgi-bin Directory containing WOW dynamic executables
$OWHOME/WebApps/dat/ Directory containing SQL scripts used in the QC/QA section

sqlscripts:
$OWHOME/WebApps/gis:
wow.avx The WOW ArcView extension
$OWHOME/WebApps/install:
WOWInstall The WOW install script

$OWHOME/WebApps/htdocs:
WOW_README.change_server Sed script to change Apache server name
logos: Directory containing logos used by the Links section
openjournal_data: Directory containing links to OpenJournal parent directories
zmap_data: Directory containing links to Z-MAP Plus parent directories
openexplorer_data: Directory containing links to ArcView shapefile data
other_data: Directory containing links to SEGY, LAS and DGN data
push_output: Directory for subscription reports
$OWHOME/WebApps/conf:
lease_tables.dat Customize lease labels and whether editable
well_tables.dat Customize well labels and multi-object display
field_tables.dat Customize field labels and multi-object display
lease_keyfacts.dat Add a note attributes for leases
well_keyfacts.dat Add a note attributes for wells
field_keyfacts.dat Add a note attributes for fields
basin_keyfacts.dat Add a note attributes for basins
other_sources.dat List of web URLs used by the Links section
restricted_dir_list.dat List of directories that may not be browsed in WOW
restricted_plist.dat List of SeisWorks projects that may not be browsed in WOW
wow.env Main WOW configuration file see appendix 1
wow_sidlist.dat List of SIDs for multiple instance support
wow_distlist.dat List of districts for multiple OW_PMPATH support
wow_menu.dat Customize WOW left frame menu
ascii_file_extensions.dat List of ASCII extensions recognized by directory browsers
web_file_extensions.dat List of inbuilt extensions recognized by directory browsers
well_comparison.dat Lists of tables whose counts may be compared between wells
$OWHOME/WebApps/kdoc/
sqlscripts
create_pim_project_ SQL script to allow site-specific settings for WOW Documenter
extension_custom.sql at create time
update_pim_owsys_comments SQL script to update settings for existing WOW Documenter
.sql owsys tables
update_pim_project_comments SQL script to update settings for existing WOW Documenter
.sql project tables

$OWHOME/WebApps/templates:
dotlmkrc Dot file for lmksh for command-line execution
dotlogin C-shell WOW full environment
dotlogin2 C-shell WOW light environment
dotprofile Bourne-shell WOW full environment
launcher.dat.extra Launcher entries for WOW Documenter
dothtaccess Default Apache .htaccess file

The diagrams below display these files and directories. Bold entries signify directories,
normal fonts represent files. Note that not all files are shown, only those that a WOW
administrator need be aware of.
$OWHOME/WebApps
bin cgi-bin dat conf gis install htdocs kdoc templates push
dotlmkrc
*.cgi sqlscripts wow.avx WebAppsInstall sqlscripts dotlogin
*.tbc dotprofile
dothtaccess
lmksh wow.env index.html

rlmksh wow_sidlist.dat README.change_server
lmksh_wrapper wow_distlist.dat *.css
avsh restricted_plist.dat *.js
avsh_wrapper restricted_dir_list.dat *.pdf
DoAll2DSeismaps.sh well/field/lease_tables.dat logos
DoAll3DSeismaps.sh well/field/lease_keyfacts.dat openjournal_data
DoPush wow_links.dat zmap_data
kdoc wow_menu.dat openexplorer_data
ascii_file_extensions.dat other_data
web_file_extensions.dat push_data
well_comparison.dat
well_match.dat
/usr/apache /etc /var /var/apache
bin apache run logs
httpd httpd.conf httpd.pid error_log

apachectl mime.types access_log
htpasswd .wp

Appendix 3: WOW Architecture
The fundamental concept behind WOW is dynamic access to data. This means that the
majority of content is generated on the fly programmatically by reading the underlying
databases, formatting and then sending results to a Web browser.
WOW is a server-side application. There are no client-side dependencies, i.e. plug-ins to

be downloaded or installed, considerably simplifying maintenance. The majority of data
access is therefore done on the server, via an application API or devkit.
This architecture is designed to separate data I/O from business logic, from presentation
logic as illustrated in the figure below:
WOW Architecture
Web browser (thin client)
Any platform
Unix
Web server Apache
Presentation logic cgi-bin (compiled Tcl)
Business logic Devkit shell procedures (compiled Tcl)
Data integration Devkit shells (C++)

Data I/O OpenWorks Oracle ZMAP Plus SeisWorks Other
devkit OCI devkit devkit api
SeisWorks
ZMAP Other
Data / data servers Open- Open- horizons
mfd seismic data
Works Works zgf projects
Data layer: WOW currently covers OpenWorks, SeisWorks, Z-MAP Plus and other data
types, including SEG-Y, OpenJournal etc.
Data I/O layer: This layer is comprised of the application devkits, which provide a safe
mechanism for reading/writing the data stores.
Data Integration Layer: This provides an integration layer on top of the diverse devkits to
allow consistent read/write of vendor data. WOW uses a number of devkit shells, which
are Tcl/Tk shells extended with the underlying devkit functions.
Business Logic Layer: This layer wrappers the lower-level extensions with business
logic, including error checking, lists of values, numerical computations etc. This provides a
consistent, modular, interface to the underlying data stores.
Presentation Layer: This layer executes the shell the web server in response to being
passed a URL by a web browser. It calls procedures from the business logic layer, and
formats output on the fly as html to send back to the browser.

Appendix 4: Apache Installation Options
Introduction
This section discusses options for customizing the Apache installation, such as changing
server or port, running multiple instances, shortening the WOW URL etc.
When planning any non-default installation or customization of WOW, administrators

should be aware of the critical configuration files for Apache and for WOW. Most changes,
e.g. to server and port, will require editing in these three locations:
All Apache configuration is controlled by a singe file, httpd.conf in /etc/apache

(Solaris) or /etc/httpd/conf (Linux). This file contains the important variables
such as ServerName and Port.
All WOW configuration (with the exception below) is stored in a single file,
$OWHOME/WebApps/conf/wow.env.
The only static part of WOW that does not use wow.env, is contained in directory
$OWHOME/WebApps/htdocs. The files index.html and wow_css.js both
contain hardcoded URLs, which will need to be changed if server or port is changed.
Obtaining and Installing the Solaris Apache Package
Apache comes as an optional software package with the Solaris 8 operating system. If
installed, directory /etc/apache will exist. To confirm that Apache is installed, type:
pkginfo | grep Apache
There should be three Apache packages installed: SUNWapchd, SUNWapchr and
SUNWapchu. If the packages are not found, please install them from the Solaris 8
companion software CD.
Alternatively, a compressed tarfile is provided for convenience on isite.lgc.com, file

/products/WOW/apache/apache_solaris_package.tar.gz. Download this file,
uncompress and add the package (as root):
gzip dc apache_solaris_package.tar.gz | tar xvf -
pkgadd d .
Obtaining and Installing the Red Hat Linux Apache RPMs.
Apache comes as an optional software package with the Red Hat Linux 7.2 operating
system. If installed, directory /etc/httpd will exist. To confirm that Apache is installed,
type:
rpm qa | grep apache
There should be four Apache packages installed: apache-manual, apache-devel,
apacheconf and apache. If the packages are not found, please install them from the
Red Hat 7.2 Installation CDs.
Alternatively, a compressed tarfile is provided for convenience on isite.lgc.com, file

/products/WOW/apache/apache_linux72_rpms.tar.gz. Download this file,
uncompress and add the rpms (as root):
gzip dc apache_linux72_rpms.tar.gz | tar xvf -

rpm ivh apache-1.3.20-16.i386.rpm \
apache-devel-1.3.20-16.i386.rpm \
apacheconf-0.8.1-1.noarch.rpm \
apache-manual-1.3.20-16.i386.rpm
Patching the Solaris Apache Package
On Solaris, Landmark strongly recommends running Apache version 1.3.26 or above. To

check your version, click on Errors on the WOW top bar and look for the variable
SERVER_SOFTWARE.
The Solaris Apache patch is provided for convenience on isite.lgc.com, file

/products/WOW/apache/109234-09.zip. Download this file, unzip and patch the
package (as root):
unzip 109234-09.zip
patchadd 109234-09
<reboot>
/usr/apache/bin/apachectl start
Changing the Apache port post-install to a non-root port
Some sites may prefer to run Apache on a non-root port (> 1023). To accomplish this
post-install, you will need root access to perform the following:
1. Stop the Apache server:

Solaris: /usr/apache/bin/apachectl stop
Linux: /usr/sbin/apachectl stop
2. Edit the Apache configuration file to change the values of the following:
Solaris: vi /etc/apache/httpd.conf
line 306: Port (to the new port, > 1023, e.g. 8080)
line 78: PidFile (to a local disk location writeable by the non-root user)
line 523: ErrorLog (to a local disk location writeable by the non-root user)
line 548: CustomLog (to a local disk location writeable by the non-root user)
Linux: vi /etc/httpd/conf/httpd.conf
line 388: Port (to the new port, > 1023, e.g. 8080)
line 78: PidFile (to a local disk location writeable by the non-root user)
line 630: ErrorLog (to a local disk location writeable by the non-root user)
line 656: CustomLog (to a local disk location writeable by the non-root user)
3. Edit the Apache start script and change $PIDFILE variable as above:
Solaris: vi /usr/apache/bin/apachectl
line 23: PIDFILE=<PidFile>
Linux: vi /usr/sbin/apachectl
line 52: PIDFILE=<PidFile>
4. Add the port to the URL in the index.html file.

Solaris: vi /var/apache/htdocs/index.html
Linux: vi /var/www/html/index.html

5. An alternative to steps 2 and 3 is to make the default locations of PidFile, ErrorLog
and CustomLog writeable by the non-root user.
As the non-root user:
1. Start the Apache server:

Solaris: /usr/apache/bin/apachectl start
Linux: /usr/sbin/apachectl start
2. Add the port to WEBSERVER_URL in the wow.env file

vi $OWHOME/WebApps/conf/wow.env
line 46: add port to WEBSERVER_URL
3. Add the port to the URL in index.html and wow_css.js (2 locations in each)
vi $OWHOME/WebApps/htdocs/index.html
vi $OWHOME/WebApps/htdocs/wow_css.js
Changing the Apache server post-install
To move the WOW Apache server from one system to another, you will need root access
to perform the following steps:
1. Copy the httpd.conf file from the old to the new server.
Solaris: /etc/apache/httpd.conf
Linux: /etc/httpd/conf/httpd.conf
2. Edit the Apache configuration file to change the value of ServerName:

Solaris: vi /etc/apache/httpd.conf
line 342: change ServerName to the new server (may also be commented out)
Linux: vi /etc/httpd/conf/httpd.conf
line 439: change ServerName to the new server (may also be commented out)
3. Edit the WOW configuration file to change the value of WEBSERVER_URL:

vi $OWHOME/WebApps/conf/wow.env
line 46: change WEBSERVER_URL to new server URL
4. Change all references from old to new server in $OWHOME/WebApps/htdocs, files

index.html and wow_css.js (2 locations in each)
vi $OWHOME/WebApps/htdocs/index.html
vi $OWHOME/WebApps/htdocs/wow_css.js
5. Stop Apache on the old server and start Apache on the new server:
Solaris: /usr/apache/bin/apachectl stop (on old server)
/usr/apache/bin/apachectl start (on new server)
Linux: /usr/sbin/apachectl stop (on old server)
/usr/sbin/apachectl start (on new server)

Changing the Apache server during install
Sites may need to install WOW on a different system from which the Apache server will
eventually run. For example, WOW may need to be installed on an application server
containing the OpenWorks tree, which may be exported read-only to the intended Apache
server.
To achieve this, provide the hostname for the preferred Apache server rather than the
default during installation. Do NOT run root.sh on the installation system. Rather, copy
this to the intended Apache server and run the script locally.
Changing the Apache port during install
Sites may need to install WOW on a port other than the default port 80. To achieve this,
specify a port-qualified value for the WOW server full URL during installation, i.e.
http://<host>.<domain>:<port>.
You will need to edit httpd.conf and change the value of Port, as described above. It
may also be necessary to open up permissions on the files and directories used by the
PidFile, ErrorLog and CustomLog variables in httpd.conf.
Shortening the WOW URL (this step now done during installation)
By default, the WOW URL is http://<host>.<domain>/wow/, with the trailing slash

required by Apache. The WOW URL can be simplified to http://<host>.<domain>
without the /wow/ if the Apache server is not used other than by WOW. This involves
replacing the default Apache index.html file, with the WOW index.html (as root):
Solaris: cd /var/apache/htdocs
Linux: cd /var/www/html
cp index.html index.html.orig
cp $OWHOME/WebApps/htdocs/index.html .
vi index.html
line 12: change src="wow_info.html" to
src="http://<host>.<domain>/WebApps/wow_info.html"

Installing Multiple Apache Servers Solaris
An alternative to using WOWs multiple ORACLE_SID cookie-based solution is to install a

single Apache server per ORACLE_SID. In the example below, a default WOW instance
has been installed on http://wow.oilco.com; OWHOME is set to /apps/ow, and the 2nd
Apache instance is to be installed in /usr/local/apache1.
1. Obtain the Apache binary distribution. Either download from

http://www.apache.org/dist/httpd/binaries/solaris/, file apache_1.3.26-sun4u-sun-
solaris2.280.tar.gz, or from isite.lgc.com, directory
/products/WOW/apache.
2. Install Apache to a local disk (make sure it is writeable first):

gzip -dc apache_1.3.26-sun4u-sun-sol2.280.tar.gz | tar xvf -
cd apache_1.3.26
./install-bindist.sh /usr/local/apache1
3. Configure Apache httpd.conf and make the following changes:

vi /usr/local/apache1/conf/httpd.conf
line 304: Port 8081
line 318: User <your WOW user>
line 319: Group <group of WOW user>
line 326: ServerAdmin <system administrators email>
line 648: change AllowOverride None to AllowOverride AuthConfig
line 612: insert line Alias /wow/ "/apps/ow/WebApps1/htdocs/"
line 654: add the following stanza:
ScriptAlias /bin/ "/apps/ow/WebApps1/cgi-bin/"
<Directory "/apps/ow/WebApps1/cgi-bin">
AllowOverride AuthConfig
Options None
Order allow,deny
Allow from all
</Directory>
4. Start Apache
/usr/local/apache1/bin/apachectl start
5. Duplicate the WOW software tree:

cd $OWHOME
mkdir WebApps1
cd WebApps
find . -depth -print | cpio -pdlmv ../WebApps1
6. Configure WOW:
Change all references from the default to the new port in files index.html and
wow_css.js, e.g. change wow.oilco.com to wow.oilco.com:8081 (2
locations in each)
cd $OWHOME/WebApps1/htdocs
vi $OWHOME/WebApps1/htdocs/index.html
vi $OWHOME/WebApps1/htdocs/wow_css.js
Update the wow.env file:
cd $OWHOME/WebApps1/conf

vi wow.env
line 21: change WOW_HOME to /apps/ow/WebApps1
line 46: change WEBSERVER_URL to wow.oilco.com:8081
line 68: change APACHE_HOME to /usr/local/apache1
Change ORACLE_SID, OWSYSSID, OW_PMPATH and other variables as appropriate.
cd /usr/local/apache1/htdocs
cp index.html index.html.orig (if it exists)
cp $OWHOME/WebApps1/htdocs/index.html .
7. Repeat steps above as often as is required, e.g.:

Port: 80, Apache: default OS package, WOW: $OWHOME/WebApps
Port: 8081, Apache: /usr/local/apache1, WOW: $OWHOME/WebApps1
etc.
Installing Multiple Apache Servers Linux

http://archive.apache.org/dist/httpd/binaries/linux/ , file apache_1.3.26-i686-whatever-
linux22.tar.gz, or from isite.lgc.com, directory /products/WOW/apache.

gzip -dc apache_1.3.26-i686-whatever-linux22.tar.gz | tar xvf -
cd apache_1.3.26
./install-bindist.sh /usr/local/apache1
3. Configure Apache httpd.conf and make the following changes:

vi /usr/local/apache1/conf/httpd.conf
line 304: Port 8081
line 318: User <your WOW user>
line 319: Group <group of WOW user>
line 326: ServerAdmin <system administrators email>
line 648: change AllowOverride None to AllowOverride AuthConfig
line 612: insert line Alias /wow/ "/apps/ow/WebApps1/htdocs/"
line 654: add the following stanza:
ScriptAlias /bin/ "/apps/ow/WebApps1/cgi-bin/"
<Directory "/apps/ow/WebApps1/cgi-bin">
Options None
Order allow,deny
Allow from all
</Directory>
4. Start Apache
/usr/local/apache1/bin/apachectl start
5. Duplicate the WOW software tree:

cd $OWHOME
mkdir WebApps1

cd WebApps
find . -depth -print | cpio -pdlmv ../WebApps1
6. Configure WOW:
Change all references from the default to the new port in files index.html and
wow_css.js, e.g. change wow.oilco.com to wow.oilco.com:8081 (2
locations in each)
cd $OWHOME/WebApps1/htdocs
vi $OWHOME/WebApps1/htdocs/index.html
vi $OWHOME/WebApps1/htdocs/wow_css.js
Update the wow.env file:
cd $OWHOME/WebApps1/conf
vi wow.env
line 21: change WOW_HOME to /apps/ow/WebApps1
line 46: change WEBSERVER_URL to wow.oilco.com:8081
line 68: change APACHE_HOME to /usr/local/apache1
Change ORACLE_SID, OWSYSSID, OW_PMPATH and other variables as appropriate.
7. cd /usr/local/apache1/htdocs
cp index.html index.html.orig (if it exists)
cp $OWHOME/WebApps1/htdocs/index.html .
8. Repeat steps above as often as is required, e.g.:

Port: 80, Apache: default OS package, WOW: $OWHOME/WebApps
etc.
Upgrading Apache to a Native Apache Version Solaris
WOW by default uses the version of Apache shipped with Solaris 8, which may need to be
updated. The Sun version of Apache is provided in package format, which distributes files
over multiple operating system directories. The native Apache version installs into a single
directory, by default /usr/local/apache. This section describes the steps required to
upgrade Apache. These steps will require root privileges:
1. Shutdown the current version of Apache:

2. Download the Apache binary distribution into /tmp. Either download from
http://www.apache.org/dist/httpd/binaries/solaris/, file
apache_1.3.26-sun4u-sun-solaris2.280.tar.gz, or from
isite.lgc.com, directory /products/WebApps/apache.
3. Install Apache to a local disk using the install-bindist.sh script supplied:

cd /tmp
gzip -dc apache_1.3.26-sun4u-sun-sol2.280.tar.gz | tar xf -
cd apache_1.3.26
./install-bindist.sh /usr/local/apache

4. Configure Apache httpd.conf and make the changes listed below. It may be easier
to cut & paste from the original configuration file than to type in changes by hand. Line
numbers in brackets below are for the original file /etc/apache/httpd.conf.
vi /usr/local/apache/conf/httpd.conf
line 318 (320): User <your WOW user>
line 319 (321): Group <group of WOW user>
line 326 (328): ServerAdmin <system administrators email>
line 342 (344): ServerName <your server name>
line 612 (593): insert line Alias /wow/ "/your/OWHOME/WebApps/htdocs/"
line 654 (617): add the following stanza:
ScriptAlias /bin/ "/your/OWHOME/WebApps/cgi-bin/"
<Directory "/your/OWHOME/WebApps/cgi-bin">
Options None
Order allow,deny
Allow from all
</Directory>
(replace the value /your/OWHOME with the value of $OWHOME).
5. Start Apache
/usr/local/apache/bin/apachectl start
6. Change permissions on the logs directory to enable viewing of the error_log for
diagnostic purposes by a non-root user. This is an optional step: some sites may not
wish non-root users to view the log files, although this will make WOW error diagnosis
more difficult.
chmod 755 /usr/local/apache/logs
7. Modify the Apache boot-time startup/shutdown scripts:

vi /etc/init.d/apache
line 8: APACHE_HOME=/usr/local/apache
line 9: CONF_FILE=/usr/local/apache/conf/httpd.conf
line 10: PIDFILE=/usr/local/apache/logs/httpd.pid
8. Update the value of APACHE_HOME in the wow.env file:

vi wow.env
line 68: change APACHE_HOME to /usr/local/apache
9. Update the document root index.html file. Some sites will have previously
replaced the original Apaches start page /var/apache/htdocs/index.html with
an edited copy of $OWHOME/WebApps/htdocs/index.html. Others may use their
own index.html start page. In either event, copying the original file or files into the
new document root is required:
cp /var/apache/htdocs/index.html /usr/local/apache/htdocs

Upgrading Apache to a Native Apache Version Linux
WOW by default uses the version of Apache shipped with Red Hat 7.2, which may need to
be updated. The Red Hat version of Apache is provided in RPM format. The native
Apache version installs into a single directory, by default /usr/local/apache. This
section describes the steps required to upgrade Apache. These steps will require root
privileges:
1. Shutdown the current version of Apache:

/usr/sbin/apachectl stop

http://archive.apache.org/dist/httpd/binaries/linux/ , file apache_1.3.26-i686-whatever-
linux22.tar.gz, or from isite.lgc.com, directory /products/WOW/apache.

gzip -dc apache_1.3.26-i686-whatever-linux22.tar.gz | tar xvf -
cd apache_1.3.26
./install-bindist.sh /usr/local/apache
4. Configure Apache httpd.conf and make the changes listed below. It may be easier
to cut & paste from the original configuration file than to type in changes by hand. Line
numbers in brackets below are for the original file /etc/httpd/conf/httpd.conf.
vi /usr/local/apache/conf/httpd.conf
line 413 (413): User <your WOW user>
line 319 (414): Group <group of WOW user>
line 326 (421): ServerAdmin <system administrators email>
line 342 (439): ServerName <your server name>
line 612 (739): insert line Alias /wow/ "/your/OWHOME/WebApps/htdocs/"
line 654 (763): add the following stanza:
ScriptAlias /bin/ "/your/OWHOME/WebApps/cgi-bin/"
<Directory "/your/OWHOME/WebApps/cgi-bin">
Options None
Order allow,deny
Allow from all
</Directory>
(replace the value /your/OWHOME with the value of $OWHOME).
5. Start Apache
/usr/local/apache/bin/apachectl start
6. Change permissions on the logs directory to enable viewing of the error_log for
diagnostic purposes by a non-root user. This is an optional step: some sites may not
wish non-root users to view the log files, although this will make WOW error diagnosis
more difficult.
chmod 755 /usr/local/apache/logs
7. Modify the Apache boot-time startup/shutdown scripts:

vi /etc/init.d/httpd
line 22: apachectl=/usr/local/apache/bin/apachectl
line 23: httpd=/usr/local/apache/bin/httpd

Update the value of APACHE_HOME in the wow.env file:
vi wow.env
line 68: change APACHE_HOME to /usr/local/apache
8. Update the document root index.html file. Some sites will have previously
replaced the original Apaches start page /var/www/html/index.html with an
edited copy of $OWHOME/WebApps/htdocs/index.html. Others may use their
own index.html start page. In either event, copying the original file or files into the
new document root is required:
cp /var/www/html/index.html /usr/local/apache/htdocs
Moving the Apache Web Root (read-only $OWHOME)
WOW by default creates a Web alias from /wow/ to $OWHOME/WebApps/htdocs,

which is referred to as the Web Root. This location on disk contains static files, directories
and links that are customizable on a site-by-site basis. If your site requires that the
$OWHOME directory be entirely read-only, then the Web Root can be moved as described
below:
1. Change the Apache alias:

Solaris: vi /etc/apache/httpd.conf.
line 593 (approx): Alias /wow/ "/new-read-write-location/htdocs/"
Linux: vi /etc/httpd/conf/httpd.conf.
line 739 (approx): Alias /wow/ "/new-read-write-location/htdocs/"
2. Modify the WEB_ROOT variable in the wow.env file to the new location:
vi wow.env
WEB_ROOT=/new-read-write-location/htdocs; export WEB_ROOT
3. Copy the htdocs directory to the new read-write location:

cp r $OWHOME/WebApps/htdocs /new-read-write-location
4. Add the new location to the config file that prevent browsing above the web root:
vi $OWHOME/WebApps/conf/restricted_dirlist.dat
5. Restart Apache:
/usr/local/apache/bin/apachectl restart
In the scenario where a read-only $OWHOME is required, the WOW conf directory can also
be moved, and linked back to $OWHOME/WebApps, i.e.:
cd $OWHOME/WebApps
cp r $OWHOME/WebApps/conf /new-read-write-location
mv conf conf.orig
ln s /new-read-write-location/conf

Using NIS for Password Authentication
By default WOW uses a duplicated password file /etc/apache/.wp to store encrypted

passwords for authentication purposes. This is required for any activity if security level is
C, and for write activity at level B. If a client uses NIS, i.e. if a list of users and their
encrypted passwords can be obtained using ypcat passwd, then it is possible to
authenticate directly using the Apache mod_auth_pam module. The procedure is
described below (root is required):
1. Install mod_auth_pam.so :
cp $OWHOME/WebApps/dso/mod_auth_pam.so /usr/apache/libexec
chmod 755 /usr/apache/libexec/mod_auth_pam.so
2. Edit /etc/apache/httpd.conf, add entries to LoadModule/AddModule sections:

LoadModule pam_auth_module /usr/apache/libexec/mod_auth_pam.so
AddModule mod_auth_pam.c
3. Edit /etc/pam.conf, add the following lines at bottom:

# Apache httpd
httpd auth required /usr/lib/security/$ISA/pam_unix.so.1
httpd account required /usr/lib/security/$ISA/pam_unix.so.1
4. Edit $OWHOME/WebApps/cgi-bin/.htaccess, remove AuthUserFile line.
5. Restart Apache:
/usr/local/apache/bin/apachectl restart

Appendix 5: Background on the Devkit Shell lmksh
Introduction
The WebApps products WOW and Corporate Data Archiver are powered by Tcl/Tk
shells, extended with Landmark devkit functions. This provides a powerful yet simple
mechanism for extracting information from these project data sources for display in a table,
graphical user interface or Web page.
The main devkit shell lmksh integrates the OpenWorks, SeisWorks, Z-MAPPlus and ZGF
devkits with other apis providing coverage of e.g. GeoProbe, SEG-Y and LAS files.
Other than as documented in the main body of these Release Notes, command-line
usage of lmksh is not formally supported. This appendix is provided as an unofficial start
point to those interested in scripting their own command line utilities. Please note that no
support will be provided on either Tcl/Tk or on lmksh.
For more information on Tcl/Tk, try one of these books:

Tcl and the Tk Toolkit, by John Ousterhout, published by Addison-Wesley 1994,
ISBN 020163337X
Practical Programming in Tcl and Tk (4th Edition), by Brent Welch, Jeffrey Hobbs &
Ken Jones, published by Prentice-Hall 2003, ISBN 0130385603
Tcl/Tk in a Nutshell, by Paul Raines & Jeff Tranter, OReilly 1999, ISBN 1565924339.
Tcl/Tk: A Developers Guide (2nd Edition), by Clif Flynt, published by Morgan
Kaufmann 2003, ISBN 1558608028.
Some useful web sites:

Main Tcl/Tk site: http://www.tcl.tk
Neosoft (contributed source): http://www.neosoft.com/tcl
Tcl Wiki (getting started guide): http://wiki.tcl.tk
Newsgroup: news:comp.lang.tcl or http://groups.google.com/groups?group=comp.lang.tcl
Running lmksh
To run lmksh you require a .lmkrc file in your home directory and to have sourced the
required environment:
prompt> cp $OWHOME/WebApps/templates/dotlmkrc ~/.lmkrc (1-off)
prompt> source $OWHOME/WebApps/templates/dotlogin* (C-shell)
prompt> . $OWHOME/WebApps/templates/dotprofile (Bourne shell)
prompt> lmksh
lmksh{1}% OWSetup (configures OpenWorks environment)
lmksh{2}% SeisSetUp (configures SeisWorks environment)
lmksh{3}% info commands (lists all available commands)
lmksh{4}% info commands sdl* (lists commands beginning with sdl)
lmksh{5}% info procs (lists all available procedures)
lmksh{6}% info args hrzinfo (lists arguments for specified proc)
Alternatively, a wrapper script is provided and linked to $OWHOME/bin during installation:

prompt> rlmksh

Notes on .lmkrc: you will need to copy the .lmkrc into the home directory of every user
that wishes to run lmksh interactively:
prompt> cp $OWHOME/WebApps/templates/dotlmkrc $HOME/.lmkrc
Add or uncomment the commands OWSetup and SeisSetUp in .lmkrc so you do not
need to type these during every interactive session. Add or uncomment
SourceAllProcs to load all available commands.
The lmksh Commands
There are three classes of commands:
Tcl built-in commands: This is the core Tcl language. See the Tcl man pages or html
help at $OWHOME/WebApps/tcltk/htmldocs/tcltk.html for information on built-in
commands. To access the man pages:
prompt> source $OWHOME/WebApps/templates/dotlogin
prompt> man <cmd>
Extended commands: These are added to lmksh to provide scripted access to devkit
functions. The extended commands are usually low-level with little error trapping. Most
begin with sdl_ (SeisWorks), ow_ (OpenWorks), sil_ (MFD), zgf_ (ZGF), sgy_
(SEGY) and gen_ (LAS and others). To see the arguments for an extended command,
type the command name:
lmksh{7}% sdl_hrzinfo
Procedures: These are additional wrappers to the extended commands, including more
robust error trapping and other business logic to make the low-level commands more
useful. To see the arguments for any procedure:
lmksh{8}% info args hrzinfo
OpenWorks database access procedures usually start with a lowercase letter to denote
that they require an Oracle database connection to be established first, e.g.:
prompt> rlmksh
lmksh{9}% set lda [OWoralogon]
lmksh{10}% getWellLists TESTDATA
lmksh{11}% oralogoff $lda
Exposing lmksh Commands
It is sometimes more convenient to run lmksh procedures through a regular Bourne- or C-

shell. A wrapper script is provided in $OWHOME/WebApps/bin for this purpose. To
expose any lmksh procedure on the command line, create a link as illustrated below:
prompt> cd $OWHOME/WebApps/bin
prompt> ln s lmksh_wrapper <proc>
The procedure can then be run on the command line, with any required parameters
passed through to the underlying lmksh.
Health Warning
WOW and CDA are largely read-only applications. But the underlying lmksh has
additional destructive options, e.g. the ability to create, rename and delete
SeisWorks horizons. Use of these options is entirely at your own risk, and you
should always ensure you have a current backup before proceeding.

Landmark/Asia Pacific Landmark/EAME Landmark/The Americas
11th Floor Menara Tan & Tan Hill Park South Building 1, Suite 200, 2101 CityWest
207 Jalan Tun Razak Springfield Drive Houston, TX 77042
50400 Kuala Lumpur Leatherhead, Surrey KT22 7NL P.O. Box 42806, Houston, TX77242
Malaysia England U.S.A.
Tel: 60-3-2164-1121 Tel: 44-1372-868-600 Tel: 1-713-839-2000
Fax: 60-3-2164-1135 Fax: 44-1372-868-601 Fax: 1-713-839-2168
Help Desk: 61-8-9481-4488 Help Desk: 44-1372-868-686 Help Desk: 1-713-839-2200
Email: apsupport@lgc.com Email: eame_helpdesk@lgc.com Email: support@lgc.com
Trademarks
Landmark, the Landmark logo, 3D Drill View, 3D Drill View KM, 3DVIEW, Active Field Surveillance, Active
Reservoir Surveillance, ARIES, Automate, BLITZ, BLITZPAK, CasingSeat, COMPASS, Contouring Assistant,
DataStar, DBPlot, Decision Suite, Decisionarium, DecisionDesktop, DecisionSpace, DepthTeam, DepthTeam
Explorer, DepthTeam Express, DepthTeam Extreme, DepthTeam Interpreter, DESKTOP-PVT, DESKTOP-VIP,
DEX, DFW, DIMS, Discovery, Drillability Suite, DrillModel, DrillVision, DSS, Dynamic Surveillance System,
EarthCube, EdgeCa$h, eLandmark, EPM, e-workspace, FastTrack, FZAP!, GeoDataLoad, GeoGraphix,
GeoGraphix Exploration System, GeoLink, GES, GESXplorer, GMAplus, GrandBasin, GRIDGENR, I2 Enterprise,
iDims, IsoMap, LandScape, LeaseMap, LMK Resources, LogEdit, LogM, LogPrep, Make Great Decisions,
MathPack, Model Builder, MyLandmark, MyWorkspace, OpenBooks, OpenExplorer, OpenJournal, OpenSGM,
OpenTutor, OpenVision, OpenWorks, OpenWorks Well File, PAL, Parallel-VIP, PetroBank, PetroWorks, PlotView,
Point Gridding Plus, Pointing Dispatcher, PostStack, PostStack ESP, PRIZM, PROFILE, ProMAX, ProMAX 2D,
ProMAX 3D, ProMAX 3DPSDM, ProMAX MVA, ProMAX VSP, pStaX, QUICKDIF, RAVE, Real Freedom,
Reservoir Framework Builder, RESev, ResMap, RMS, SafeStart, SCAN, SeisCube, SeisMap, SeisModel,
SeisSpace, SeisVision, SeisWell, SeisWorks, SeisXchange, SigmaView, SpecDecomp, StrataMap, Stratamodel,
StratAmp, StrataSim, StratWorks, StressCheck, STRUCT, SynTool, SystemStart, T2B, TDQ, TERAS, Total
Drilling Performance, TOW/cs, TOW/cs The Oilfield Workstation, Trend Form Gridding, Turbo Synthetics, VIP,
VIP-COMP, VIP-CORE, VIP-DUAL, VIP-ENCORE, VIP-EXECUTIVE, VIP-Local Grid Refinement, VIP-
POLYMER, VIP-THERM, WavX, Web OpenWorks, Well Editor, Wellbase, Wellbore Planner, WELLCAT,
WELLPLAN, WellXchange, WOW, Xsection, ZAP!, Z-MAP Plus are trademarks, registered trademarks or service
marks of Landmark Graphics Corporation.
All other trademarks are the property of their respective owners.

WOW Release Notes PDF

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

WOW Release Notes PDF

Uploaded by

Copyright:

Available Formats

WOW R2003.3.1.

July 2004 Part No. 159509 R2003

Capture knowledge: allow users to document projects, providing context to enhance

WOW is part of Landmarks WebApps1 technology framework. It is a 'thin client'

WOW coverage is considerable and expanding in both depth and breadth:

Geolog is a registered trademark of Paradigm Geotechnology B.V.

GeoFrame is a registered trademark of Schlumberger.

WOW R2003.3.1.5 Release Notes Page 2 of 71 July 2004

Use of Native Apache

The actual Apache cgi-bin directory, /var/apache/cgi-bin, is not used by WOW.

Restructuring of WOW Directories

All configuration files have been centralized in a new $WOW_HOME/conf directory.

WOW R2003.3.1.5 Release Notes Page 3 of 71 July 2004

New WOW Security Model

Level A: universal read-only with named exclusions, no write-back allowed

Level B: universal read access with validated write-back

Level C: validated read and write-back (emulates native applications).

Simplified Installation Script

The WOW installation script $OWHOME/WebApps/install/WOWInstall now takes

Rationalized style sheets / Dynamic framework

FlexLM Licensing / Source Code Compilation

Improved Error Reporting

WOW R2003.3.1.5 Release Notes Page 4 of 71 July 2004

1. OpenWorks: added a navigation bar, similar to the SeisWorks module

Enhancement #132498: modified crontab to run at 4am on days 2-6

Defect #135965: Push email points to wrong URL

1. GIS: add ArcView shapefile viewer module

WOW R2003.3.1.5 Release Notes Page 5 of 71 July 2004

1. OpenWorks: Coverage of TDQ models plus external binary data

1. OpenWorks: added general support for multiple Oracle instances

WOW R2003.3.1.5 Release Notes Page 6 of 71 July 2004

WOW R2003.3.1 is a point product release. WOW must be reinstalled.

1. OW: added extra attributes to KRS document detail display

WOW R2003.3.1.5 Release Notes Page 7 of 71 July 2004

WOW R2003.3.1.5 Release Notes Page 8 of 71 July 2004

Other enhancements and bug fixes:

1. OW: fixed error in comparison saving well list to project 2 (#159311)

1. Changed SeisWorks project details table to display in right frame

1. Fixed SeisWorks timeslice image creation failure

WOW R2003.3.1.5 Release Notes Page 9 of 71 July 2004

1. GeoProbe: Added support for viewing GeoProbe 'Pictures' directory

1. GeoProbe: Changed volume count to only list .vol files

Enhancements and Fixes in this Version (R2003.3.1.5)

WOW R2003.3.1.5 is a patch release. It requires WOW R2003.3.1 to be installed first.

Bug fixes and enhancements:

WOW R2003.3.1.5 Release Notes Page 10 of 71 July 2004

Other Pre-installation Considerations

Before installing, you need to choose or confirm the following:

1. A system on which to run the Apache2server. Apache is a lightweight daemon

WOW R2003.3.1.5 Release Notes Page 11 of 71 July 2004

4. An install location, typically $OWHOME/WebApps, but may be any NFS-exported

WOW R2003.3.1.5 Release Notes Page 12 of 71 July 2004

Login to the chosen server as the chosen user.

Source the Landmark environment if not done by default:

Create and cd to the installation location ($WOW_HOME):

Untar the media:

Run the installation script:

CD Installer Method (WebApps)

Login to the chosen server as the chosen user.

Insert the WOW CD into the server CD drive

Stage 1 Installation Parameters

The installation script prompts for the following parameters:

WOW R2003.3.1.5 Release Notes Page 13 of 71 July 2004