|
POSC Specifications Version 2.2 |
Getting Started Using POSC Software |
This section will give examples and "tips" for using some of the POSC supplied software. It will rely on documentation for the software as given in the Data Access area of this Specification.
Before you can use the software, you must create the database and set up the environment. These steps are detailed in the articles, Setting Up the Environment and Set Up a Database. These two articles set up the environment variables that are used to choose the correct software.
Use of EntityLoader is documented in Appendix H of the Data Access and Exchange document. Refer to this area for details on setting up EntityLoader load files and running the program.
The section on Loading Your Own Data discusses the use of EntityLoader, and gives an example of building an EntityLoader file. Some of the details of how to build this file are discussed in that section.
Assuming that the environment has been set up properly and the loader file exists, % EntityLoader can be run with the following command:
$POSC_BIN/EntityLoader username password dbname < loadfilenamewhere the present implementations use the same name for username, password and dbname. Assuming these have been set similar to the example with username, password and dbname = 'db1', we would have
% $POSC_BIN/EntityLoader db1 db1 db1 < well.ELwhere we have used the loader file, well.EL, as built in the Loading Your Own Data example.
In addition, it is generally useful to redirect the output to a file (for example, well.out), and to run the process in the background. Thus the call would be:
% $POSC_BIN/EntityLoader db1 db1 db1 < well.EL >! well1.out &
The use of refLoadLevelOne is not significantly different. The call using the comparable example to the above would be
% $POSC_BIN/refLoadLevelOne db1 db1 db1 < well >! well2.out &where well is the refLoadLevelOne file as built in the Loading Your Own Data example.
However, because of the difference in the two, we have found it useful to add an extra file. The difference is that EntityLoader loads all the entities within the single file, while refLoadLevelOne loads only a single file. For this reason, we build a load_list file that contains the name of the files to load and the order in which to load them. Thus, our example loads the coordinate_system, well, wellbore, topological_relationship, etc. in a given order. We capture all the files, in the correct order, in the load_list file. The load_list file is given below:
--Under construction--We then us another script which converts this list of files into separate loadRefLevelOne calls. The script is similar to the following (loadRef.script):
#!/bin/csh -f
if ($#argv < 4) then
cat << EOF
Usage:
loadRef.script dbname password dbname directory load_list
loadRef.script uses refLoadLevelOne to load all of the files in
directory which are listed in load_list into the database specified
by the first three arguments.
EOF
exit 1
endif
setenv TMP .
setenv MY_USERNAME $1
setenv MY_PASSWORD $2
setenv MY_DBNAME $3
setenv SOURCE $4
setenv MY_LISTNAME $5
awk '{print "echo `date` " $1 ";$POSC_BIN/refLoadLevelOne $MY_USERNAME $MY_PASSWORD \
$MY_DBNAME < $SOURCE/" $1}' $MY_LISTNAME >! $TMP/aaaRefEntitySyb
pushd $TMP
csh aaaRefEntitySyb
rm aaaRefEntitySyb
popd
The load_list is in the same directory as the load files. We can then call this script, usually from the parent directory, with the following:
% loadRef.script db1 db1 db1 welldirectory load_list > ref.out &where we have redirected the output to the file ref.out.
psql is a useful implementation for testing the load of the database. It can be used to access using the Level Two POSC sql calls. These calls are very similar to standard SQL, with extensions to handle the aggregates, subtypes, and other additions to standard relational database SQL.
psql is called as follows:
% $POSC_BIN/psql username password facilityIn our example this would be
% $POSC_BIN/psql db1 db1 db1Note that psql is running in interactive mode in this example. This is different from EntityLoader and refLoadLevelOne, which run in batch mode. However, psql can also be run in batch mode, by invoking it with a file that has the psql commands:
% $POSC_BIN/psql username password facility -i commandfilenamewhere commandfilename contains the psql commands.
It should be noted that all the psql commands are directed to the logical data model. If one wishes to interrogate the relational tables directly, he can use the vendor's sql access program (such as sqlplus, for Oracle). This is not recommended in general, but it may be appropriate in specific cases.
Examples of psql commands can be seen in the various Example Documents in this Specification. Click on the Examples button, and you will find psql commands interspersed with the text.
In my case, I use psql after loads to randomly test the database for properly loaded data. Although this is not extensive, it does give an indication of a problem load.
See Chapter 9 of the DAE Specification for details on the Level Two language.
This page still under construction.
See the coming attractions area for information on downloading updates to this section
[Return to Getting Started Introduction]