AUXILIARY STORAGE in CA-OPS/MVS

book

Article ID: 52621

calendar_today

Updated On:

Products

CA SOLVE:Operations Automation SOLVE:Access Session Management CA SOLVE:FTS CA OPS/MVS Event Management & Automation CA SOLVE

Issue/Introduction

Description:

Receiving error message: IRA200E AUXILIARY STORAGE SHORTAGE

Solution:

IRA200E AUXILIARY STORAGE SHORTAGE

Explanation: The system detected a shortage of available slots in the auxiliary storage paging space. This message is issued when 70% of all available slots in the system are in use.

System Action: The system rejects LOGON, MOUNT, and START commands until the shortage is relieved. The system keeps initiators from selecting new jobs and users with rapidly increasing auxiliary storage requirements from running until the shortage is relieved. The system writes message IRA206I to identify address spaces with the most rapidly increasing auxiliary storage requirements. Use the PAGEADD command to add auxiliary storage to the system.

System Programmer Response: Allocate additional auxiliary storage to the paging data sets during system initialization. Examine programs that use virtual I/O (VIO) and other jobs with heavy auxiliary storage requirements for possible looping or extraordinary auxiliary storage requirements.

Auxiliary storage is an ON DEMAND, type of storage, meaning if you are assigned it, and no one else needs it, you will keep it. Because OPSLOG/SYSCHK1 etc... OPSMAIN's address space can be very large, even though the true working set size is much smaller. If another address space demands the storage, the auxiliary storage manager will 'steal' it from CA-OPS/MVS.

Auxiliary storage is on a 'as needed' basis. If an address space needs auxiliary storage then it can be stolen from CA-OPS/MVS as needed.

You do not need to shut down CA-OPS/MVS because you see that it has reached 30% (30% is only an example) - that is not a problem - as stated before if auxiliary storage is required by another address space, it will take the storage from CA-OPS/MVS.

First verify that OPSLOG is getting allocated properly by checking the BROWSECHECK parameter in the 4.1.1 panel.

The BROWSECHECK parameter displays the total number of OPSLOG checkpoint requests that successfully wrote data to the OPSLOG checkpoint VSAM data set. If no new event data is received during a checkpoint interval, the checkpoint is bypassed.

**if the value is 0 then OPSLOG is not getting allocated and is being kept entirely in storage!**

Please note. You cannot set the BROWSECHECK parameter. If the OPSLOG DD is not allocated then the OPSLOG is simply an area of extended private virtual storage backed by the paging subsystem and will have auxiliary storage problems. You need to allocate a true DIV data set to your OPSLOG DD then the OPSLOG will be DIV backed and won't require paging space.

The OPSLOG will be check-pointed to the DIV and the BROWSECHECK value will increase at each checkpoint interval. Without the DIV, the OPSLOG data is not saved across products restarts.

Even if OPSLOG is getting allocated properly, different systems will have different storage usage by CA-OPS/MVS. OPSLOG uses DIV datasets which act like paging datasets. OPSLOG will keep these pages of data in CA-OPS/MVS until MVS needs them. What this means is that if a system is not busy, CA-OPS/MVS will keep more pages of OPSLOG in its storage. When the system gets busy, CA-OPS/MVS will release these pages of storage for MVS to use...

The biggest factor for storage usage is OPSLOG, if customer wants to reduce storage usage by CA-OPS/MVS, then reduce the size of OPSLOG.

Environment

Release:
Component: SOPMVS