Sun Mainframe Transaction Processing Software Configuration Guide

This chapter describes the guidelines for configuring your application environment. It contains the following topics:

• Sun MTP Transaction Servers. You set this value in the VSAM Configuration Table (VCT). See Customizing the VCT.
• Choosing a Recovery Method.
• Effect of Recovery on Configuration.
• Determining the Number of Sun MTP Processes.
• Shared Memory Requirements.
• Determining the VSAM Buffer Size.
• Determining Swap Space.
• Kernel Parameters

Also refer to the Sun Mainframe Transaction Processing Software Administrator's Guide, which lists the limits of Sun MTP resources, such as VSAM file size.

---

Sun MTP Transaction Servers

A Sun MTP transaction server's primary function is to execute programs related to a transaction. A region must have at least one transaction server but cannot have more than 224.

The transaction servers are composed of a text segment and a data segment.

• Sun MTP code, COBOL and Liant PL/I runtime code, C code, and other third-party objects form the text segment. Third-party objects can be relational database management systems (RDBMS) runtime systems, sort runtime systems, or other application code.
• Working storage, Sun MTP environment variables, RDBMS, allocated memory, and program modules form the data segment.

In a Sun MTP region, all the transaction servers have the same text segment. However, the data segment varies depending on the type and size of the transaction it has executed. By default, in each transaction server, the data segment size is pre-configured. The following illustration shows the structure of a transaction server.

  FIGURE 4-1 Transaction Server Structure

Determining the Number of Transaction Servers

The Transaction servers field in the VCT specifies the total number of transaction servers available to the region. Because a transaction server is required to execute any transaction, online program, or batch program, this field also defines the maximum number of transactions and programs that can execute concurrently. Sun MTP uses this value to determine if transaction servers are available.

The value to set for this field depends on your application environment. For example, if all logged in users are involved in conversational transactions, as opposed to pseudo-conversational transactions, this number must at least equal the number of logged in users. If, however, the logged in users are involved in only pseudo-conversational transactions, this number can be much smaller.

Use a value of 16 to 20 or less if the transactions are small programs and the user enters large amounts of data on the user screen. (The user cannot type as fast as the transaction server can process the transaction.) If these transactions start background transactions, it is preferable to set the value to 20.

If you examine the output of kixdump -Spq, you can determine if there are any transaction servers waiting on the queue. It might be acceptable to allow about 20 percent of the transactions to wait on the queue for pseudo-conversational systems. For example, if you have 500 users but only 300 users are submitting transactions concurrently, you need 50 transaction servers. The likelihood of 50 or more users submitting transactions concurrently is low.

Experiment with different values to determine the optimal number of transaction servers for your environment. The following table provides a starting point for determining the number of transaction servers to configure based on the number of active users. The number of asynchronous transactions, batch jobs, and query jobs will increase the number of transaction servers required. You will need to monitor your system and evaluate your transaction profiles to achieve the performance you require.

Refer to the Sun Mainframe Transaction Processing Software Administrator's Guide for information about using transaction classes to manage your application workload.

Determining the Maximum Number of Background Tasks

The Maximum background tasks field in the VCT specifies the maximum number of background transactions and programs that can execute concurrently. The value in this field should not exceed 50 percent of the value you set for transaction servers. However, if the application depends on background transactions frequently started by the TRIGGER or START commands, you can set a value that is 75 percent of the value set for transaction servers.

Determining the Maximum Number of Batch Jobs

The Maximum batch jobs field in the VCT establishes the number of transaction servers that can only be used to execute batch transactions. The value in this field should not exceed 50 percent of the value you set for transaction servers.

Determining the Maximum Number of Query Jobs

The Maximum query jobs field in the VCT sets the total number of interactive processes that can execute concurrently. This parameter limits the number of transaction servers assigned to third-party processing tasks.

---

Choosing a Recovery Method

Sun MTP provides two methods for implementing recovery. The first method uses a recovery file, and the second method uses the Sun MTP Native Recovery File System (NRFS). Each method provides the same level of recovery protection, but ease of use and performance levels differ, as described in the following table.

See Chapter 6 for information about configuring both types of recovery.

---

Effect of Recovery on Configuration

Recovery can affect your region's configuration in several ways:

• VSAM uses approximately 300 bytes of shared memory for every locked resource (record). This should not affect your region unless you are using VSAM RC (read consistency) for batch programs. This is because VSAM acquires a lock for every record updated by a batch program. If your batch program updates many records, consider increasing the size of shared memory. See Shared Memory Requirements. Alternatively, you can modify your batch programs to commit the changes more frequently.
• If you are running batch programs, make sure your recovery file is large enough to hold the before images and block-split information that must be retained between commits.

---

