User Storage Limits and Application Processing

Published: January 30, 2008

by Joe Hertvik

Every once in a while, I'll run into a situation where for no apparent reason, a user can no longer run a process that either updates user-created System i data or creates an output file. The process will run fine one day and stop working the next day. After investigation, the problem usually has something to do with the user's Maximum Storage Allowed (MAXSTG) parameter.

The MAXSTG parameter is assigned to a user profile when that profile is created. Its mission is to tell the operating system how much auxiliary storage (in kilobytes) can be assigned to store permanent system objects owned by this user. While many shops will not allow users to create their own objects, it's interesting how many common applications involve user object creation, including the following items.

• Submitting a batch job that creates temporary files
• Connecting to the system through ODBC or JDBC and uploading data
• Running i5/OS queries that create new files from available data
• Several third-party applications

If a user's MAXSTG is set too low, these and other similar applications may bomb out when the user hits his storage limit. If the user is running an interactive job when the limit is hit, an error message is displayed on their screen. If the user's storage limit is exceeded while creating or updating objects during a batch job, an error message is sent to the job log and the target object will not be created or updated.

Conversely, if MAXSTG is set too high for the user, the application will run but system storage may start filling up when the user puts too much garbage in the system. The key is to set MAXSTG to a value that is high enough for the user to create whatever objects are needed but not so high that the user can junk up the system by creating too many objects. It's also worth noting that MAXSTG is generally more of a problem with power users who create their own databases or upload a lot of data, than it is with every day users.

Here's the drill for determining when a user has crossed their maximum storage limit and how to change that limit, when necessary.

1. As mentioned earlier, all users have a MAXSTG attached to their user profile. For many shops, the default MAXSTG value is *NOMAX, which means that the user can use an unlimited amount of hard drive space if he wants to. However, many shops override the default setting and assign limited MAXSTG values to individual users. In other instances, vendors may specify that software-centric user profiles are assigned a specific amount of storage that is smaller than the default *NOMAX value. So there are several situations where a user may not have the ability to allocate as much hard drive space as he wants.

2. If you are seeing that a user is unable to create a file or add records to an existing file that they own, you can check the user's MAXSTG parameter and other storage information by running the following Display User Profile (DSPUSRPRF) command.

DSPUSRPRF USRPRF(user_profile_name)

On the Display User Profile screen that appears, page down to about the third screen where you will see an area similar to the following that lists out the storage information for that user:

Storage information:                                  
  Maximum storage allowed  . . . . . . . . :   *NOMAX 
  Storage used . . . . . . . . . . . . . . :   32     
  Storage used on independent ASP  . . . . :   *NO  

The user's MAXSTG value can also be checked and modified in iSeries Navigator (OpsNav) by opening the user profile under the Users and groups→All users path in OpsNav and clicking on the Job button under that profile. The Maximum Storage Allowed value can be found under the General tab on the Jobs panel for that user.

3. In scenarios where the user has maxed out his maximum storage allocation, the Storage Information portion of the DSPUSRPRF screen could look something like this:

Storage information:                                  
  Maximum storage allowed  . . . . . . . . :   32
  Storage used . . . . . . . . . . . . . . :   32     
  Storage used on independent ASP  . . . . :   *NO  

In storage overflow situations, the Storage Used Value will be very close to or contain the same value as the Maximum Storage Allowed value on the screen. If the user is having trouble uploading data, creating records, or creating files and you see this situation, you can change the user's MAXSTG to a larger value by running the following Change User Profile (CHGUSRPRF) command.

CHGUSRPRF USRPRF(user_profile_name) MAXSTG(new_value)

You can also change the user's MAXSTG value in iSeries Navigator by opening the user profile under Users and groups→All users, clicking on the Jobs button, and then opening the General tab inside the Jobs panel.

Although you can assign any MAXSTG value that you want to the user, the system will allocate storage to the user in 4 kilobyte increments (4K). So if you assign a MAXSTG value that is not divisible by 4 (i.e., 9K), the system will allocate the smallest multiple of 4K hard space (12K in the case of a 9K assignment) that will fit the original MAXSTG request.

If you are dealing with a power user and you want to allow this user to allocate as much disk space as they want, you can also change MAXSTG to indicate that there is no maximum to the amount of storage this user can access by running this CHGUSRPRF command.

CHGUSRPRF USRPRF(user_profile_name) MAXSTG(*NOMAX)

You can also set MAXSTG to No Maximum by using the General tab inside the Jobs panel for this user under their OpsNav user profile.

So as you can see, once you get the hang of setting and discovering user profile storage limits, they are easy to find and just as easy to manipulate. The trick lies in knowing what to look for.

                     Post this story to del.icio.us
               Post this story to Digg
    Post this story to Slashdot