Programming Under the HP-UX Operating System

• Access to Directories.

• Pathname Conventions in Referencing Files.

• Use of Shared Memory.

• Use of Interprocess Communication.

• Native Language Support.

Access to Directories

It is best to create DBEnvironments in directories separate from the directory in which source files reside. For greatest security, the DBEnvironment should reside in a directory owned by user hpdb to which the programmer does not have write access. Program files should be kept in a separate directory to which the programmer has write access. Then you can code CONNECT statements like the following:

	   EXEC SQL CONNECT TO '../sampledb/PartsDBE';

where sampledb is the directory containing the DBEnvironment and the two periods (..) are the parent directory of both the program directory and the DBEnvironment directory. Following this procedure assures the safety of DBEnvironment files.

Pathname Conventions in Referencing Files

When you create a DBEnvironment, a DataBase Environment Configuration (DBECon) file having the name of the DBEnvironment is created. The absolute pathname of this DBECon file is stored in the DBECon file itself. In all subsequent references to files, you may use either an absolute pathname or a pathname relative to that of the DBECon file. Any file reference which does not begin with a slash (/) assumes a relative pathname.

For example, if a DBEnvironment was created with the following command:

	START DBE 'PartsDBE' NEW;

and the user was currently in the directory /users/dbsupport/sql, the pathname /users/dbsupport/sql would be stored in the DBECon file. If the user were subsequently to create a DBEFile with the command:

	CREATE DBEFILE Orders WITH PAGES=50, NAME='OrdersDF';

the actual pathname of the file OrdersDF would be relative to the pathname stored in the DBECon file and would be /users/dbsupport/sql/OrdersDF. If however, the user were to create a DBEFile with the command:

	CREATE DBEFILE Orders WITH PAGES=50, NAME='/users/shipping/OrdersDF';

the pathname stored in the DBECon file would be ignored while creating this file. The user would need to fully qualify this pathname each time this file is referenced.

Both absolute and relative pathnames are restricted to a maximum length of 127 bytes (including the filename, e.g., OrdersDF).

In addition, if the DBEnvironment you want the preprocessor to access resides in a directory other than your current working directory, you will have to qualify the pathname of that DBEnvironment.

For example, if the DBEnvironment you want the preprocessor to access resides in your sampledb subdirectory, you would invoke the preprocessor as follows:

   $ psqlc sampledb/SomeDBE -i SourceFileName -d

Use of Shared Memory

ALLBASE/SQL uses two types of shared memory, DBCore shared memory and inter-process communication (IPC) shared memory.

When you start a DBEnvironment with the START DBE command, a block of DBCORE shared memory is obtained for the current DBEnvironment session. Until the last user session ends, all users and programs accessing the DBEnvironment share this allocated memory, which includes:

The use of DBCore shared memory is illustrated in Figure 1-6 “Use of DBCore Shared Memory in a DBEnvironment”.

Figure 1-6 Use of DBCore Shared Memory in a DBEnvironment

Since these are shared resources, your program cannot manipulate their size directly. However, a DBA can alter them with the SQLUtil ALTDBE command. Refer to "Estimating Shared Memory Requirements" in the "Physical Design" chapter of the ALLBASE/SQL Database Administration Guide.

An IPC shared memory segment is allocated for each local access application accessing the DBEnvironment. IPC shared memory is mapped to the user's process.

Series 300 Shared Memory

	300/400: The following shared memory considerations apply only to Series 300 and 400 systems. Systems using SQL must be configured with a minimum shmmaxaddr of 13MB. The default shmmaxaddr is 16MB and is recommended. (See the HP-UX System Administrator Manual for information on shmmaxaddr, an operating system parameter.) ALLBASE/SQL application programmers using their own shared memory must consider the following: Do not map your shared memory between the 12MB to 16MB address space used by ALLBASE/SQL. It is recommended that you avoid mapping shared memory within 1MB of the top of the data segment (brk). CONNECT to your DBEnvironment prior to mapping in your own shared memory. This is to satisfy ALLBASE/SQL requirements for dynamic data storage.

Choosing an Interprocess Communication Option

ALLBASE/SQL offers two interprocess communication options. Fast ipc is the default and is available for the E.1 release. The previously existing interprocess communication method, signal ipc, remains a viable alternative depending on your application requirements.

Any applications developed with ALLBASE/SQL release E.1 will by default use fast ipc. Any existing applications developed on a prior release will by default use signal ipc unless they are relinked. Once an existing application has been relinked, fast ipc is in effect. You have the option of setting an environment variable to indicate which form of interprocess communication you wish to use.

The following sections describe each option, how to set the environment variable, and debugging considerations:

Using Fast IPC

Fast ipc offers the following features:

• Performance is improved for applications with many, simple ALLBASE/SQL statements because overhead is reduced in communicating a request between an application and ALLBASE/SQL. It is the complexity of the statement that determines whether or not improved performance results. The size of a transaction or the size of a query result do not affect performance in regard to fast ipc.

• Only signal 18 (SIGCLD) is used by ALLBASE/SQL when fast ipc is enabled. Therefore, if your application uses signals, you should avoid using signal 18.

	NOTE: If you want to use fast ipc and trap signals, note that once a signal has been trapped and processed, your code must return from the signal handling routine to the trap point before further processing continues.

Setting the HPSQLfast_ipc Environment Variable

The following example illustrates how to set the HPSQLfast_ipc environment variable.

Suppose you already have applications that must use signals and which were written prior to this release. Signal ipc is the default unless you relink your applications. In this case, you reset the signal ipc option by setting the environment variable, HPSQLfast_ipc to n or N.

For the Bourne shell or Korn shell:

HPSQLfast_ipc=n; export HPSQLfast_ipc

For the C shell:

setenv HPSQLfast_ipc n

Perhaps your existing applications do not use signals, and you decide to take advantage of the new option. To reset to the fast ipc option you must relink your applications.

	NOTE: The appropriate HPSQLfast_ipc environment variable must be in effect at run time.

Setting Signal Handling for Debugging

Be aware that when you enter a debugging session, you must set the signal handling table for the xdb debugger, for example:

z 18 rs

	300/400: Series 300 and 400 systems use the cdb debugger with a different format, as follows: 18 z rs

Native Language Support

ALLBASE/SQL lets you manipulate databases in a wide variety of native languages in addition to the default language, known as n-computer. You can use either 8-bit or 16-bit character data, as appropriate for the language you select. In addition, you can always include ASCII data in any database, since ASCII is a subset of each supported character set. The collating sequence for sorting and comparisons is that of the native language selected. A list of supported languages is in /usr/lib/nls/config.

You can use native language characters in a wide variety of places, including:

If your system has the proper message files installed, ALLBASE/SQL displays prompts, messages and banners in the language you select, and it displays dates and time according to local customs. In addition, ISQL accepts responses to its prompts in the native language selected. However, regardless of the native language used, the syntax of ISQL and SQL commands--including punctuation--remains in ASCII.

In order to use a native language other than the default, you must do the following:

You can use native language characters in the DBEnvironment name. If you do so, you must set the LANG environment variable to the same language before you can connect to the DBEnvironment. To avoid confusion, it is advised that you always use the same language for the DBEnvironment that you use in the LANG variable.

Resetting the LANG variable while you are connected to a DBEnvironment has no effect on the current DBE session.