If /tmp is on HFS, then use confighfs to expand it, like: confighfs -x 10C /tmp
to add 10Cylinders to /tmp on the current volume confighfs -xn 10C /tmp to add 10Cylinders to /tmp on a new volume (HFS in this case must be SMS managed!) http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/BPXZA590/SHCMDDES.CONFIGHFS.1 If /tmp is zFS, then use zfsadmim zfsadmin grow -aggregate dsn.containing.tmp.filesystem -size new.max.size.in.k http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/FCXD5A80/ZFSADMGROW If /tmp is TFS, you are in deep doo and I don't know how to help. === Why can't you find the file causing the problem? This is a common problem in UNIX. Without going into detail which I'm not qualified to explain, it is possible to "delete" (unlink() or rm) a file which is currently open in a process. This removes the directory entry, but does not release the space! In fact, the file can continue to grow. The space will be released with the last process which has it open does a close on it. You can see this by running a shell script similar to the following. #!/bin/sh cd /tmp2 #/tmp2 is on its own filesystem! exec 3>some.file #open fd3 to some.file rm some.file #remove the directory entry while true;do #forever ls -l / >>&3 #add onto what was some.file ls -l df . sleep 1s done This script will run until you interrupt it. On each iteration the amount of space in /tmp2 will decrease. But you will never see "some.file" listed. As soon as you interrupt the script, do a "df ." and you will see all the space in /tmp2 come back. That's because interrupting the script closes the inode which is then deleted and its space freed. Many utilities to this type of thing to have file work area without worrying about something else being able to mess with it. Most weird to us z/OS types. -- John McKown Systems Engineer IV IT Administrative Services Group HealthMarkets(r) 9151 Boulevard 26 * N. Richland Hills * TX 76010 (817) 255-3225 phone * john.mck...@healthmarkets.com * www.HealthMarkets.com Confidentiality Notice: This e-mail message may contain confidential or proprietary information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. HealthMarkets(r) is the brand name for products underwritten and issued by the insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance Company(r), Mid-West National Life Insurance Company of TennesseeSM and The MEGA Life and Health Insurance Company.SM > -----Original Message----- > From: IBM Mainframe Discussion List > [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Adams, Tracy > Sent: Friday, January 21, 2011 7:34 AM > To: IBM-MAIN@bama.ua.edu > Subject: /tmp space is full > > > First of let me apologize for my OMVS ignorance. Other than > using the basic set it and forget it parameters of OMVS we > have never had to touch it. Now we are developing an app > that may keep the mainframe around a long time that provides > and consumes Web Services. > > Long story short, my /tmp file is full and I cant figure out > what is taking the space. Using the LS command there are > only about 5 files in there and they are smal 30-50 blocks(?) > apiece of the 28000 that are allocated. The syslog file is > there also but when I cat that there only is a hand full of > records in there. Other than that I see nothing. A. How do > tell what is allocated that space and/or 2 how can I make > /tmp larger on the fly? > > TIA, > > Tracy > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO > Search the archives at http://bama.ua.edu/archives/ibm-main.html > > ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
