SQL Memory Guard

The SQL Memory Guard function, used for SQL memory monitoring, is not required for normal production processing, but if you are experiencing an unusual SQL memory problem that is affecting the availability of the Multi-User Facility, the SQL Memory Guard function can be invoked. You should in most cases, however, only use the SQL Memory Guard function if CA Support requests you to do so.

SQL Memory Guard monitors memory requests made by SQL and looks for possible misuse and contention on each memory address as well as the entire memory pool. If you invoke the SQL Memory Guard function, you may notice a slight increase in CPU usage, because the memory guard monitors and records every SQL memory request.

When the invoked SQL Memory Guard encounters a possible memory problem, it aborts the invalid memory request before any damage is done to the memory pool. The request that generated the invalid memory request then receives an SQL return code of -999, thus protecting the MF from a possible destructive memory failure.

The following error message is produced when problems are detected. Additional debugging information is dumped to the Statistics and Diagnostics Area (PXX).

-999

INTERNAL ERROR (file-name LINE xyz): command CONFLICT - addr1(task1)/addr2(task2)

If such a -999 message is received, contact CA Support and give them the following information from the message text:

command

Is the service requested by task1, such as FREEMEM or DELPOOL.

addr1

Is the address of the illegal call to memory services (the R14), relative to the entry point of load module DBSRPPR.

task1

Is the task (DBRW) number of the outlaw requestor of memory services.

addr2

Is the relative address of the call for the prior conflicting request (valid regardless of DBRW contents).

task2

Is the task (DBRW) number of the caller for the prior conflicting request on either the memory address or the memory pool in question. Note that this task may be executing an unrelated job by this point in time. This does not, however, necessarily prevent the SQL Memory Guard from finding the problem.

The above information helps CA Support resolve memory-related problems more quickly. In addition, as always when you contact CA Support to report any SQL error code, provide a Statistics and Diagnostics Area (PXX) report with DUMPS=FULL.

Following is an example of an actual -999 message:

-999: INTERNAL ERROR (MEMSERV LINE 1396): FREEMEM CONFLICT - FD14(1)/FCBE(1)

Activating the SQL Memory Guard

The features of the SQL Memory Guard can be activated or deactivated, though normally only at the direction of CA Support, by executing the following commands (for more information on DIAGOPTION, see the CA Datacom/DB Database and System Administration Guide):

DIAGOPTION 2,2,ON: Causes automatic debugging and abend prevention to begin either immediately or as soon as the trace table is allocated.
DIAGOPTION 2,2,OFF: Causes automatic debugging and abend prevention to stop. If the trace table has been allocated, requests are still logged.
DIAGOPTION 2,4,ON: Causes the memory trace table to be allocated (approximately 32K) and activated (meaning memory requests are logged) when the next new RUN UNIT starts its first SQL request. To receive automatic debugging and abend prevention, also execute DIAGOPTION 2,2,ON as described in the following related section.
DIAGOPTION 2,4,OFF: Causes the memory trace table to be freed (the memory manager makes the storage available for use by SQL only) when the next new RUN UNIT starts its first SQL request.