RE: IFS Error I think..... -- MIDRANGE-L

<<Briefly, for the archives: what do they have to do?>>
Buck,
There was several responses out there reguarding this error message. So I
put the question below with the responses from the people below.... Again
Thanks To All Who Contributed

<<<Can someone explain this message, how critical is it, what causes it, and
how can I avoid it in the future?
Thanks. Dave 
Message ID . . . . . . : CPI0999 Severity . . . . . . . : 80 Message type .
. . . . : Information Date sent . . . . . . : 02/04/02 Time sent . . . . . .
: 14:43:49 Message . . . . : Storage directory threshold reached. Cause . .
. . . : The storage directory is nearing capacity. This is a potentially
serious system condition. This message will be repeated until an IPL has
been performed. Recovery . . . : The amount of storage used on the system
must be reduced. To reduce the amount of storaged used, do the following: --
Delete objects from the system that are not needed. -- Save objects that are
not needed online by specifying STG(*FREE) on the Save Object (SAVOBJ)
command. >>>
ANSWERS:
You'll get this message when you have a large number of objects on your
system; I used to get it frequently on my P02 (R.I.P.). I made it go away by
deleting objects in QRPLOBJ and in my archive libraries or by IPL'ing. I had
> 10% free space on the system so it wasn't about storage space per se. My
conclusion is that there's a directory somewhere in the system tracking
objects; the (finite) size of the directory seems to be a function of the
amount of DASD. When you run for a long period without IPL'ing, internal
objects left by OS/400 must be clogging the directory. When the directory
gets over a certain size, this message starts appearing. When you have
15,468 jobs still in the system, it's likely you're adding overhead to
various system functions. Some disk cleanup, job cleanup, and/or and IPL is
indicated... 

This indicates that the total number of objs that the system can put on disk
is approaching the max number. example: (I don't know the real numbers) Lets
say the system can have 100,000 objects on the system, you have say 95,000
or some other high number. When you hit 100,000 it's like running out of
disk. Again I don't know the real numbers this is just a example. I would
run a RCLSTG and see what you get. 

I searched the archives for CPI0999 and got quite a few hits around the end
of August, first of September. And the subject line was CPI0999 even. Many
hints were given to run a RCLSPLSTG with *NONE

>From the 'What's New for OS/400 and SAP R/3 Redbook': "Run the STRDSKRGZ
command if you are receiving the system message CPI0999 

I think part of the was that this appears to be a temporary situation. You
might be able to look back through your history logs to find the first
occurrence of the message and review what jobs were running at the time.
IIRC, this particular message (CPI0999) is going to be resent at regular
intervals until your next IPL regardless of whether the situation has been
corrected. Because DSPSYSSTS showed such a wide difference between 'Maximum
unprotected' and 'Current unprotected', it does look as if the problem was
temporary. Some job was running that created a large number of objects or
some very large compound objects and triggered the message. The job ended;
the objects were temporary and were deleted; but the message is
automatically re-sent simply because "that's the way it works". It's WAD. 

This is from an old V3R2 APAR.
On newer releases, check out the STRDSKRGZ command.: Users who create large
numbers of Byte Stream Files (Bsf's: all OS/400 object type *STMF and some
*DOC objects) may experience DASD fragmentation problems on their AS/400
systems, depending on the number of files created, the nature of change to
those files, and the file sizes. "DASD fragmentation" occurs when only
small, scattered pieces of disk storage remain available for new usage, even
though overall DASD utilization may not be approaching 100%. Although AS/400
storage management can combine smaller pieces to appear like larger ones up
to a point, DASD fragmentation can have a significant impact on system
performance; beyond this, a totally fragmented system will not IPL. A
CPI0999 message is issued to the QSYSOPR message queue when system
fragmentation reaches a point of significant concern. In general, action
should be taken when this message is received to reduce fragmentation that
has already occurred. An IPL de-fragmentation utility is available for this
purpose; see Licensed Internal Code PTF MF12857 for more information
regarding the de-fragmentation utility. In addition, this PTF is recommended
for all users of Bsf's to reduce the likelihood of DASD fragmentation
occurring due to Bsf usage. Those considering this PTF should read this
cover letter in its entirety and understand the changes being introduced
prior to applying the PTF. Byte Stream Files associated with this change can
be created in the following means: o QDLS - Some Document Library Objects
(DLO's) also have an associated Bsf (object type *DOC). For instance, each
DLO accessed from a PC via Client Access/400 has an associated Bsf. o Client
Access/400 and File Serving - PC files are stored as Bsf's on AS/400 server
systems. Objects in Shared folders are stored as Bsf's on the AS/400. o
UNIX-like APIs- Application Program Interfaces exist that create Bsf's as
*STMF objects. o Optical - The Optical file system uses Bsf's. o LAN
Server/400- Each Network Server Storage Space uses two Bsf's. This is not
expected to be of any significant impact to the fragmentation problem,
except for users who create and destroy Network Server Storage Spaces
repeatedly and often.
---------------------------------------------------------------- The number
of bytes of storage for each *STMF Byte Stream File can be determined as
follows: 1) Enter the Work with Object Links (WRKLNK) command on an AS/400
command line, identifying the path to the Bsf of interest 2) Select option
8, "Display Attributes" next to the Bsf 3) Page down to the second panel of
attributes 4) The "Allocated Size of Object" value provides the number of
bytes associated with the Bsf
---------------------------------------------------------------- This PTF
introduces changes to how storage is managed for Byte Stream Files being
created, enlarged and truncated. In general, additional storage may be used
for each Bsf. Managing the storage in large blocks reduces DASD
fragmentation. For storage-constrained systems, these changes may have the
following net impacts: o Users with many small Bsf's may be affected by a
minimum size change from 1024 to 2048 bytes. o Each Bsf less than 32,768
bytes in size could be roughly 500 bytes to 16,000 bytes larger than prior
to this PTF, depending on Bsf size. o Each Bsf between 32,768 bytes and
525,000 bytes in size could be up to 36,864 bytes larger than before this
PTF, depending on Bsf size. o Each Bsf between 525,000 bytes and 2 gigabytes
in size could be up to 103,768 bytes larger than before this PTF, depending
on Bsf size. For those with need of specific details, the following changes
will occur: 1) New Bsf's will be created with a minimum size of 2048. The
minimum size was previously 1024 bytes for an empty file and 1536 bytes for
a file containing less than 512 bytes of data. 2) All new Bsf sizes will be
in 32,768-byte increments, except for Bsf's less than 32,768 bytes in size.
These small Bsf's can be 2048, 4096, 8192 or 16,384 bytes in size. Bsf's
created prior to this PTF being applied will be modified only as they are
changed by the user, copied, or saved and restored. Previously, all sizes
were rounded to 512-byte boundaries, which minimized storage consumption,
but maximized fragmentation. 3) Small additional amounts of storage will be
added on larger Bsf's. For Bsf's between 65,000 and 525,000 bytes in size,
this will be no more than 4096 bytes. For larger Bsf's, this difference will
be no more than 71,000 bytes. 


Steven Segars
AS/400 Certified Specialist/Administrator
CSX Technology
Work: 904-633-5650
Fax:   904 633-1051