HPlogo ALLBASE/SQL C Application Programming Guide: HP 3000 MPE/iX Computer Systems > Chapter 1 Getting Started with ALLBASE/SQL Programming in C

Moving into the Production Phase

» 

Technical documentation

Complete book in PDF
» Feedback

 » Table of Contents

 » Index

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

[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.