To create, update, or delete data from a DB2 database, use SQL statements. SQL is a standardized language that allows you to define and manipulate data in a relational database. There are two ways to run SQL statements:
VisualAge Smalltalk Server provides methods that enable you to perform the following SQL statements from CICS, IMS, or OS/390:
Alternatively, you can use nonvisual parts for SQL statements. You use CLI or static SQL statements. For transactional environments such as CICS or IMS, you must use precompiled SQL statements.
The application AbtBaseStaticIbmDatabaseApp is required in both the development and runtime environments to write SQL statements that will run under DB2 in OS/390:
The following applications are optional:
See Developing your DB2 application on the workstation for a description of the steps needed to test your application on the workstation. When your Smalltalk application is completely tested and ready to run in the target environment, follow the steps described in Deploying your application on the target environment.
The following steps describe how to develop a DB2 Smalltalk application on the workstation. This process assumes that you will be precompiling your DB2 for workstation package specs from the development image. You can also choose to precompile your DB2 for workstation SQL packages from a passive image. To precompile for DB2 for workstation from a passive image, you need to version and release your classes in the development image, make a passive image for the target environment, load your application into the passive image, and precompile in the passive image.
See DB2 SQL Reference and DB2 Application Programming and SQL Guide to learn how to write SQL statements. See Distributed Relational Database Architecture Formal Register of Existing Differences in SQL for a detailed description of the differences between SQL statements on different platforms.
If you are accessing DB2 on OS/390, use high-level qualifiers.
A Smalltalk DB2 application is designed and coded like any other Smalltalk application. The only additional work lies in the coding of a query spec for each static SQL statement.
Query specs are stored in access sets but are grouped together into package specs, each of which will become a DBRM on OS/390 or a bind file on the workstation. The DBRMs for an application are bound together (using DB2 Bind) into a plan. You can also bind DBRMs into intermediate packages and then into DB2 plans.
Each package spec is stored in a subclass of AbtDatabaseAccessSet. The package spec can be precompiled or its access set can be precompiled. When an access set is precompiled, all of the access set's package specs are precompiled. The TrailBlazer browser provides a user interface for the creation and maintenance of query specs, package specs, and access sets.
See Writing SQL statements using Smalltalk for more information.
Note: | You can precompile for DB2 for workstation from a workstation image only. That is, to precompile for DB2 for workstation, you must be either in the development image or in a passive image. |
To use static SQL statements, you must precompile your SQL packages in Smalltalk before your application can be tested on the workstation. The precompile ensures that the SQL packages are in sync with the plan residing on DB2 for workstation. The precompile for DB2 for workstation does the following:
To precompile your access sets for the workstation using TrailBlazer, do the following:
Note that when precompiling for DB2, a trailing period in a host variable (which is an invalid host variable) causes a walkback.
When you have precompiled your SQL packages, you can test your program interactively against DB2 for workstation by running it from the Transcript or a workspace.
Once your program runs correctly on DB2 for workstation, you are ready to deploy it to the target environment.
You must release all classes to your application; otherwise, when you load your application into the passive image, the classes will not be loaded or will not contain the latest updates. To version and release all classes to your application in the development image, select Manage Applications from the Tools menu; then--
If you need to translate any strings in your application, you must separate the strings. To do so, follow instructions on National Language Support (NLS) in the VisualAge Smalltalk User's Guide and generate one or more message and pool repository (.mpr) files. This means you implement abtExternalizedStringBuildingInfo, loaded, and removing methods in your application class, then use menu choices available from the NLS choice of the Transcript's Tools menu.
Because your application will use one or more .mpr files, when packaging from an XD passive image, you will need to go to the Policies tab and select the Dumper policy type and the Make Message Catalogs Resident option. The Policies tab is available during the Modify Instructions step.
If you do not already have a passive image, add one by following these steps:
This example uses the choice MVS.
When you switch to the passive image--whether you have just created it
or it has been previously created--the XD Transcript window
opens. The XD Transcript is to this passive image what the System
Transcript is to the development image. The XD Transcript looks like
this:
To load your application into the passive image, select Manage Applications from the Tools menu of the XD Transcript window; then--
Note: | You can precompile for DB2 for MVS (or OS/390) from an OS/390 image only. That is, to precompile for DB2 for OS/390, you must be in a passive image whose image type supports OS/390. |
Precompiling for DB2 for OS/390 differs from precompiling for DB2 for workstation. Although your SQL packages have been precompiled if you have tested them on the workstation, they need to be precompiled once again for use with DB2 for OS/390.
The precompiler updates information held by the existing instances of AbtQuerySpec and produces a DBRM for each SQL package. DB2 Application Programming and SQL Guide describes a set of precompiler options supported for PL/I, COBOL, and other languages. Where appropriate, options of the same name are also supported by the precompile behavior of AbtSqlPackage.
The following precompile options are used and cannot be changed for VisualAge Smalltalk Server precompiles:
The following precompile options can be specified independently for each SQL package. Public class methods on AbtSqlPackage allow you to set and query these options:
The following precompile options do not apply to VisualAge Smalltalk Server:
To precompile your SQL packages for all target environments, do the following in the passive image:
The precompile will cause class methods to be regenerated for query specs and methods with SQL code to be precompiled. This requires that your application is an open edition and that you are the developer of the access set class.
Also, the precompile action generates a cross reference report showing the SQL generated by the query specs. The SQL is listed by generated statement number (the statement number referenced by many BIND error messages). The report can be seen by browsing the file named package.xrf, where package is the name of the DBRM or bind file created by the precompile.
The DBRM created as part of the precompile must be uploaded as binary to OS/390 and placed in the DBRM library. You can then use a DB2 Bind to create a Plan from the DBRM.
Notes:
When you package an image to run on OS/390, you can package the image as a single module or as a dependent module. A dependent module uses the classes of a shared base module to run. See the VisualAge Smalltalk Server Guide for the steps to package your application image.
If your application uses .mpr files, you will need to select the Dumper policy type and the Make Message Catalogs Resident option during the Modify Instructions step. See Step 2: Separating strings in your application.
If you are writing an application that will work with CICS, see VisualAge Smalltalk Server Guide for more information about how to run the packaged image. If you are running in CICS/ESA 3.3 and you receive the CICS abend ASRA, ensure that the taskdataloc is specified as BELOW in the transaction definition of your program. There is a description of the proper definition for a transaction in the VisualAge Smalltalk Server Guide.
If you are writing an application that will work with IMS/ESA, see the VisualAge Smalltalk Server Guide for more information about how to run the packaged image.
If you are writing an application that will work with OS/390, see the VisualAge Smalltalk Server Guide for more information about how to run the packaged image.