Title: SQL Packages and AS/400

Abstract: Understanding, viewing and deleting SQL Packages on AS400.

Product OneWorld® Suite Technical Release ALL Document ID OTI-99-0072 Date Created 04/23/2001 Date Reviewed 04/23/2001 Date Revised 04/23/2001

SQL packages are a feature of the OS/400 operating system which store information about dynamic SQL queries on the AS/400. An SQL package object contains information needed by SQL to perform a request of a program on a remote system. So, the next time the statement is executed, the AS/400's Query Optimizer already knows the best method to use to execute the requested query. In addition, if the system detects significant changes in the database, it will re-optimize the query and save the updated query information.

There is an SQL package for each application on the AS400. The package name is the first 7 characters of the application plus a 3 character hash. For example, typically OneWorld® will generate a package called OEXPLORFJA. This package is a file that is stored in a library on the AS/400. (The default library in which the packages are stored is QGPL.)

Because SQL packages are a shared resource, the information built when a statement is prepared will be available to all the users of the package. This saves processing time, especially in an environment when many users are using the same or similar statements. By comparison, dynamic SQL requires that each user go through the prepare processing for a particular statement, and this must be done every time the user starts the application.

Since SQL packages are permanent, the information they contain is also saved across job initiation/termination AND across IPL's. (Therefore, an IPL will NOT delete any SQL package.)

The following command can be used to view all of the *SQLPKGs on an AS/400:

WRKOBJ OBJ (*ALL/*ALL) OBJTYP (* SQLPKG)

The AS/400 screen displays the following information: To view the properties of an individual SQL Package, take option 8 to "Display Description".

Prior to V4R3, SQL packages were limited to 16MB. Furthermore, ODBC packages had additional restrictions on the number of statements allowed. In V4R3, the maximum size of a package was increased to 16,384 statements or approximately 500MB, whichever comes first. In V4R3, ODBC package size limits have also been removed.

Note that the SQL package must be created on V4R3 to be capable of this new larger size, they are not converted automatically. If you are upgrading to V4R3, extended dynamic SQL packages should be deleted if you wish to take advantage of the larger size. In V4R2, customers have seen data access problems related to the 16meg limit being reached on the *SQLPKG or in what is being described as "corruption" of the package. One of the main symptoms of this record locks against the Next Numbers table and other data access errors.

When problems occur that are perceived to be caused by *SQLQKG objects, you can delete all of *SQLPKGs created by OneWorld®. In order to ensure that all *SQLPKG object can be removed all must be signed out of OneWorld® prior to deleting the *SQLPKGs. If users are still logged into OneWorld® they will have a lock on some of the *SQLPKG objects thus preventing the deletion of these objects.

In V4R3, there is considerably less need to delete SQL packages. It is still reasonable to delete them when you've made substantial changes to the database (which could necessitate access plan rebuilds). Because extended dynamic SQL packages are recreated when the application is run, there is little harm in deleting SQL packages.

IMPORTANT: DO NOT delete any *SQLPKG which starts with a Q; (i.e. - QZDAPKG, QSQLPKG2, QSQXDPKG). These are IBM-created *SQLPKG objects critical to the performance of the OS/400 operating system.

Also, the OS/400 operating system will NOT let you delete those SQL packages beginning with and underscore "_", (i.e. _CETUPFBA and _CSETUPFJA).

To delete individual SQL Packages, use the WRKOBJ OBJ(*ALL/*ALL) OBJTYP(*SQLPKG) command. Place a '4' beside each *SQLPKG you wish to delete.

Clients who have experienced repeated problems with *SQLPKGs have scheduled periodic jobs to automatically delete them. A separate Job Scheduler entry must be created for each SQL package to be deleted. The following command can be used by the AS/400 Security Officer (QSECOFR) to add an entry to the AS/400 Job Scheduler.

ADDJOBSCDE

The following is an example of a Job Schedule entry to delete the OEXPLORFBA *SQLPKG at 12:00:01 A.M. each morning: To verify that the Scheduled Job is created, use the command: WRKJOBSCDE.

Change the server INI to force deletion of SQLPKGs.

This change will not affect what the client has set in their ODBC settings, i.e. Extended Dynamic Support. The INI setting on the server will only affect applications (UBE or other OneWorld® Kernel jobs) that are running on the server.

Forcing the SQLPKGs to be deleted after the UBE has completed requires an addition to the INI on the AS/400. Under the section [DB System Settings] of the INI add the following line:

SQL Package Library = 1.

Adding this line will force the SQLPKGs to generate in the QTEMP library. The QTEMP library contents are deleted after the UBE finishes processing. Putting a '0' in place of the '1' changes the destination library for the SQL packages to QGPL.

NOTE: Deleting the SQL packages immediately after creation or running of the UBE affects performance because a new package will have to be created each time a UBE is run.