Programming for performance is a vast topic that has many points of view as to what is right and what is not. One little-considered area is "seek time"--the time it takes for the iSeries or AS/400 to physically locate and retrieve the requested data. One generality is that the more stuff you have to seek through, the longer the seek will take. The corollary is the greater the percentage of free space, the better the performance. Fortunately, there are many things you can do, large and small, to free up space on your hard drives.
Let's start with the big and difficult:
Reclaim Storage (RCLSTG)--This has several disadvantages:
- A dedicated system is required--nothing else can run.
- The job may take several hours.
- The overall result may be nothing.
On the other hand, RCLSTG may uncover some very serious problems. If you have a bad area on disk, RCLSTG will attempt to recover the data and place the data in a new area. RCLSTG will identify orphaned objects that are not a part of any library. If you are having problems, RCLSTG can free up a significant amount of disk space. It is advisable to run RCLSTG once a month, even if it means kicking the users off the system. You might be surprised by what you find.
Reorganize Files (RGZPFM)--This command is especially effective when using the KEYFILE(*FILE) parameter on indexed physical files. The space for all deleted records in the file will be purged, and the data in the file will be physically arranged in key sequence. The larger the file, the greater the benefit. The greater the volatility, the greater the benefit. I have heard arguments against reorganizing because files were very large and constantly in use. I don't care. It's like going into battle with a rusty gun. You know the gun needs cleaning, but you're using it so much you won't take the time to clean it...until it backfires! Not taking the time to reorganize your data is the AS/400 equivalent of the rusty gun. One day, your performance will backfire.
Regenerate Journal Receivers (CHGJRN *GEN)--Even if you are not using journals, many system programs do. Use the DSPOBJD ALL/ALL *JRNRCV command to see the size of existing journal receivers. These can be huge! Generating a new receiver for the journal and then deleting the old receiver can save a significant amount of space.
Now for the little piddly stuff:
Work with Alerts (WRKALR)--Alerts can be important. However, most of the time they are not and can be deleted. Use the WRKALR command to display your alerts and determine what can be removed.
Work with Problems (WRKPRB)--If you are not using ECS or the service director, problem records may not have any meaning for you. The system will allow you to delete any problem records over a month old. You may want to play with the system value that controls this default time period.
Clear Message Queues (CLRMSGQ)--Message queues can accumulate a ton and a half of messages. Periodic cleansing can cut the accumulation. Certain system message queues are more prone to message clutter than others. These include QSYSOPR, QPGMR, QTCP, QSRV, QSECOFR, and others.
Delete old system logs--This can be accomplished by typing WRKOBJ QSYS/QHST* *FILE and pressing Enter. All but the last entry may be deleted. The size of the system log is controlled by a system value.
Delete spool files--When a determination is made as to which spool files are safe to delete, then they should be deleted via WRKSPLF *ALL. The occasional system dump can occupy an awfully large amount of space. Run RCLSPLSTG *NONE afterward to reclaim the space that the spool files were using.
These are just some of the things that you can do to free disk space. You can automate many of these tasks by going to the assistance menu (GO ASSIST) and selecting the clean-up options. Other tasks are only pertinent to the individual shop. What may be a regular garbage cleanup program in one shop could be a disaster of deleted valuable objects in another. Some shops place a great deal of info on the IFS, while other shops hardly touch the IFS. The best judge of pertinence versus irrelevance is likely the one who is most familiar with the system. On that note, I'm gonna find my own space.
--David Abramowitz is an independent consultant. He may be reached at
More than ever, there is a demand for IT to deliver innovation. Your IBM i has been an essential part of your business operations for years. However, your organization may struggle to maintain the current system and implement new projects. The thousands of customers we've worked with and surveyed state that expectations regarding the digital footprint and vision of the company are not aligned with the current IT environment.
TRY the one package that solves all your document design and printing challenges on all your platforms. Produce bar code labels, electronic forms, ad hoc reports, and RFID tags – without programming! MarkMagic is the only document design and print solution that combines report writing, WYSIWYG label and forms design, and conditional printing in one integrated product. Make sure your data survives when catastrophe hits. Request your trial now! Request Now.
Forms of ransomware has been around for over 30 years, and with more and more organizations suffering attacks each year, it continues to endure. What has made ransomware such a durable threat and what is the best way to combat it? In order to prevent ransomware, organizations must first understand how it works.
Disaster protection is vital to every business. Yet, it often consists of patched together procedures that are prone to error. From automatic backups to data encryption to media management, Robot automates the routine (yet often complex) tasks of iSeries backup and recovery, saving you time and money and making the process safer and more reliable. Automate your backups with the Robot Backup and Recovery Solution. Key features include:
Business users want new applications now. Market and regulatory pressures require faster application updates and delivery into production. Your IBM i developers may be approaching retirement, and you see no sure way to fill their positions with experienced developers. In addition, you may be caught between maintaining your existing applications and the uncertainty of moving to something new.
IT managers hoping to find new IBM i talent are discovering that the pool of experienced RPG programmers and operators or administrators with intimate knowledge of the operating system and the applications that run on it is small. This begs the question: How will you manage the platform that supports such a big part of your business? This guide offers strategies and software suggestions to help you plan IT staffing and resources and smooth the transition after your AS/400 talent retires. Read on to learn:
LATEST COMMENTS
MC Press Online