Maintaining ALLBASE/SQL Programs

• Updating application programs.

• Changing program-related authorizations.

• Obsoleting application programs.

Updating Application Programs

Minor modifications to programs in use can often be made right on the production machine and production DBEnvironment, during hours in which the production DBEnvironment use is minimal. Major program modifications, because they are more time-consuming, are usually made on a development machine and development DBEnvironment.

In either case, the OWNER of the program's module or a DBA preprocesses the revised program and replaces the old module with a new one. Existing RUN authorities can be either preserved or revoked. Dropping old modules and preserving or revoking RUN authorities can be done either by using the DROP MODULE command in ISQL or when you invoke the preprocessor.

The PRESERVE option of the DROP MODULE command retains any existing RUN authorities for the module when it is deleted from the system catalog as in the following example:

   isql=> DROP MODULE myprog PRESERVE;

To delete a module and any existing RUN authorities in ISQL, simply omit the PRESERVE option.

You can also drop a module at preprocessing time:

   $ psqlpas somedbe -m modulename -i mysource.sql -d

The -d command tells the preprocessor to drop any existing module named modulename; if you omit the -d command, a new module is created only if a module named modulename does not exist. This invocation line drops any existing module named modulename, but retains any related RUN authorities. To revoke the RUN authorities, you would specify the -r (revoke) option in the command string as follows:

   $ psqlpas somedbe -m modulename -i mysource.sql -d -r

The DROP MODULE command is also useful in conjunction with revised programs whose modules must be installed in a DBEnvironment different from that on which preprocessing occurred. Before using the INSTALL command to store the new module, you drop the existing module using the DROP MODULE command, preserving or dropping related RUN authorization as required.

Changing Program-Related Authorization

Once a program is in production use, you may need to grant and revoke RUN and CONNECT authority as program users revoking CONNECT authority in the following example requires DBA authorization:

   isql=> REVOKE CONNECT FROM olduser;

Revoking RUN authority as shown below requires either module OWNER or DBA authority:

   isql=> REVOKE RUN ON pgmr1.somepgm FROM olduser;

Obsoleting Programs

When an application program becomes obsolete, you use the DROP MODULE command to both remove the module from any DBEnvironment where it is stored and revoke any related RUN authorities:

   isql=> DROP MODULE myprog; 

Related RUN authorities are automatically revoked when you do not use the PRESERVE option of this command.

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 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-5 “Use of DBCore Shared Memory in a DBEnvironment”.

Figure 1-5 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 "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 application accessing the DBEnvironment. IPC shared memory is mapped to the user's process.

	NOTE: 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

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