Unconfigured Ad Widget

Collapse

Announcement

Collapse
No announcement yet.

*USRSPC objects in QRPLOBJ

Collapse
X
Collapse
 
  • Page of 1
  • Filter
  • Time
  • Show
Clear All
new posts
Previous template Next
  • #1

    *USRSPC objects in QRPLOBJ

    QRPLOBJ has been on all AS/400 machines. I understand that when you compile objects while they are in use using REPLACE(*YES), the system moves executing objects to QRPLOBJ with a system generated object name to prevent duplicate names. The text has the name of what the original object was. Unfortunately IBM doesn't tell us the criteria they use in a program called QEZCleanup to purge the data from this library. The QEZCleanup program does run all the time. If you have a large object that is no longer in use, you can delete it. If it is use, the system won't let you. It also looks like IBM is using it for *USRSPC objects they will eventually be cleaning as well. There is no setting to prevent it's use. If you want to minimize it's use, write new CL program to #1 Allocate the object so it can't be used while you recompile it. #2 Delete the old object. #3 Compile the new one. #4 DEALLOCATE the object again. If you do this, you will also have to make sure no one is using the program or file when you wish to compile it. IBM does clean this stuff out eventually, so it works best to not worry about the space it it, and let IBM take care of the housekeeping. I wish you the best on this issue, and hope this helps you understand what is happening.
    Tags: None
  • #2
    *USRSPC objects in QRPLOBJ

    sthompso wrote: > 1. QRPLOBJ is a secured library at our site. Not only can I not delete > the *USRSPC objects, I can't even display them. Our DBA staff has > already told me they're not in business to be cleaning up after messy > programmers! (especially since none of the other WDSc users in the > shop have this problem) Dwight has already explained the base purpose for QRplObj. I'd be interested in an explanation as to why this library is secured. There'd be no reason to secure it given it's base purpose. Thus you'd have the ability to clear it up as necessary. Are there others that are working on the same types of programs you are? If not, then their stance of not cleaning up after "messy" programmers is not realistic and they need to educate themselves as to the purpose of the library. Bill

    Comment

    • #3
      *USRSPC objects in QRPLOBJ

      Hi, You can just change the authority to the library, and then you can delete any objects in the library, assuming they're not being used.

      Comment

      • #4
        *USRSPC objects in QRPLOBJ

        I asked IBM about this library... it doesn't seem to matter how you compile -- REPLACE(*YES) or (*NO)... it still copies the current pgm object into this library while the other is being created. Furthermore, if someone us using the pgm object you are compiling, they will use the pgm in QRPLOBJ until exiting the program (I have seen it in the call stack of the user's job log)... when they call it again, they will use the new object. Even though it's bad practice, I compile pgms that are in use all the time. The cleanup is supposed to occur during an IPL... according to IBM this library is cleared then.

        Comment

        • #5
          *USRSPC objects in QRPLOBJ

          I make it a practice each morning to type the following command: CLRLIB QRPLOBJ Dave

          Comment

          • #6
            *USRSPC objects in QRPLOBJ

            I had the same problem that was described here. After I spent some time searching for a solution, I finally found the cause of all the *USRSPC objects in QRPLOBJ. My problem was that I used the "Iseries Job Status" View (Window -> Show View -> Other... -> IseriesIseries Job Status), with a refresh interval of 10 seconds in combination with the option "Add batch compiles to the Iseries Job Status view" and "Add batch commands to the Iseries Job Status view" (Window -> Preferences -> Remote Systems -> Iseries -> Command Execution). These settings resulted in a *USRSPC object that was written every 10 seconds in QRPLOBJ. When I increased the refresh interval to 1 minute, a *USRSPC object was written every minute... So there were 2 solutions for me to avoid all the *USRSPC objects: 1) Turn off the Command Execution preferences: no adding to the Iseries Job Status view. 2) Set the refresh interval in the Iseries Job Status View to Never (only when I do a manual refresh I get a *USRSPC object). Hope this helps... I don't know if the *USRSPC objects are normal "side effects", perhaps the WDSc developing team can tell us?!

            Comment

            • #7
              *USRSPC objects in QRPLOBJ

              We are on WDSC 5.1.2, and our AS400 is at V5R3. For some reason, WDSC is not cleaning up after itself. I am becoming the proud owner of thousands of objects in QRPLOBJ, most of them of type *USRSPC. I got 1086 new *USRSPC objects in one cycle of debug/fix/recompile! The *USRSPC objects have names like Q670121BB8, and their text description is QTEMP/RSEUTILS. No one else in my shop has reported this problem. Does anyone have any idea what's going on? Here's why some of the helpful suggestions I have received haven't helped: 1. QRPLOBJ is a secured library at our site. Not only can I not delete the *USRSPC objects, I can't even display them. Our DBA staff has already told me they're not in business to be cleaning up after messy programmers! (especially since none of the other WDSc users in the shop have this problem) 2. I had hoped it would help if I could refrain from using System Request/2 to shut down my RSE Server, but after shutting down properly from RSE, I still have thousands of *USRSPC objects. 3. Logging off the iSeries and back on again doesn't help; they only seem to go away at IPL. 4. We only IPL once a week, and another time in a couple hours of debugging I have used up 20% of my available storage on about 9700 of these things, after starting out today clean after an IPL. Bottom line -- I really need to get this to stop! Does anyone know a setting I should have set, or some other way to prevent persistent *USRSPC objects in WDSc ?

              Comment

              • #8
                *USRSPC objects in QRPLOBJ

                The objects in QRPLOBJ are a side effect of creating a user space where one already exists. This is simply the way OS/400 works. If you delete the data area first, then create a new one, you won't have this issue. I assume IBM doesn't really care because, as David implies, most of us clear QRPLOBJ on a semi-regular basis. The idea of a "locked down" QRPLOBJ is a little unusual to me; I can't discern a valid business reason to not allow people to delete the objects there, especially if they own them. Anyway, I suggest looking at the solution above, and also trying to get some relief from your IT gatekeepers. If neither seems to work, please post again and I'll try to get some more definitive information. It seems that a very simple fix to WDSC (delete the data area before creating it again) would relieve this problem. Joe

                Comment

                Previous template Next
                Working...
                X