|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 might 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.
You must include the $UNIKIX/lib directory when setting the LD_LIBRARY_PATH environment variable, otherwise the region will not start.
You only need to set the KIXBTCH environment variable if you are using standard batch. If your region uses Sun MBM for batch processing, you do not need to set $KIXBTCH. 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 performed to ensure that you are using a compatible version of the Solaris operating system. If the version of Solaris is earlier than release 8, the following message is displayed:
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 shared 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.
TSQ items specified in the WRITEQ TS...MAIN command are written to in-memory queues using the default 512-byte block size, or a size large enough to hold the item. Other TSQ items are written to disk.
TSQ items specified in the WRITEQ TS...MAIN command are written to in-memory queues using the block size specified in the -q option, or a size large enough to hold the item. Other TSQ items are written to disk.
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.
The TSQ enhancements made in this release increase the use of operating system semaphores. If your runtime environment is set to use semaphores (the Sun MTP default), rather than Solaris mutexes, you or your system administrator must review the semaphore values in the /etc/system file to ensure that they are sufficient. TABLE 2-2 describes the affected semaphores and provides examples for setting the correct values.
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.
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, be aware that 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 and PL/I copybooks.
For example, you might have coded your programs (PLI and COBOL) 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 PL/I or 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).
Caution - Make sure to set the appropriate permissions on Sun MTP system transactions. Sun MTP provides transaction security by means of the Program Control Table (PCT) and the Sign-On Table (SNT). Or, you can use Sun MSF external security management to secure your transactions. Refer to the Sun Mainframe Transaction Processing Software Administrator's Guide for information about both security models.
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) will not be 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.
3. In Sun MBM, start BAM.
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.
10. Exit BAM.
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: