|
Neil, thanks...hope going back to V3R2 APAR's didn't hurt too much! -----Original Message----- From: midrange-l-admin@midrange.com [mailto:midrange-l-admin@midrange.com]On Behalf Of Neil Palmer Sent: Tuesday, February 05, 2002 8:31 AM To: midrange-l@midrange.com Subject: Re: Message 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. ...Neil "Dave Snyder" <dsnyder@blcnet.com> Sent by: midrange-l-admin@midrange.com 2002-02-04 15:26 Please respond to midrange-l To: midrange-l@midrange.com cc: Subject: Message 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. _______________________________________________ This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list To post a message email: MIDRANGE-L@midrange.com To subscribe, unsubscribe, or change list options, visit: http://lists.midrange.com/cgi-bin/listinfo/midrange-l or email: MIDRANGE-L-request@midrange.com Before posting, please take a moment to review the archives at http://archive.midrange.com/midrange-l.
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.
midrange.com