Determining the Number of Sun MTP Processes

Sun MTP creates transaction servers and system processes during initialization. You can determine the total number of processes by calculating the number of Sun MTP-initiated processes and the number of user-initiated processes:

# of processes = # of transaction servers

+ 1 process for Sun MTP recovery
+ 1 process for interval control
+ 1 process for printing services
+ 1 controller process for other processes
+ (optionally) 1 process for remote terminal communications
+ (optionally) 1 process for communication using TCP/IP sockets
+ (optionally) 1 process for ISC from a remote region using SNA
+ (optionally) 1 process for ISC from a remote client/region using TCP/IP
+ (optionally) 1 process for Sun MTP Administration Framework
+ (optionally) 1 process for MQSeries integration
+ (optionally) 1 process for Sun MTP Communications Manager
+ (optionally) 1 process for each TN3270 server
+ (optionally) 1 process for transaction classes

During system execution, Sun MTP might add processes to fulfill specific tasks, such as standalone processes to run transactions such as CTBL, CFMS, and print requests.

Clients might require additional processes depending on how they connect to the region.

• If the user logs in locally, at least two processes are required. The first process executes a shell and the second process executes a Sun MTP client, such as unikixl or unikixl.exe. X terminal users require more processes.
• Remote non-SNA clients do not require additional processes on the system that is running the Sun MTP server.
• SNA users require one process as an SNA server and one additional process for each SNA user if the SNA server is executing on the same platform as the client.

The Maximum number of users field on the VCT screen, therefore, affects the number of processes as follows:

Maximum user processes = Maximum # of local users * 2

+ Maximum # of SNA users + 1 (if SNA is in use)

The maximum number of users cannot exceed the number of users specified in the Sun MTP site license. Therefore, the total number of processes required by a region is determined as:

Total processes = # of Sun MTP server processes

+ Maximum user processes

---

Shared Memory Requirements

Sun MTP uses five types of shared memory segments:

• Transaction area
• Terminal area
• VSAM buffer area
• System area(s)
• User area(s)

The first three areas are static, determined during startup based on the configuration in the VCT. The system area and user area are dynamic shared memory segments, and the sizes are defined by the user during region startup. The system area is used to store Sun MTP internal structures, which are allocated depending upon the user processing. The user area is used to store user-requested and Sun MTP-allocated areas visible to the application, such as the COMMAREA.

Calculating Shared Memory Requirements

Because the amount of dynamic memory required for executing Sun MTP is determined by many application and system factors, you can only determine the amount of dynamic shared memory to allocate by experimentation. Your user shared memory segment size should be at least as large as the largest working storage you have in any one of your online programs. Begin with a minimum of 4 MBytes using the -S option of the unikixmain command.

Some of the factors that can affect the use of dynamic shared memory are:

• Shared memory used by applications
• Number of concurrent VSAM locks
• Sun MTP resource definition
• Sun MTP Extended Trace Facility
• Interval control commands
• Started transactions
• ISC
• COBOL working storage
• BMS maps
• Temporary storage structures
• Transient data structures
• Number of concurrent browses

The following table describes each of the shared memory areas and provides formulas to use to calculate shared memory requirements.

Determining Where to Attach Shared Memory

Sun MTP shared memory contains structures that are shared by different process, including the transaction processors, recovery processor, and administration server process. The architecture of Sun MTP dictates that the shared memory should be attached at the same offset for all the cooperative processes that use the shared memory.

In FIGURE 4-2, if the process is a transaction processor, heap space is occupied by the runtime system, COBOL .int and .gnt programs, the JVM, Sun MTP structures, application dynamic memory, third-party products, and so on. As the transaction processor runs, it occupies heap space, and the heap pointer moves towards the start of Sun MTP shared memory.

If the process is a transaction processor or administration server process, shared libraries are attached in the libraries area. As more user, system, and Sun MTP shared libraries are attached to the process, the libraries area will start growing toward the end of Sun MTP shared memory.

If the heap space or the shared libraries encroach on Sun MTP shared memory, application aborts and region failures can occur. This situation calls for the placement of Sun MTP shared memory so that the region's cooperative process can grow both the heap space and the shared library space, if needed. The application requirements will determine the placement. For example, if COBOL .int and .gnt programs are not used, the heap space requirement is less.

By default the Sun MTP region attaches the shared memory at virtual address 0xEE000000, as shown in FIGURE 4-2. The user can adjust this by using the
-M t (threshold) -M c (maximum core) options to the unikixmain command.

  FIGURE 4-2 Process Image

Heap Space

All the Sun MTP processes use less heap space than the transaction processor.

