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 Multi-User Facility 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 (RWTSA) number of the outlaw requestor of memory services.
addr2: Is the relative address of the call for the prior conflicting request (valid regardless of RWTSA contents).
task2: Is the task (RWTSA) 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)