- Community Home
- >
- Servers and Operating Systems
- >
- Operating Systems
- >
- Operating System - OpenVMS
- >
- Re: vms disk help
Operating System - OpenVMS
1753830
Members
9306
Online
108806
Solutions
Forums
Categories
Company
Local Language
back
Forums
Discussions
Forums
- Data Protection and Retention
- Entry Storage Systems
- Legacy
- Midrange and Enterprise Storage
- Storage Networking
- HPE Nimble Storage
Discussions
Discussions
Discussions
Forums
Discussions
back
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
- BladeSystem Infrastructure and Application Solutions
- Appliance Servers
- Alpha Servers
- BackOffice Products
- Internet Products
- HPE 9000 and HPE e3000 Servers
- Networking
- Netservers
- Secure OS Software for Linux
- Server Management (Insight Manager 7)
- Windows Server 2003
- Operating System - Tru64 Unix
- ProLiant Deployment and Provisioning
- Linux-Based Community / Regional
- Microsoft System Center Integration
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Blogs
Information
Community
Resources
Community Language
Language
Forums
Blogs
Go to solution
Topic Options
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
06-28-2009 11:24 AM
06-28-2009 11:24 AM
Re: vms disk help
I'd really like to point out that about the worst thing to do with a filled disk is reboot,
as rebooting is very difficult. Unless the
accounting file is the culprit you can
do some emergency stuff on your system disk
to get it working.
Purge/keep=3/log sysdisk:[*...]
will let you see what's writing a lot of files to the system.
new operator log, errorlog.sys, and accountng.dat files will help. As long as they are backed up you can always go back to them or save them on another disk.
A note, if you do a
set account/new it will start a new file
BUT IT WILL INCLUDE all Image activation,
so immediately do a set account/noimage
Since these files are created a bit at a time,
they may take up 100s of retrival pointers,
and the lack of free headers could stop you in your tracks. If you want to keep the existing files, such as accountng.dat
do a copy/contiguous filename Then purge the
original. So you have some options.
You can use the convert and recreate the file
with extra space.
All the log files have this problem. I liked
to use the RMS utilities to convert them to pre-sized files with extra space. Remember that keeping all your fragmenting log, or dat
files will have all these pointers. This also means if you use the files, such as use accounting.dat or your system backs it up it requires many extra I/Os. So this has performance issues.
Then, do the dir/sel= look for big files
and get huge files that may be sitting wasting space.
My rule of thumb is keep no applications on the system disk.
Finally, over the years, even sysuaf.dat
can, like any other ISAM files get it terrible shape with internal bucket splits,
records marked deleted. Since this file is hit in every login, including batch, it's worth optimizing it.
For example
Anal/rms/fdl sysuaf.dat
The edit/fdl syauaf.fdl
and choose optimize. It will create
an FDL file for your sysuaf.dat.
Make sure you choose the option to
add additional records, and the fill factor low and it will help performance for
a much longer time.
After you optimize the fdl, then
anal/rms/fdl=sysuaf.fdl sysuaf.dat sysuaf.dat
Make sure it stays in common and you don't put a separate copy in a root directory.
I'm always willing to follow up on the phone or email on any advise I give.
Have fun
Bob Comarow
VMS Consultant.
You can do a Purge/keep=2 to get out of the emergency.
If the security journal is huge, close it,
and start a new one.
as rebooting is very difficult. Unless the
accounting file is the culprit you can
do some emergency stuff on your system disk
to get it working.
Purge/keep=3/log sysdisk:[*...]
will let you see what's writing a lot of files to the system.
new operator log, errorlog.sys, and accountng.dat files will help. As long as they are backed up you can always go back to them or save them on another disk.
A note, if you do a
set account/new it will start a new file
BUT IT WILL INCLUDE all Image activation,
so immediately do a set account/noimage
Since these files are created a bit at a time,
they may take up 100s of retrival pointers,
and the lack of free headers could stop you in your tracks. If you want to keep the existing files, such as accountng.dat
do a copy/contiguous filename Then purge the
original. So you have some options.
You can use the convert and recreate the file
with extra space.
All the log files have this problem. I liked
to use the RMS utilities to convert them to pre-sized files with extra space. Remember that keeping all your fragmenting log, or dat
files will have all these pointers. This also means if you use the files, such as use accounting.dat or your system backs it up it requires many extra I/Os. So this has performance issues.
Then, do the dir/sel= look for big files
and get huge files that may be sitting wasting space.
My rule of thumb is keep no applications on the system disk.
Finally, over the years, even sysuaf.dat
can, like any other ISAM files get it terrible shape with internal bucket splits,
records marked deleted. Since this file is hit in every login, including batch, it's worth optimizing it.
For example
Anal/rms/fdl sysuaf.dat
The edit/fdl syauaf.fdl
and choose optimize. It will create
an FDL file for your sysuaf.dat.
Make sure you choose the option to
add additional records, and the fill factor low and it will help performance for
a much longer time.
After you optimize the fdl, then
anal/rms/fdl=sysuaf.fdl sysuaf.dat sysuaf.dat
Make sure it stays in common and you don't put a separate copy in a root directory.
I'm always willing to follow up on the phone or email on any advise I give.
Have fun
Bob Comarow
VMS Consultant.
You can do a Purge/keep=2 to get out of the emergency.
If the security journal is huge, close it,
and start a new one.
- « Previous
-
- 1
- 2
- Next »
The opinions expressed above are the personal opinions of the authors, not of Hewlett Packard Enterprise. By using this site, you accept the Terms of Use and Rules of Participation.
News and Events
Support
© Copyright 2024 Hewlett Packard Enterprise Development LP