When servicing application transactions, Sun MTP transaction processors accumulate heap space. After the memory threshold is reached, the transaction processor is discarded and a new transaction processor is substituted. This is referred to as recycling the transaction processor. If a transaction starts before reaching the threshold, it is allowed to acquire more memory until it reaches the maximum core value. At this point, the current running transaction is aborted and the transaction processor is recycled. This is referred to as an out-of-storage condition.

The memory specified by the memory threshold value is not immediately allocated up to the maximum core address when the transaction processor is initiated, but is allocated progressively during the instance of the transaction processor by application programs. This total storage, text and heap space, accounts for the memory used in a system; that is, the total memory of all transaction processors is subtracted from the total memory available from the system. If this memory exceeds the system memory, swapping or paging of processes and memory occur.

Shared Library Usage

The administration server process and transaction processor use more shared libraries than the other Sun MTP processes.

Shared libraries can be libraries provided by the Solaris operating environment, such as libc.so, Sun MTP-supplied libraries, such as ceci.so, and libraries provided by third-party products. As the shared libraries are attached, they occupy the space in the libraries area and can start using space above Sun MTP shared memory. When there is no more space to attach a shared library or new Sun MTP shared memory segment, the Solaris operating environment issues an errno 22 (for shmat).

Where to Attach Sun MTP Shared Memory

You can adjust the memory threshold and maximum core values during region startup using the -M t and -M c parameters of the unikixmain command. Setting
-M t to a negative value moves the attach point of shared memory down toward the heap, reducing the heap space by the same amount. Setting the -M t option to a positive value moves the attach point up, increasing the heap space. Finding the best value requires some analysis and experimentation.

Shared memory is attached by default at virtual address 0xEE000000. This address also acts as the default maximum core value. You can change this address by specifying the -M t as an offset from 0xEE000000.

For example, by setting -M t-16M, Sun MTP will attach to shared memory at 0xEE000000 minus 0x1000000 (-16 MBytes), which is the address 0xED000000. This also has the effect of setting the maximum core address value to 0xED000000. The valid range for setting the -M t is -1M through -3854M (note that these are negative numbers). The threshold can be set as a positive number by subtracting from the maximum core value with the -M c option. For example, if you start the region with these options:

-M t-32M -M c10M

the region will run with the following values, as shown in the output of the kixdump -M command:

Values of Shared Memory, Max Core, Threshold Memory 

Address of Shared Memory    (ec600000) 

Address of Max Core         (ec600000) 

Address of Threshold Memory (ebc00000)

Refer to the Sun Mainframe Transaction Processing Software Reference Guide for more information about the kixdump utility.

The recommended startup values for shared memory are -M t-1024M and
-M c10M.

---

Determining the VSAM Buffer Size

If your application uses VSAM datasets or has a high volume of temporary storage (TEMPSTG) access, you must specify the number of VSAM buffers in the Number of shared buffers field in the VCT. The following table provides values you can use as a starting point.

This VSAM buffer memory is allocated in the shared memory space, but is still a part of main memory.

---

Determining Swap Space

The swap space must accommodate the virtual memory requirements of Sun MTP, as well as any other processing on the host system. Swap space should equal or exceed the sum of the memory requirements for all applications you intend to execute concurrently.

If the target system's current file system cannot accommodate the necessary swap space, you must change the file system configuration. Many systems support a command that displays the actual block layout of a disk's partitions.

Free partitions are made into usable file systems with the newfs command or some derivative. Most systems have the mkfs command to which newfs is a preprocessor. This command creates a file system on the disk partition.

A file system must be mounted so that users or applications can access it. To mount the new file system use either the mount command or add an entry in the file system mounting table (usually /etc/fstab). Refer to the Solaris documentation for more information about file systems.

If the target system's resources still do not provide the necessary space, you can usually add internal or external hard disks.

---

Kernel Parameters

There are several operating environment, or kernel, parameters that can affect the startup and the performance of a region. This section provides information about these kernel parameters.

The parameters governing the UNIX kernel configuration reside in one or more files. Because default values for the parameters vary by hardware platform and might have been previously adjusted, you must review the current settings. If the current setting of a parameter meets or exceeds the Sun MTP requirement, do not modify it.

Changing Kernel Parameters

The methods for changing kernel values and generating a new kernel varies for different systems. For specific details, including the exact location of these parameters and instructions on how to change parameters and generate a new kernel, refer to the Solaris documentation. There are also many third-party books that cover system administration and kernel tuning.

The following table lists the kernel parameters.

^{1 (TableFootnote) These parameters only apply on some systems. A value set to 0x7FFFFFFF indicates a resource without limits.}

Sun Mainframe Transaction Processing Software Configuration Guide

816-5328-11

Copyright © 2004, Sun Microsystems, Inc. All rights reserved.