If larger objects are spread across multiple storage groups, you can avoid virtual storage shortages in OAM address space when running your OSMC storage management cycle by limiting the number of storage groups that can be run concurrently. For example, if the maximum object size (specified in the IEFSSNxx with the MOS=nnn keyword) is 100MB, processing a maximum of 10 object storage groups at a time is recommended. For a maximum object size of 256MB, a maximum of four storage groups for concurrent processing is recommended. The maximum number of storage groups processed can be set using MAXS= in the PARM field on the JCL EXEC statement in the OAM cataloged procedure. The default value is MAXS=2.

You should also determine the maximum object size of any other storage groups you have and adjust the MAXS= parameter accordingly. If, for example, you have only five storage groups with the potential to contain 100MB objects, you could specify more than five additional storage groups.

In general, OSMC will process concurrently up to 15MB of data per storage group with the possibility of processing 15MB plus the largest object size in the storage group. When processing multiple storage groups concurrently, ensure that the total amount of storage across all storage groups stays around 1GB. This will allow the remaining 1GB to be used for other OAM address space functions. The use of a monitoring tool during the initial OSMC storage cycles can help you avoid problems resulting from virtual storage constraints.

OAM exploits 64–bit virtual storage when objects greater than 256MB are written to or read from the file system sublevel or tape. If your installation will implement objects greater than 256MB on the file system sublevel or tape, you must ensure that OAM is configured properly to access virtual storage above the 2G bar and you must plan for the significantly increased storage utilization on your system. For more information see MEMLIMIT for OAM, Auxiliary storage and real storage considerations, and System paging.