Either /tmp or any other filesystem SMIT might use: /var/tmp maybe or something such. Issue "df -k" and watch for numbers close to 100%. (Disregard /usr in this case, it is no problem if it is filled up to 95+%)
unmount /tmp and do a "fsck -y" on the filesystem and/or the logical volume (i suppose that is hd3, but i am not sure, issue "lsvg -l rootvg" to find out).
If any errormessage comes up you cannot understand post it here. Have a look in the error-log ("errpt" and "errpt -a" respectively) and watch out for "HDISK3" and/or "HDISK4" type errors. These would indicate a harddisk failure.
After fsck-ing the filesystem remount it and try if that solved the problem. If not please write the symptoms along with the output of fsck here.
Unfortunately this is a production box, and I am a new employee quite low in the scheme of things. Not at liberty to be unmounting filesystems on the fly- only tasked to load a software package and get out. Hellfire and damnation could befall me.
I have checked errpt and there are no outstanding errors with HDISK3.
This is a curious problem though- I seem to remember something like this many years ago happening, but can find nothing in my notes.
Root user not able to create any file in /tmp. One would think, these people would be having problems with their applications themselves on this server. At any rate I will report and investigate. Thanks!