IBM Support

Temporary Addresses

Troubleshooting


Problem

This document discusses why the percentage of temporary addresses is increasing and what it means.

Resolving The Problem

The WRKSYSSTS command screen shows a value representing the Percent of Temporary Addresses Used as "% temp addresses" (see below):
 
Work with System Status                    SystemA
                                                                07/15/04  10:00:19
    % CPU used . . . . . . . :         .3    Auxiliary storage:                  
    Elapsed time . . . . . . :   00:00:01      System ASP . . . . . . :    740.8 G
    Jobs in system . . . . . :       6593      % system ASP used  . . :    36.9638
    % perm addresses . . . . :       .050      Total  . . . . . . . . :    755.9 G
>>  % temp addresses . . . . :      2.674 <<   Current unprotect used :     3038 M
                                               Maximum unprotect  . . :     3154 M
                                                                                 
    Type changes (if allowed), press Enter.                                      
                                                                                 
    System    Pool    Reserved    Max   -----DB-----  ---Non-DB---                
     Pool   Size (M)  Size (M)  Active  Fault  Pages  Fault  Pages                
       1     2211.83    685.79   +++++     .0     .0     .0     .0                
       2    14008.34      1.03     288     .0     .0     .0     .0                
       3       92.15       .00      43     .0     .0     .0     .0                
       4     1935.34       .00      50     .0     .0    3.5    3.5                
       5      184.31       .00      30     .0     .0     .0     .0                
                                                                            Bottom

Each time a temporary object is created, it uses a unique temporary address. The system has a very large but finite number of addresses available. Percent of temporary addresses indicates the percentage of those addresses used.

Many systems typically have a low percentage of temporary addresses used. However, rapid use of temporary addresses can occur and is typically a sign of application(s) creating temporary objects at an abnormally high rate. Programs that use heap space can use an address for each 16MB of heap in the same thread. Each thread or activation group uses a new address. Query can use temporary addresses for internal processing of joins and sorts. Some API calls can create temporary space that would use one or more temporary address. The best course of action to reduce the number of temporary addresses used is to change the application that is using them. Perhaps the application can be rewritten to have one job or one set of jobs handle multiple requests rather than starting a new job for each request. Or, perhaps the application can re-use the same temporary space by clearing and loading it with new data rather than deleting and creating new ones.

Refer to the following document for additional information regarding this: http://www-01.ibm.com/support/docview.wss?uid=nas8N1019798

Message CPI0997 (CPI0997) is issued when nearly all available machine addresses used. The text indicates the following:

Message . . . . : Nearly all available machine addresses used.            

Cause . . . . . : Nearly all available machine addresses have been used for reason &1. If the percentage of addresses used reaches 100 percent, the system will end abnormally. See reason &1 shown below:                    
1 - At least &2 percent of the maximum possible addresses for permanent objects have been used.
2 - At least &3 percent of the maximum possible addresses for temporary objects have been used.
           
Recovery  . . . :   See reason &1 shown below:                              
1 - Contact your service representative.                                
2 - Schedule an IPL to allow the system to reset the temporary addresses.  The reset of the temporary addresses will have minimal impact on the scheduled IPL.

Notes:
1. The CPI0997 message is issued when the system reaches 90% temporary addresses used.
2. Temporary and permanent storage each have 2** 38 addresses available (2 to the 38th power is 274,877,906,944).
In V7R4 and later releases temporary addresses are reset every IPL.

In V5R3 through V7R3, an IPL resets the temporary addresses if the percentage used is above 85 percent. The system must be IPLed before reaching 100% or it will crash and require an IPL to reset the percentage. Note: For systems at releases V5R2 and earlier, when the percentage of temporary addresses reaches 100 percent, a scratch installation is required.

In IBM i releases V7R1 through V7R3, there is an advanced analysis macro (SMSETTEMPSIDWRAP) available in SST that can be used to specify when to reset the temporary address space. It can be set between 30% and 95%. This support is also available with the following PTFs at V5R4M5 - V6R1M1:

