User Space in iSeries

2480 pts.
AS/400 Object Cleanup
AS/400 performance
Can someone explain what the object type *USRSPC is used for on the iSeries and what is the best approach for cleanup of these objects? Thanks, Bill

Answer Wiki

Thanks. We'll let you know when a new response is added.

User spaces enable a large amount of data to be stored. They’re similar to data areas, but can hold much more information. Several of the system APIs write their output to a user space, which can then be read by another API and programatically processed by a language with pointer support (all of the ILE languages on the i support pointers).

Here’s one article about them – although it’s from 1991, it’s a good overview of the concepts. The maximum size of a user space has been increased from its original limit of 16 MB; I don’t remember the exact limit now, but it’s pretty huge. I think that increase was done either for 6.1 or possibly V5R4.

Minor correction: The maximum size of a *USRSPC is still in the neighborhood of 16MB. It has actually been reduced by a few K due to performance reasons.

Bruce Vining

Thanks for the correction, Bruce; I was mistaken.


Discuss This Question: 4  Replies

There was an error processing your information. Please try again later.
Thanks. We'll let you know when a new response is added.
Send me notifications when members answer or reply to this question.
  • slack400
    user spaces link These objects shouldn't really be 'cleaned up'. When you delete a user profile these objects can be deleted with the user. You may want to check with your development team to verify that your applications cleanup user spaces when a user logs off. You should be looking at other places for recovering storage if that's your intention.
    2,740 pointsBadges:
  • Cwc
    It is possible however, that an internally developed application isn't deleting the user spaces it creates after it's done with them, although it should be. I found one on our system a while back, and it had left 8 years worth of user spaces in the QGPL library.
    4,290 pointsBadges:
  • Cwc
    4,290 pointsBadges:
  • TomLiotta
    A user space can be thought of like a large *CHAR data area. A *CHAR (2000) data area can have a *CHAR (10) value in the first ten bytes, and another in the second ten bytes, and so on. It's up to your program to decide what goes into the bytes of a large data area. Any data structure that you can think of could be defined over such a data area (up to 2000 bytes). The same is true of a user space. You put whatever you can fit into one, with whatever structure or structures you choose. It's effectively a block of memory that is persistent and that can be accessed by multiple programs in multiple jobs. There are important differences between data areas and user spaces. First, user spaces can be up to (almost) 16MB in size. Second, you can create a user space that is small, but set an attribute of the space that allows it to grow as you keep writing data past the end of the space (until reaching the 16MB limit). The fairly large size means that you can build large lists of objects, usually by way of running one of the "list" APIs (which automatically set the 'auto-expand' attribute.) An initial small creation size, though, usually means that the space will only be as big as needed to hold the data you put into it. You don't need to create a 16MB space only to find out later that it only needed to be 50KB. User spaces are permanent objects. You might create one to hold a temporary list of object names, expecting to delete it at the end of your job. But if your job ends abnormally, the user space doesn't go away (unless it's in QTEMP). User spaces are often given temporary names, based on job numbers or dates. This avoids collisions, but it also helps them to collect without cleanup. Some method of determining which old spaces are obsolete should be made available. User spaces (object type *USRSPC), user indexes (*USRIDX) and user queues (*USRQ) are objects that provide relatively high performance, partly because they don't implement some of the overhead elements that other object types do. For example, ALCOBJ can set locks against them; but access isn't stopped for other jobs. The other jobs must explicitly check for locks if locking is needed. Obtaining a pointer to a user space can allow two (or more) jobs to "share memory". Storing a value in memory based over a user space gives essentially real-time access to the value in based memory in another program in a different job. In any case, the Last Used Date can be the most useful attribute to determine which user spaces may be deleted. Plenty of them can collect in user libraries, including QUSRSYS. For most of them, the name or the text can guide you to the job or function that's creating them. If you find a large cluster, you might make note for periodic cleanup. The DLTUSRSPC command (or option 4 in PDM) is the simplest method. Tom
    125,585 pointsBadges:

Forgot Password

No problem! Submit your e-mail address below. We'll send you an e-mail containing your password.

Your password has been sent to:

To follow this tag...

There was an error processing your information. Please try again later.

Thanks! We'll email you when relevant content is added and updated.


Share this item with your network: