This chapter provides information for managing ObjectStore on OS/2 systems. For complete information, you should consult the first six chapters of this book along with this chapter.
os_database::open("d:\\carter\\myfiledb")
os_database::open("\\\\servername\\sharename\\myfiledb")In C and C++, you must escape the back slash (\) with another back slash.
You can specify a relative pathname.
Server names
You can specify a Server name when you open or create a database. The Server name identifies the Server host on which the database is located. For example:
Server on a UNIX host: | elvis:/usr/barbar/employees |
Server on an OS/2 host: | elvis:D:\usr\barbar\employees |
This specifies a database, employees, in the directory \usr\barbar on the host elvis.
Setting Server Parameters
Each Server parameter that you can specify is described in Chapter 2, Server Parameters.
OSTORE.INI
The ObjectStore Server stores its parameters in the OSTORE.INI file. This file is in the standard format for OS/2 parameters files. The ObjectStore installation and setup utilities create the OSTORE.INI file and store it, by default, in the \OS2 directory on the boot drive. OSSETUP
All Server parameters have default values. Object Design recommends that you use the default value for each parameter, which requires no action on your part. However, you can use the OSSETUP utility to modify parameters in the OSTORE.INI file. See your installation guide for information. Using -p
If you do not want to use the Server parameters in the OSTORE.INI file, you can create a standard OS/2 parameters file that contains the parameter values you want. When you start the Server with the osserver utility, you can specify this Server parameters file with the -p option. OS2.INI
Alternatively, you can remove the OSTORE.INI file and place Server parameters in the OS/2 user profiles, OS2.INI and OS2SYS.INI.
OS2SYS.INI Search order
ObjectStore uses the following search order to find parameter settings:
After you modify a Server parameter, you must shut down and restart the Server for the parameter to take effect.
After starting, the Server displays the message Server started to let you know that it is ready to accept requests from clients on the network.
Use -i and -I with caution
Be sure to move all data out of the log before you initialize it. See ossvrchkpt: Moving Data Out of the Server Transaction Log. Be sure to back up all data in the rawfs before you initialize it. See osbackup: Backing Up Databases.
When you initialize the transaction log, anything in the log is lost. The Server resizes the log to the values specified by the Log Data Segment Initial Size and Log Record Segment Initial Size Server parameters. When the log is in the rawfs, this frees space for use by other files. When the log is in the native file system, this reallocates space dedicated to the transaction log. The size of the log does not change.
Initializing when you have a rawfs
If you have a rawfs, then specifying the -i or -I option with osserver initializes the rawfs and the transaction log. When you specify -i, ObjectStore responds with
The entire ObjectStore file system on this host is about to be initialized, thus destroying any data currently in it. Unless you have a backup of the ObjectStore file system, it will be impossible to recover the old contents once the initialization is started. Are you sure that you want to reinitialize the ObjectStore file system?When you specify -I, this message does not appear.
You have asked for initialization which will create a new transaction log, deleting any old log that might exist, thus destroying any recovery data in the old log. This might leave some file databases in a broken state. Are you sure that you want to create a new log?When you specify -I, this message does not appear.
START /N OSCMGR4 0
This book refers to ObjectStore utilities by their full names.
%OS_ROOTDIR%\BIN\OSSERVER.EXE
Server errors | OSSERVER.TXT |
Cache Manager errors | OSCMGR4.TXT |
If the file does not already exist, ObjectStore creates it. If the file does exist, ObjectStore appends to it.
Search order
Creating a rawfs
To create the rawfs or add partitions to an existing rawfs, use the OSSETUP utility. When you create the rawfs, you specify a disk drive letter and a file name. After you create the rawfs, you add Server partitions. See your installation guide for details. Using OSSETUP to Add File Partitions
Be sure to shut down the Server before you run OSSETUP. You cannot run OSSETUP while the Server is running. When you exit from OSSETUP, it prompts you to indicate whether or not you want to restart the Server. If you indicate No, you must run osserver to start the Server. Syntax
PartitionN FILE pathname {expandable | nonexpandable}
Partition0 FILE c:\mypart0 expandable Partition1 FILE d:\mypart1 expandable Partition2 FILE e:\bigpart99 expandable
Partition0: FILE c:\usr1\one expandable Partition1: FILE d:\usr2\two expandable Partition2: FILE e:\usr3\three nonexpandable
SET OS_TMPDIR=c:\temp
ossvrsht -f hostname
osserver -F -v -d 10
You do not need to redirect the output. ObjectStore places the output in the oss.out and osserver.txt files in the c:\temp directory, using the OS_TMPDIR environment variable.
The osserver options have the following meanings:
oscmgr4 0 50 0 1 1You do not need to redirect the output. ObjectStore uses OS_TMPDIR to send the output to the osc4.out file. The oscmgr4 options have the following meanings:
host:drive:\pathHowever, the IBM NFS implementation for OS/2 does not allow locking a file across an NFS volume. Doing so is not safe for databases that are remote to the ObjectStore Server. But it is quite safe if the database is physically located on the ObjectStore Server.
For example, a client can access a database by means of NFS. The client NFS mounts the drive from the ObjectStore Server so that it appears as a local drive on the client. Now the client can reference the database as, for example,
g:\my\path\to\databaseObjectStore translates that path to something the ObjectStore Server can understand, and since it is physically on the ObjectStore Server, it can locate the Server-local file.
There is another scenario that is not safe. In this case, the database is not physically resident on the ObjectStore Server. By default, ObjectStore does not allow this. You can, however, set up a locator file to allow it. See Chapter 5, Using Locator Files to Set Up Server-Remote Databases. In this unsafe scenario, the database is physically resident on a third machine, the NFS server, which might be the client machine. The ObjectStore Server needs to lock the database by means of NFS. On OS/2, this is not possible. You cannot lock across NFS volumes, which makes it difficult to guarantee the integrity of the database.
Updated: 03/26/98 20:46:44