Resolution:
Environment:
============
* z/OS
* TIBCO® Object Service Broker for z/OS

Symptoms:
=========
When the @MAP tool is used to allocate a large amount of transaction storage, an abend U2168 is issued along with message:
   S6BST001E STORAGE MANAGER ERROR: REQUEST LENGTH EXCEEDS MAXIMUM POSSIBLE FOR STORAGE POOL
The calling rule fails.

Cause:
======
On z/OS, the maximum single amount of transaction storage that can be getmained by the @MAP tool is 262,144 bytes less some control overhead. Although the "TIBCO® Object Service Broker Shareable Tools Software Release 5.2.0" manual under the description of @MAP states that a DATAREFERENCE exception is raised if "...the size value is invalid for the specified scope," the exception condition is not raised and the rule fails on the U2168 abend if an amount is requested exceeding the supported limit.

Note that the maximum transaction storage that a transaction can acquire via multiple @MAP requests or acquired automatically internally is set by the EE parameter TRANMEMMAX=. This is described in the "TIBCO® Object Service Broker Parameters" manual. You can specify this parameter via an EECONFIG assembly and linkedit or by an override in //HRNIN DD * in your Execution Environment (EE).

Workaround:
===========
Larger amounts of storage can be obtained by substituting SESSION for TRANSACTION type memory in @MAP allocation requests. With SESSION storage, areas of at least 1,048,000 bytes can be allocated. Use of SESSION memory should be used with caution since this storage is not automatically freed until session termination. You will need to reuse such storage areas in any repetitive processing; otherwise, the SESSIONMEMMAX limit or z/OS virtual storage available will be exceeded and the @MAP storage request will fail.

Resolution:
===========
Problem report OSBZ-1448 has been raised to address the following issues:
1) the exception DATAREFERENCE is not raised under documented conditions for z/OS systems
2) the behaviour between z/OS (abends) and Open Systems (succeeds) is different
3) the failing z/OS abend U2168 cannot be gracefully handled in the calling rule although the DATAREFERENCE exception should be raised instead of the abend according to the Tools documentation for @MAP
4) @MAP storage allocation limitations are not documented providing no guidance to the customer

Customers experiencing these issues should open a service request and ask to be put on the resolution list for problem report OSBZ-1448.

References:
===========
TIBCO® Object Service Broker Messages With Identifiers
TIBCO® Object Service Broker Parameters
TIBCO® Object Service Broker Shareable Tools

Abend U2168 when allocating large area of memory via @MAP tool