R545 MF49771 1137
R610 MF49775 1102
R611 MF49781 1102

Note: The following HIPER PTFs should be applied prior to (or with) the IPL that you plan to do the temporary storage address reset:

APAR MA39285
R540 MF49652 0292
R545 MF49653 0292
R610 MF49633 0215
R611 MF49641 0215

APAR MA39284
R540 MF49903 0292
R545 MF49904 0292
R610 MF50118 0215
R611 MF50049 0215

APAR MA39188
R540 MF49679 0292
R545 MF49680 0292
R610 MF49617 0215
R611 MF49639 0215

To help locate what is causing rapid temporary address growth:
Use WRKSYSACT, press F11 until storage allocated is shown. Then use F19 to auto refresh and observe jobs that are allocating storage. Sorting by amount of storage being allocated may give hints as to the job(s) or application(s) causing the problem.

Alternatively, turn on object auditing and query the audit journal receivers for objects that were created. This could also assist in identifying job(s) or application(s) causing all the temporary objects to be created. See the Information Center for information on Setting up Security Auditing and Using the security audit journal.

To use the SMSETTEMPSIDWRAP macro, perform the following (Note: You will need to be on 7.1 or install the appropriate PTF above prior to running the following steps):
1. From the operating system command line, type STRSST and press the Enter key.
2. Sign in with a service tool profile and password that has authority to Display/Alter/Dump in SST.
3. Select Option 1 - Start a service tool, and press the Enter key.
4. Select Option 4 - Display/Alter/Dump, and press the Enter key.
5. Select Option 1 - Display/Alter storage, and press the Enter key.
6. Select Option 2 - Licensed Internal Code (LIC) data, and press the Enter key.
7. Select Option 14 - Advanced analysis, and press the Enter key.
8. On the Select Advanced Analysis Command screen, there is a list of available advanced analysis macros (under the Command column). Because SMSETTEMPSIDWRAP is not listed, type 1 (Select) next to the top blank line under the Command column. In the blank line, type SMSETTEMPSIDWRAP, and press the Enter key.

Note: SMSETTEMPSIDWRAP is "semi-permanent". It survives IPL and reset, but it won't survive across installs (and has the potential of not surviving when applying PTFs). 
9. In the Options field, enter a number between 30-95 to specify the new percentage, and press the Enter key.

Notes:
1. The SMGETTEMPSIDWRAP macro can be used to retrieve the current setting.
2. smsettempsidwrap = Set Temporary Address Threshold
3. smgettempsidwrap = Get Temporary Address Threshold
4. The reset will occur on the IPL after the percent is reached. The IPL does not take more time to do a reset. There is no way to reset/regain/lower the amount of temporary addresses used by doing something covert within System Service Tools.
5. Upon upgrading operating system releases (in other words, V5R4M0 to V6R1M0), the number of temporary addresses will persist through the upgrade.
6. Performance Explorer may be needed to analyze temporary address growth and may require a consulting agreement accordingly.
7. The 90% threshold at which the CPI0997 message will be issued cannot be changed.
8. The additional time for IPL after setting this macro is negligible.

Internal Use Only

SLIC - VERTICAL MICROCODE (9400DG300)

[{"Product":{"code":"SGYQGH","label":"IBM i"},"Business Unit":{"code":"BU009","label":"Systems - Server"},"Component":"Internals","Platform":[{"code":"PF012","label":"IBM i"}],"Version":"5.3.0;5.3.5;5.4.0;5.4.5;6.1.0;6.1.1;7.1.0","Edition":""},{"Product":{"code":"SSC3X7","label":"IBM i 6.1"},"Business Unit":{"code":"BU009","label":"Systems - Server"},"Component":" ","Platform":[{"code":"","label":null}],"Version":"","Edition":""},{"Product":{"code":"SSC52E","label":"IBM i 7.1"},"Business Unit":{"code":"BU009","label":"Systems - Server"},"Component":" ","Platform":[{"code":"","label":null}],"Version":"","Edition":""}]

Historical Number

347970291

Document Information

Modified date:
18 October 2019

UID

nas8N1015972