WOT No Disk Space !!!!
Neil Allison
Somebody out there must be able to help me...
We are running a series 300 9406 with 12Gb of disk installed.
The disk usage is currently at 94.5% (was 98.4% yesterday but I
have archived some stuff onto tape for now) and I don't know what is
using up disk space at the current rate.
Does anybody have any ideas how I can regain some space. Even a small
amount would be a great help.
Thanks in advance
Neil Allison
Andreas Gruber
I suggest you this solution :
At first you can autom. a cleanup for the system:
go CLEANUP
with Menupoint 1 you can tune your special AS/400 cleanup.
2.) you can analyse what libraries use the diskspace
go disktask
with point 2 you can print a disk analyse. If the date of the information
is too long in the past you can get a current disk-analyse-data-base with
point 1.
(this is a long running job!!!)
I hope this helps,
andreas gruber
Michael Ozanne
In article <3211c67...@news.demon.co.uk>
ne...@chalyork.demon.co.uk "Neil Allison" writes:
*Somebody out there must be able to help me...
*We are running a series 300 9406 with 12Gb of disk installed.
*The disk usage is currently at 94.5% (was 98.4% yesterday but I
*have archived some stuff onto tape for now) and I don't know what is
*using up disk space at the current rate.
*
*Does anybody have any ideas how I can regain some space. Even a small
*amount would be a great help.
1) do a full back up
2) do an IPL
3) clear any unwanted documents from the output queues
4) See if your applications have any file purge and reorganisation
routines.
5) See if your applications have parameters set for on-line file storage
discuss setting it for a shorter period.
6) look for any large physical files, use RGZPFM to compact them
to active records only
7) there is a Compress Object command but I'm not sure how safe and secure
that is
8) look for any transient workfiles that haven't been properly closed down.
9) Run reclaim storage (RCLSTG), this may take a while.
--
Michael Ozanne
MagesGroup
Check the files in QPFRDATA and QMPGDATA. IBM automatically began
including their own performance tools to help your planning (their
marketing) that constantly collects data. Trouble is that in many cases
the data is never erased. I've seen the old performance data files grow
to 3 or 4 gig at some shops.
Also, I hope you have GO CLEANUP running to remove old files. You need to
be signed on as QSECOFR to set and run this.
Finally, do a RCLSTG (Reclaim Storage) some weekend. The system will need
to be in a restricted state and it will take many hours.
Let me know how it turns out.
Jim Berryman
Neil Allison wrote:
>
> Somebody out there must be able to help me...
>
>
>
> Neil Allison
We have a 300 with 16 gig and have the same problem.
The biggest offender I have found (here) is the system cross reference
files in QSYS (QADBFILD is 1.2 gig!). We are a software developer, and
have to maintain multiple versions of our products, so we have a lot
of redundant files in different versions on our system.
The second biggest (and fastest growing) is the files in QMPGDATA.
These files are maintained by IBM's Performance Monitor.
So if you're running PM, take a look at that library.
Also, we IPL every night to help keep our system clean.
I don't know if you are able to do that, but IPL as often as you can.
And, we run a Reclaim Storage every 3-4 months.
Don't know if this will help you, but good luck.
Jim Berryman
CSSL Beijing
Neil Allison wrote:
>
> Somebody out there must be able to help me...
> We are running a series 300 9406 with 12Gb of disk installed.
> The disk usage is currently at 94.5% (was 98.4% yesterday but I
> have archived some stuff onto tape for now) and I don't know what is
> using up disk space at the current rate.
>
> Does anybody have any ideas how I can regain some space. Even a small
> amount would be a great help.
>
> Thanks in advance
>
I think following 3 methods will be helpful:
1.Delete useless joblogs and spooled files. Make cleanup work.
2.Tell every one to remove those obsolete objects.
3.If no other objects could be deleted, delete some features of system software, such as
some features of 5763SS1 regarding S/36,S/38,online edudcation, or some features on
Client Access, for example, features for OS/2. If you are not sure about that, look at
'Sofware Installation Guide'
Stephen Liu
Senior System Engineer
css...@public.bta.net.cn
dp...@usa.pipeline.com
A couple of places to check that have not been posted yet would be QHST
files, and shared folders if you have users on PC Support or Client Access.
--
Bryan Hipp
The views expressed above ARE those of my employer, I am not allowed to
have any original thoughts of my own.
Richard D Phillips
If you are running an audit journal of your own you might want to
look at the receivers and associated files. We periodically must
remove these. You might also check any system journal items.
Nisimkain
You can also save space by running CHGPGM command on all programs for a
library and choose REMOVE observable *ALL. This will save space for each
pgm, but you will be unable to run interactive debug on any pgm,(until you
re-compiled the program). If that is not a concern this will save space.
Did some mention about checking the PTF's if they are permannet or not?
Carl Sherwin.
Petemass
Carl wote:
First make sure that you have the source for all the programs that you
want to remove observability for. This is risky, and I would only do it
as a last resort. Although, you will get lots of room back.
Pete Massiello
Information Solutions & Software, Inc.
Voice: 203-744-7854
Fax: 203-790-6056
Emai: PETE...@AOL.COM
Orangtang
There are a number of things to look at....Check qhst files in lib. QSYS.
Each day, 3-5 files are created. If you don't have your CLEANUP option
set to automatically delete them you must delete them yourself. You
really only need 1-2 weeks worth. You may want to save them to tape before
deleting....Just in case.. Also, check deleted records in your physical
files...You may need to do some reorgs (RGZPFM). If you are running the
Performance Monitor, check the performance data in QPFRDATA. You should
be deleting this data after a certain period of time. Also, the problem
log needs to be cleaned out. GO PROBLEM. The system keeps messages in a
problem log. These also need to be periodically deleted. There is also a
library that keeps a copy of every object that was replaced. I think it's
called QRPL..somthing like that. Check to see how old the oldest obj. is
in this lib. This lib. also needs to be cleared out periodically. Check
your "re-use space for deleted spool files" system value. Also, you
should be IPLing at least once a week. This helps free up DASD and
Reclaim Storage, RCLSTG could also help free up DASD. Many of these clean
up procedures can be automated using the cleanup facility..GO
CLEANUP...Let me know if any of this helps..Ron
Cybe...@ewib.com.ru
One more thing not mentioned here. If you have your security auditing
enabled check the QAUDJRNRCV journal receiver.
Last time I did it the size of it was about 2GB! Hope this helps.
Ilya.
CRAIG A. HIRST
In article <3213A4...@public.bta.net.cn>, CSSL Beijing
<css...@public.bta.net.cn> writes
-- hello , how often does you system power down ?. if you don't do this the
house keeping jobs do not run.
also try looking at the qhst files they can build up and fill your system
up.also look at you problem file
CRAIG A. HIRST
MP
> In article <3213A4...@public.bta.net.cn>, CSSL Beijing
> <css...@public.bta.net.cn> writes
> >Neil Allison wrote:
> >>
> >> Somebody out there must be able to help me...
> >> We are running a series 300 9406 with 12Gb of disk installed.
> >> The disk usage is currently at 94.5% (was 98.4% yesterday but I
> >> have archived some stuff onto tape for now) and I don't know what is
> >> using up disk space at the current rate.
> >>
> >> Does anybody have any ideas how I can regain some space. Even a small
> >> amount would be a great help.
> >>
> >> Thanks in advance
> >>
> >> Neil AllisonHi....
> >
1. Use the command GO DISKTASKS to access the menu which will enable you to
obtain a breakdown of objects on your system in size order.
NB: This may take several hours to run.
You can then use the output to identify the offendingly large objects.
2. Permanently applying any temporarily applied PTF's will regain some disk space.
3. Use GO LICPGM to ascertain if there are any unrequired dictionaries which have
been installed. These could be removed. NB: Be careful which LICPGM's you delete.
--
MP @ Comp Dev Dept
http://users.colloquium.co.uk/~WALK_GEO/whome.htm
mailto:WALK...@cqm.co.uk
Kennet Bjarnung
If You are planning to upgrade to RISC in the future - DO NOT REMOVE
observable *ALL!!! You got a lot of work to restore it.
Kennet
Ian Stewart
Nisimkain wrote:
> You can also save space by running CHGPGM command on all programs for a
> library and choose REMOVE observable *ALL. This will save space for each
> pgm, but you will be unable to run interactive debug on any pgm,(until you
> re-compiled the program). If that is not a concern this will save space.
> Did some mention about checking the PTF's if they are permannet or not?
> Carl Sherwin.
No! NO! NO!!
You don't want to do this until you've had a long, hard
think about the implications. That stuff is there for a
reason. You will probably cause yourself problems with
having to recompile programs on some later upgrade, as the
system will not be able to regenerate the executable from
the embedded information (seeing you removed it).
If THAT isn't a concern to you, or if the benefits outweigh
the cost, then proceed ...
I think, from memory, that the original poster was more
concerned at the problem (some system function gobbling disk
like it was going out of fashion) in any case. The solution
(if any) is to find out what it is and stop it! Unless you
have a rapidly growing amount of object code, the space taken
by it will be pretty stable, and won't be contributing to the
growth ...
----------------------------------------
Ian Stewart i...@jigsaw.southern.co.nz
Njal Fisketjon (Njål Fisketjøn)
- Delete old history logs QSYS/QHST*
- If using office, use the DLTOUTMAIL command, and tell users to
delete their old mail. Mail to all (or many) users is kept on the
system until all recipients have deleted the mail from their "in-box"
- Display library QDOC and see if it's big. If it is, users may be
copying a lot of files to their personal folder from their PC's.
- Delete unneeded spool files, and use the RCLSPLSTG command.
- Run RCLSTG and delete unneeded objects placed in library QRCL.
- Use the compress object command (CPROBJ if I remember correctly) to
compress program objects used infrequently
- Reorganize physical files with lots of deleted records
Njal Fisketjon
FIGU DATA AS
nfis...@figu.no
nox...@ibmmail.com
Njal Fisketjon (Njål Fisketjøn)
<Cybe...@ewib.com.ru> wrote:
This reminds me of:
Accounting journals if job accounting is activated.
Journal receivers; if any. Use CHGJRN with *GEN and (save and) delete
the old receiver if not needed by your application.
Njal Fisketjon
FIGU DATA AS
Njål Fisketjøn
FIGU DATA AS
nfis...@figu.no
Bob Carl
'Use 'Delete Licensed Programs' for items not used.
When did you last run a RECLAIM STORAGE and RECLAIM TEMPORARY STORAGE?
See the manuals for more details.
--
Bob Carl@US_EDS_DSD @ EDSHUB
Using the Magic of OS2 WARP
Dan Riehl
>Nisimkain wrote:
>
>> You can also save space by running CHGPGM command on all programs for a
>> library and choose REMOVE observable *ALL. This will save space for each
>> pgm, but you will be unable to run interactive debug on any pgm,(until you
>> re-compiled the program). If that is not a concern this will save space.
On Fri, 23 Aug 1996 14:56:15 +1200, Ian Stewart
<i...@jigsaw.southern.co.nz> wrote:
READ ON..... IAN IS EXACTLY CORRECT!
>No! NO! NO!!
>
>You don't want to do this until you've had a long, hard
>think about the implications. That stuff is there for a
>reason. You will probably cause yourself problems with
>having to recompile programs on some later upgrade, as the
>system will not be able to regenerate the executable from
>the embedded information (seeing you removed it).
>
>If THAT isn't a concern to you, or if the benefits outweigh
>the cost, then proceed ...
Just one more addition to IAN's post..... DON'T YOU DO IT IF YOU EVER
WANT TO UPGRADE TO A NEW RELEASE OF OS/400!!!!!!!!!
>----------------------------------------
>Ian Stewart i...@jigsaw.southern.co.nz
__________________________________________
Dan Riehl
Seattle, Wa
dri...@toolnet.com
http://www.toolnet.com
Tim Laswell
ne...@chalyork.demon.co.uk (Neil Allison) wrote:
>Somebody out there must be able to help me...
>We are running a series 300 9406 with 12Gb of disk installed.
>The disk usage is currently at 94.5% (was 98.4% yesterday but I
>have archived some stuff onto tape for now) and I don't know what is
>using up disk space at the current rate.
We experienced the same problem. We attributied it to starting to use
the BPCS Order Entry module. Come to find out that was sort of the
problem. It seems that most BPCS Physical Files are set at
REUSEDLT(*NO) which means deleted records still take up space. One
file in paticular belonged to a little known XM4 add-on module we
purched for BPCS. This file was giving us "Record not added, file is
full" messages. The systems analyst just kept bumping up the file
size. When I started investigating I foun that the file had
1,300,000+ records with 1,200,000 deleted records. One simple RGZPFM
released 5% of our storage. Further investigation by doing a DSPFD
BPCSF/*all OUTFILE(QTEMP/CHKFIL) then a RUNQRY RCDSLT(*YES) found a
few more BPCS files with more than 100 deleted records. A xxxDSKINF
command showed us another file of our own we forgot about that was
taking up 2% of disk space hadn't been reorganized lately.
Tim in Coumbia MD
James A. Easterday
Ian Stewart <i...@jigsaw.southern.co.nz> wrote:
>Nisimkain wrote:
>> You can also save space by running CHGPGM command on all programs for a
>> library and choose REMOVE observable *ALL. This will save space for each
>> pgm, but you will be unable to run interactive debug on any pgm,(until you
>> re-compiled the program). If that is not a concern this will save space.
>> Did some mention about checking the PTF's if they are permannet or not?
>> Carl Sherwin.
>No! NO! NO!!
>You don't want to do this until you've had a long, hard
>think about the implications. That stuff is there for a
>reason. You will probably cause yourself problems with
>having to recompile programs on some later upgrade, as the
>system will not be able to regenerate the executable from
>the embedded information (seeing you removed it).
^^^^^^^^^^^^^^^^^^^^^^^^^^^^that right there is it in a nutshell, but
don't forget that it will also prevent you from getting a formated
dump if a program crashes...
>If THAT isn't a concern to you, or if the benefits outweigh
>the cost, then proceed ...
>I think, from memory, that the original poster was more