AS400 Suddenly Out Of Space

AS/400 Disk Space
AS/400 storage
I have an AS400 V5R1 that was at 60% and now over the weekend shot up to 99 % full. I have no ideas why I lost all the space. This happend last week as well and I removed an old library but still happening. Reclaim Storage and Splfiles Does Nothing. Is there a Journal that could have gone nuts ?? The system does not tell me anything, just out of space. This happend after weekly IPL on weekend. Please Help. Thank you

Answer Wiki

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

You need to run a RTVDSKINF job then PRTDSKINF to view the disk space usage on your system.
This can run several hours though so run during downtime.
In the interim, do you schedule a cleanup job? CHGCLNUP F4 to view. If you haven’t then you can use this to cleanup your history logs, etc..
Or WRKOBJ OBJ(QSYS/QHST*) OBJTYPE(*FILE) to manually delete QHST files
Check the QRPLOBJ library, you can clear this library.
If you know your system, type wrkobj *all/*all *jrnrcv. Delete the excessive jrnrcvs.
WRKOBJPDM for a specific library and sort by object size or DSPLIB and print out to see the large objects.


RTVDSKINF/PRTDSKINF might be no help if you have no prior baseline or trend data. Further, it might be the cause of hitting the limit if you run it. RCLSTG should be avoided if you don’t know the cause — it won’t tell you anything.

V5R1?? or V6R1?

Sign on as an *ALLOBJ/*SPLCTL/*JOBCTL user at least.

Start a session and run WRKACTJOB. Press <F11> to view elapsed data. Place the cursor over in the column labeled AuxIO and press <F16> to sort. Start investigating the jobs from the top of the list on down. Press <F5> a couple times over the following couple of minutes to view refreshed statistics.

In a second session, run WRKOUTQ. (The default should be *ALL and you should have authority.) View the list to see if any *outq is receiving a high number of entries. Press <F5> to see if the number rises for any queue. Investigate suspicious *outqs to see what is being added.

I’d be suspicious of (1) journal receivers, (2) spooled files, (3) QRPLOBJ from a looping job and (4) streamfiles — it _might_ be a shared directory that’s getting added to. (RTVDIRINF/PRTDIRINF might be more appropriate than xxxDSKINF, but might also put you over the limit.)

If this is V6R1, it _might_ not be one of your jobs. If V6R1, is this a Power6 processor?


Discuss This Question: 5  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.
  • A4ginatl
    Theer are a number of reasons for disk space getting gobbled up. Firstly run the RTVDSKINF and PRTDSKINF to look for libraries or folders that seem to be larger than they should be. depending on the size(disk) of your system, a simple thing like reports take up a lot of space. You will need to clean up old spool files and then either IPL the system or run the spool file clean up commands to free up the space the spool files used. The space a spool file uses is not made available immediately after the spool file is deleted. If you are journaling, the journals will take up a lot of space. The IFS also uses a lot of disk space. The IFS can be very difficult to analyze as you will have to drill down through the folders to see the contents. If you do not IPL regularly and you compile often, old versions of the programs are stored in QRPLOBJ. QRPLOBJ is cleared only when the system IPL's. You can clear it using CLRLIB QRPLOBJ. Also check your history logs. QHST*. These build daily and may not be deleted. If you are using the OS/400 assistant, it will schedule a daily clean up based on the parameters you define. Do a GO CLEANUP and check the settings. Set them if it is not in use. Email is another issue. If you are using the email servewr on the system, you may have rogue messages building up or a problem with 1 or more messages creating error logs. These are difficult to find. I had this problem and had to shut down my email server. Lastly, you should do a RCLSTG. You may have to change your QSYSOPR message queue to hold messages and not break. The RCLSTG runs interactively and the breaking of the message will stop the reclaim process until the message is responded to. Darryl Freinkel
    95 pointsBadges:
  • sanskritraja
    can anybody post how to check last week ASP % in our as400 server, we dont have QEZJOBLOG. plz update..
    10 pointsBadges:
  • ToddN2000
    If this is just happening over the weekend and not during the week I would check to see if any new jobs are running. Check those jobs to see if they complete normally or have to be cancelled. There may be a looping issue. I don't think there is a way to check the status of ASP% for a previous time period but I may be wrong.
    135,465 pointsBadges:
  • philpl1jb

    I doubt that you can retrieve last weeks disk info.

    For the future Create a job to run



    54,090 pointsBadges:
  • WoodEngineer
    PRTDSKINF will generate a huge report.  You can save time by prompting the command and using the MINSIZE parm to look for large objects.

    We had the same problem several years ago.  PRTDSKINF helped us find the offending object.  Yes, the culprit was a single object.

    As far as looking at prior ASP%, just run a job every night that sends the results to QSYSOPR.  That will put it in QHST for future reference.  If you create your own user message you could then scan QHST for that message ID to speed your search.

    We call QWCRSSTS to retrieve system status info.
    8,225 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: