Virtual storage requirements for Db2 address spaces

Db2 uses several types of private address spaces, and each type requires storage.

Tip:

You might notice that the sample jobs sometimes use a region size of 0 KB. This region size is meant to simplify the installation process in those particular cases. In the following recommendations, the region sizes are based on average use under normal circumstances on typical systems. Your requirements might be quite different.

Database services address space (ssnmDBM1)
The database services address space is responsible for accessing relational databases that are controlled by Db2 for z/OS and provides most database-related services. The input and output to database resources is performed on behalf of SQL application programs in this address space. It is the largest Db2 address space. It uses storage above the 2 GB bar. The default start up procedure is DSN1DBM1. First, plan for a minimum of 90 MB in this address space, with 2 MB below the 16 MB line.

Most modules reside in the 31-bit extended private area. Storage usage below the 16-MB line is typically less than 2 MB.

System services address space (ssnmMSTR)
The system services address space starts and stops Db2, and controls local access to Db2 for z/OS, and performs various system-related functions. It needs less space than the database services address space (ssnmDBM1). Specify 0 KB for the system services address space. The default start up procedure is DSN1MSTR.
Distributed data facility (DDF) services address space (ssnmDIST)
The distributed data facility address space supports network communications with other remote systems and execution of database access requests on behalf of remote users. Use the default region size of 0 KB. This address space is started as part of DDF initialization. The start-up procedure is DSN1DIST.
Internal resource lock manager (IRLM) address space (irlmproc)
Db2 uses the IRLM address space to control access to database resources and locking. When row locking is used, the number of locks that Db2 acquires might increase, which might in turn increase the amount of storage that IRLM requires. The number of locks that are acquired is dependent on your application.

You can estimate the IRLM control block structure at 540 bytes per lock. IRLM no longer supports placing locks in ECSA. All IRLM locks are now placed in the IRLM private address space.

Tip: In the IRLM address space startup procedure, set an estimated value for the IRLM control block structure size in one of the following ways:
  • During installation, set the value of field MAX STORAGE FOR LOCKS and MAX LOCKS STORAGE UNIT in installation panel DSNTIPJ.
  • In the IRLM startup procedure, set the region size to 0 (RGN=0). Set an estimated value for the maximum amount of above-the-bar storage that the IRLM address space can request (MLMT=nnnnnu). nnnnn is an integer, and u is the units for the integer: M, G, T, or P.

The PC and MAXCSA parameters are no longer used, but you must maintain them for compatibility reasons. You must specify the parameters and values, but their values are not used. The MAXCSA value must be in the range 0–9999. The amount of available storage for IRLM private control blocks, including locks, is determined by the operating system and site-specific IPL parameters. IRLM reserves approximately 10% of the available private storage to be used for must-complete lock requests.

Use the MODIFY irlmproc,STATUS,STOR command to view and monitor the amount of private storage that IRLM has available.

You can dynamically adjust the amount of below-the-bar private storage by using the MODIFY irlmproc SET,PVT command. This command changes only the monitoring threshold of private storage for IRLM.

You can dynamically adjust the limit for above-the-bar private storage by using the MODIFY irlmproc SET,MLT command. This command updates only the MEMLIMIT that z/OS uses to control the amount of above-the-bar storage that can be requested by an address space. A new value remains in effect until the next time IRLM is stopped and restarted or until the MODIFY command is issued successfully again.

Neither of these MODIFY commands change the physical amount of storage that the operating system assigns to the address space.

Enabling data sharing further increases the storage that IRLM requires.

Allied agent address spaces
In Db2, an allied agent address space is any user address space that attaches to Db2. This address space can include Resource Recovery Services attachment facility (RRSAF), TSO attachment facility, IMS attachment facility, CICS® attachment facility, and batch address spaces.

The size of the Db2 attachment facility code in the allied agent address space depends on which attachment facilities you use. TSO requires about 372 KB for the DSN command. CAF, IMS, and RRSAF each require about 36 KB for the Db2 attachment facility code. For all attachment facilities, except CICS Transaction Server and RRSAF, the Db2 attachment facility code must run below the 16 MB line of virtual storage. Applications can run above the 16 MB line.

Db2 stored procedures address spaces (WLM-named)
WLM-established stored procedures address spaces are WLM-established address spaces that can provide multiple isolated environments for stored procedures.

Each WLM-established stored procedures address space is associated with a Workload Manager environment.

Db2 for z/OS stored procedures support both main programs and subprograms; this support requires additional storage for each task control block (TCB). However, because you can run fewer programs in an address space, you can use less storage below the 16 MB line in each address space.

The amount of space that is required by a WLM-established stored procedures address space depends on the applications. Stored procedures that internally store a large amount of in-process work require more space than those that do not store much in-process work. Also, Java™ stored procedures require more space than others, such as COBOL stored procedures.

The overall amount of required space depends on the number of WLM-established stored procedures address spaces that are running, and the amount of space that is required for each.

Administrative task scheduler address space
Each Db2 subsystem has a coordinated administrative task scheduler address space that it can start by using a z/OS started task procedure.

Therefore, if there are many Db2 subsystems running on a single z/OS system, there is a separate administrative task scheduler with a separate name for each one.

Two instances of the same administrative task scheduler cannot run simultaneously. To avoid starting up a duplicate administrative task scheduler, at startup the administrative task scheduler checks all of the address spaces control block first to ensure that there is no address space other than itself with the same name. If another address space with the same name is already up and running, the administrative task scheduler that is starting up immediately shuts down with a console error message. The administrative task scheduler can check only the address spaces that are in the same system, not in the entire Sysplex.

The administrative task scheduler address space stays up, even when Db2 comes down.

Db2 also uses extended common service area (ECSA), 64-bit common storage, and the z/OS Shared Memory Facility. For more information, see Shared memory storage requirements and Common service area storage requirements.