HP 3000 Manuals

ALLBASE/SQL C Application Programming Guide

Moving into the Production Phase 

At the beginning of the production phase, you need to:

   *   Install the program module in the production DBEnvironment.
   *   Assign the appropriate security structure on the production
       system.

Installing Program Modules 

Installation involves using the ISQL INSTALL command to store a module
created in one DBEnvironment into a different DBEnvironment on the same
or a different system.  When the preprocessor stores a module in a
DBEnvironment, it also creates a file containing a copy of the module,
which can be installed into another DBEnvironment.  The installable
module file in the following example is SQLMOD. The module also has an
internal, SQL name, in this case PGMR1@ACCOUNT.CEX8, which is saved as
part of the module at preprocessing time.  Use the INSTALL command in
ISQL as shown in this example:

     isql=> CONNECT TO 'SOMEDBE.SOMEGRP.SOMEACCT'; 
     isql=> INSTALL SQLMOD; 

     Name of module in this file:  PGMR1@ACCOUNT.CEX8
     Number of sections installed:  3
     COMMIT WORK to save to DBEnvironment.

     isql=> COMMIT WORK; 

This process is illustrated in Figure 1-5.


          Figure 1-5.  Moving an Application to a Production System 

ISQL copies the module from the installable module file named SQLMOD into
a DBEnvironment named SOMEDBE.SOMEGRP.SOMEACCT. During installation,
ALLBASE/SQL marks each section in the module valid or invalid, depending
on the current objects and authorities in SOMEDBE.SOMEGRP.SOMEACCT.

To use the INSTALL command, you need to be able to start a DBE session in
the DBEnvironment that will contain the new module.  If you are replacing
a module with a new one of the same name, make sure no other users are
accessing the module.  To avoid problems, install modules while connected
to the DBEnvironment in single-user mode.  Before installing, you should
DROP any existing module on the production machine that has the same
name:

     isql=> DROP MODULE PGMR1@ACCOUNT.CEX8; 

Granting Module Owner Authorizations 

The original module owner is the DBEUserID of the person who preprocesses
the program or, if specified, the DBEUserID used with the OWNER option in
the preprocessor command line.  At run time, embedded SQL commands are
executed only if the original module owner has the authority to execute
them.  Therefore, you need to grant required authority to a user in the
production DBEnvironment with the same name as the original module owner
in the development environment. 

If module PGMR1@ACCOUNT.CEX8 contains a SELECT command for table
PurchDB.Parts, the following grant would ensure valid owner authorization
in the development environment:

     isql=> GRANT SELECT ON PurchDB.Parts TO Pgmr1; 

Being the owner of the module, Pgmr1 could have assigned ownership of the
module to another owner at preprocessing time by using the -o option:

     : RUN PSQLC.PUB.SYS;INFO="SOMEDBE.SOMEGRP.SOMEACCT (MODULE (CEX8) OWNER (PurchMgrs)) 

In this case, ownership belongs to a group, PurchMgrs.  Only members of
the group or an individual with DBA authority can maintain this program,
and runtime authorization would be established as follows:

     isql=> GRANT SELECT ON PurchDB.Parts TO PurchMgrs; 


NOTE  Keep in mind that the original module owner's name is coded into
      the module itself.  Therefore, the original DBEUserId must exist on
      the production system and possess the appropriate CONNECT and
      object authorities.  As a rule, it is wise to assign ownership of
      modules to a group name which can be used on both development and
      production systems.  In this fashion, you can assign different
      membership to the group on the production system than you assigned
      on the development system.


Granting Program User Authorization 

In order to execute an ALLBASE/SQL program, you must have CONNECT
authority for any DBEnvironment accessed by the program.  You must also
have one of the following authorities in the DBEnvironment accessed by
the program:

   *   RUN.
   *   Module OWNER.
   *   DBA.

A DBA must grant the authority to start a DBE session.  In most cases,
application programs start a DBE session with the CONNECT command, so
CONNECT authorization is sufficient:

     isql=> CONNECT TO 'SOMEDBE.SOMEGRP.SOMEACCT'; 
     isql=> GRANT CONNECT TO USER@ACCOUNT; 
     isql=> COMMIT WORK; 

If you have module OWNER or DBA authority, you can grant RUN authority:

     isql=> CONNECT TO 'SOMEDBE.SOMEGRP.SOMEACCT'; 
     isql=> GRANT RUN ON SOMEPROG TO USER@ACCOUNT; 
     isql=> COMMIT WORK; 

Now USER.ACCOUNT can run program SOMEPROG:

           : HELLO USER.ACCOUNT 
           .
           .
           : RUN SOMEPROG 

Refer to the ALLBASE/SQL Reference Manual for complete information on the
GRANT command.

MPE/iX 5.0 Documentation