C H A P T E R 2 |
Important Operating Information |
This chapter contains important information related to the operation of your Sun MTP system. It contains the following topics:
You must set the KIXSYS and TMPDIR environment variables before performing any tasks related to Sun MTP.
The TMPDIR environment variable must be set in your system environment for Sun MTP. If the TMPDIR variable is not set, some of your transactions may not work properly.
To verify that the environment variable is set, type the following command at a shell prompt:
If no value is returned, you must set this environment variable in your region setup script. Set it to the directory where temporary files are saved.
On AIX platforms, the LIBPATH environment variable identifies the shared library directories. You must include the $UNIKIX/lib directory when setting the LIBPATH environment variable, or the region will not start and some Sun MTP utilities will not work.
Note - The Sun MTP documentation refers to the LD_LIBRARY_PATH environment variable, which is used on Solaris platforms, and which serves the same function as $LIBPATH. |
You only need to set the KIXBTCH environment variable if you are using standard batch. On startup, Sun MTP checks the VSAM Configuration Table (VCT), and if there is a Y in the Connect to Batch field, it does not check that $KIXBTCH is set.
When you execute the kixinstall utility, a check is now performed to ensure that you are using a compatible version of the AIX operating system. If the version of AIX is earlier than release 5.2, an error message is displayed:
The information in this section describes how Sun MTP allocates and uses shared memory on AIX platforms. Because there are significant differences between AIX and Solaris platforms, information about shared memory on AIX platforms is documented here. Most of the shared memory information in the Sun Mainframe Transaction Processing Software Configuration Guide does not apply to AIX, and that which does is included here.
The standard address space model on AIX limits a process to 11 shared memory segments, each a maximum of 256 Mbytes. Therefore, if you were to instruct Sun MTP to allocate its shared memory using a segment size less than 256 Mbytes (for example, by using -S32M as a startup parameter), Sun MTP would only be able to address the first 32 Mbytes of any segment allocated. It would not be able to use the other 224 Mbytes of virtual address space for the segment. This has the effect of limiting the amount of data that can be stored by Sun MTP or the application in the various shared memory segments.
To address this limitation, Sun MTP uses a default shared memory segment size of 256 Mbytes. You could specify a smaller segment size using the -S startup parameter, but if you attempt to start the region with a value less than 16 Mbytes, or a value greater than 256 Mbytes, Sun MTP overrides the value with the default 256 Mbytes and issues a warning message.
Sun MTP has two startup parameters related to shared and process local memory:
The -S option specifies the shared memory segment size. Valid values range from 16 Mbytes to 256 Mbytes. The default value for this parameter is 256 Mbytes, which is the optimal value for most application environments.
These parameters control the amount of local process memory or heap space that can be used by a unikixtran process. This local memory begins at address 0x20000000 or segment two of the transaction processor's virtual address space.
The -M t, or threshold parameter, specifies how large the local process memory can grow. The -M c, or max core parameter, specifies how much memory beyond the threshold can be used before the unikixtran process automatically rolls over and another unikixtran process is started. The minimum threshold value, and the default value if the -M t option is not specified, is 32 Mbytes. The default -M c value is 4 Mbytes. This means that a transaction processor's local process memory can grow to 36 Mbytes before it aborts and a new unikixtran process is started.
These two options are also tied to the ulimit data value. If you type the command ulimit -d at the command line, the system's limit for your user ID's local process memory is displayed. If the sum of your -M t and -M c options exceed this value, the region will not start. You must either adjust the values of the -M t and -M c options so that their sum is less than the ulimit -d value, or you must increase the local process memory size using the following command, which changes the size for the process memory:
where nnnnn is the new size for the process memory.
The following examples illustrates the interaction between the ulimit data and the
-M t and -M c values.
The ulimit -d output indicates 131,072 Kbytes or 128 Mbytes.
If you do not provide -M t and -M c startup options, the defaults are used
(-M t32M and -M c4M). The region starts and a transaction processor's local process memory can grow to 36 Mbytes before aborting and restarting.
The ulimit -d output indicates 131,072 Kbytes or 128 Mbytes.
If your application allocates significant local memory, you might provide the
-M t100M and -M c10M options at startup. The region will start and a transaction processor's local process memory can grow to 110 Mbytes before aborting and restarting.
The ulimit -d output indicates 131,072 Kbytes or 128 Mbytes.
If your application requires approximately 200Mbytes of local memory, and you provide the -M t200M and -M c4M options at startup, the region will not come up because 204 Mbytes exceeds the system limit of 128 Mbytes. You must increase the process memory using the ulimit command. For example, to increase the memory to 210 Mbytes (215,040 Kbytes), execute the following command:
Now, the -M t and -M c options are within the system limits and the region will start.
In this release, Sun MTP does not support the large and very large process address space models on AIX, which provide a method to allocate additional segments, beyond segment two, for local process memory.
Caution - The extended shared memory support using the EXTSHM environment variable is not supported. |
There are no kernel parameters on AIX for shared memory that need to be configured or adjusted. SHMMAX, SHMSEG, SHMMNI are not valid on AIX.
Sun MTP uses six types of shared memory segments:
The first four areas are static, determined during startup based on the configuration in the VCT and a region startup option. 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.
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.
Some of the factors that can affect the use of dynamic shared memory are:
The following table describes each of the shared memory areas and provides formulas to use to calculate shared memory requirements.
Although there is a requirement that all Sun MTP processes attach shared memory at the same offset, the application user has no control over this. Sun MTP and the AIX operating system manage this automatically.
Shared libraries on AIX utilize their own separate 256-Mbyte segment, so there is no conflict with the 11 shared memory segments.
Two AIX commands, procmap and svmon provide memory layout information for processes that are running on the system. The svmon command provides information about shared memory segment utilization.
The way Sun MTP stores the path names to VSAM files has changed. Now, the full path name to a VSAM file is stored in its file control block. This change has the following impacts:
Changes made to Sun MTP in this release to improve the performance of main memory TSQs are documented in this section.
The Sun MTP default behavior is to write temporary storage queue (TSQ) information to disk (auxiliary storage). You can override this behavior by using the
-TM option to unikixmain at region startup. The M argument instructs Sun MTP to write TSQ information to memory (main storage). You can also use the MAIN option on the WRITEQ TS command to override the default behavior.
In releases prior to 8.0.1, when an item was written to a TSQ, Sun MTP allocated memory for the item from the pool of shared memory. When the queue was deleted, the memory was returned to the pool. The allocation and deallocation of memory for each TSQ item could incur a significant amount of memory management overhead.
The changes made in this release enable you to tailor your region's use of memory for TSQs.
You can reduce memory management overhead by specifying a TSQ block size at the time the region is started. This causes Sun MTP to allocate that size block at the time the queue is created and the first item is written. On subsequent writes, Sun MTP simply allocates space for an item from this block; no shared memory overhead is incurred after the first write. When the block becomes full, additional blocks are allocated as needed (requiring a shared memory allocate) to hold all of the queue items. When the queue is deleted, any blocks that had been allocated to that queue are put on a free list and can be used by other TSQs. The free list implementation removes the overhead of returning space to shared memory. Current queues, or queues created in the future, can use the memory blocks from the free list, which might even eliminate the initial allocation of a memory block if one is found in the free list. See Reallocating Blocks From the Free List.
Sun MTP now supports block sizes of 512 bytes, 1 kilobyte (Kbyte), 2 Kbytes, 4 Kbytes, 8 Kbytes, 16 Kbytes, and 32 Kbytes. If you specify the -TM option to unikixmain at startup, the default block size for TSQ data is 512 bytes. You can override the default size by also specifying the -q startup option.
The valid values for the -q option are: -q1 for 1-Kbyte blocks, -q2 for 2-Kbyte blocks, -q4 for 4-Kbyte blocks, -q8 for 8-Kbyte blocks, -q16 for 16-Kbyte blocks, and -q32 for 32-Kbyte blocks.
The following table shows the results of using various combinations of the startup options and the WRITEQ TS command with the MAIN and AUXILIARY options.
Sun MTP must allocate a new block of memory for TSQ items if there is no space in the existing blocks allocated to the queue, and there are no free blocks in the free list. If the record size is greater than the region's configured block size, a size large enough to hold the record being stored is allocated.
Sun MTP never splits items across memory blocks. Therefore, if a 100-byte item is being written, and no memory blocks allocated to the queue have 100 bytes available, a new block is allocated to contain the item. Depending on the size and mix of items written to a queue, some virtual address space in the memory blocks might not be used. For example, if a 512-byte block size is used, and the item size is 100 bytes, five 100-byte items, or 500 bytes can be written to the block. This leaves 12 bytes within the block that cannot be used, unless an item of 1 to 12 bytes is written.
Sun MTP maintains separate free lists for each of the different block sizes. Blocks are allocated from the free lists in the following ways:
Sun MTP correctly handles any size queue item, up to the maximum size of 32 Kbytes. If an application attempts to write a queue item greater than 32 Kbytes, an error is issued.
Before choosing a block size, you must analyze the application's use of temporary storage queues. Consider the number of queues and the total size of each to determine the total amount of space required and the best queue size.
The following examples describe why certain block sizes are appropriate for certain application environments:
The kixdump -q command displays information about the active temporary storage queues, including the queue name, the queue type (auxiliary or main), the total size of the queue, the last item read from the queue, the last item written to the queue, the number of active items, and the first available item number. If the queue type is main, additional information about the data blocks allocated to the queue is also displayed. This includes the address of the data block, the pointer to the next data block for the queue, the pointer to the available or free space in the block, the number of bytes available in the block, the maximum item size (in bytes) in the block, the count of items contained in the block, the total unused space (in bytes) in the block resulting from rewrite activity, and the block size in bytes.
Sun MTP dynamically creates a TSQ the first time it is named in a WRITEQ TS command. You can also predefine TSQs in the Temporary Storage Table (TST); these queues can be local or remote. There is no limit to the number of TSQs you can define in the TST. Each TSQ can contain 32,768 records, and each record can contain up to 32,768 bytes of data.
Because main temporary storage requires more memory than auxiliary storage, use it primarily for small queues that have short lifetimes or are accessed frequently. If your application writes large amounts of data to TSQs, and the data have a relatively long lifetime or are accessed infrequently, consider using auxiliary temporary storage.
TSQs written to auxiliary storage can be defined as recoverable, but not queues in main storage.
If an attempt is made to write to an ESDS file that is larger than 4 Gbytes, Sun MTP now returns an error to the calling program.
If the ESDS file is 4 Gbytes in size or greater, INVREQ is set and RESP2 is set to 1.
Limitations on the number of TCP/IP and SNA sessions that can exist for a region were not documented.
Note - Intersystem communications sessions over SNA is not supported in this release on AIX platforms. |
The number of TCP/IP sessions is controlled by the TCPRTERM and TCPSTERM environment variables.
The number of SNA sessions are controlled by the DCLRTERM and DCLSTERM environment variables.
When configuring terminals in the 3270 Devices portion of the Terminal Control Table (TCT), the Host Name and Port Number fields on the Host & Port screen are applicable only for terminals that access the region by means of the TPS PU4/5 server software (unikixtrin process). These fields are ignored for all other terminal definitions.
The behavior of socket client connections has changed. The socket protocol specifies that the socket client connect and then send the initial socket message. If this initial send is never done, the socket remains in the control of the unikixsock process forever, or until the socket client disconnects. This can cause the region to behave abnormally.
A new environment variable, KIXSOCKET_TIMEOUT, enables you to specify the amount of time to wait for the socket data before disconnecting the client. You must set this environment variable before starting the Sun MTP region. For example:
The value 10 indicates that the unikixsock process will wait 10 seconds for the socket data before disconnecting the client.
In Sun MTP releases prior to Release 8.0.0 patch 7, the kixbms utility incorrectly generated the placement of the named attribute fields in COBOL copybooks.
For example, you might have coded your programs that address map attribute field names to compensate for this:
Now, if you regenerate the map copybook using kixbms, you will also need to change your program reference to map attribute fields. For example, you would have to change the above example to:
If you do not use the above style of qualified data-name referencing of map attribute field names in COBOL programs, regenerating a map copybook should not require any programming changes.
The kixtran utility has changed to accommodate different user permissions. The kixtran utility creates an error file in the $KIXSYS directory named unikixepi.err.pid, where pid is the process ID of the kixtran process. If the user executing the kixtran utility does not have permission to write to $KIXSYS, the utility tries to create the file in the user's current directory. If it cannot, the errors are sent to standard error (stderr).
In prior releases of Sun MTP, when .bms, .sgu, and .map files were generated by the Screen Generation Utility (SGU), the file permissions were set to read/write for the owner (user who started the region) and read for the group; no permissions were granted for others. Now, the file is created with the permissions allowed by the user that started the region. For example, if the user that started the region has a umask of 003, the file will be created with the following permissions: read/write for owner and group, and read for others.
A dataset that is defined as remote in the File Control Table (FCT) is not counted as an alias. A remote dataset contains a value in the SysID field on the Remote Characteristics screen of the FCT.
A dataset whose Filename field is blank in the FCT is not counted as an alias.
Previously, the application name configured in the System Initialization Table (SIT), was used as the prefix on all external security manager (ESM) resource access check calls. Because this approach was incompatible with how CICS prefixes resource names with its ESM (RACF), customers with existing CICS/RACF-prefixed resource names would not be able to directly migrate to Sun MTP Secure. Now, the resource name prefix is formed by taking the UNIX user ID that started the region as the prefix and adding a period (.) to it.
If you are using Sun MTP and Sun MBM together, and you find it necessary to completely restore the region's $KIXSYS directory from a backup, you must also resynchronize the subsystem and region so that they can reconnect. Follow this procedure:
1. Shut down the Sun MTP region.
2. Restore the $KIXSYS directory.
4. On the BAM main menu, choose option 3, Applications & Subsystems.
5. On the Applications & Subsystems menu, choose option 4, Update a Subsystem.
6. Enter the number of the subsystem to update.
7. On the Update menu, choose option 2, Change MTP Region.
8. Type the path name of the $KIXSYS directory and press Return.
If the screen already displays the correct path name, just press Return.
9. When the confirmation screen is displayed, press Return.
11. Restart the Sun MTP region.
This section describes products or functionality no longer supported by Sun MTP.
Refer to the Sun Mainframe Transaction Processing Software Configuration Guide for information about configuring recovery.
Use the following conversion tables for either double-byte character sets (DBCS) or single-byte character sets (SBCS). The tables are located in the $UNIKIX/lib directory.
The following tables, which are also located in the $UNIKIX/lib directory, provide support for the Euro symbol:
Copyright © 2004, Sun Microsystems, Inc. All rights reserved.