To clear up the filesystem, I archived /var/tmp (forgot that this directory was important for crontab), and then deleted the directory itself.
After that there were problems like crontab not accessible, certain ftp commands like mget not functioning, and worst there were some scripts which were not executable anymore.
I restored the /var/tmp, and the first two problems (crontab missing and mget not functioning) were resolved. However, the scripts remained not executable.
Is it possible that when I deleted /var/tmp, some symlinks were removed?
And therefore any of the problem scripts had some symlink from /var/tmp?
I cannot think of any other reason why there could be scripts which became not executable even after I had restored the directory.
What permissions did you set on /var/tmp when you restored it ? Speaking from my own experience on Linux and Solaris systems (and from some quick Googlings, this should apparently also be the case in recent releases of HP-UX) this is a directory that needs to have the sticky bit set, as well as being globally writeable.
In other words, it should have permissions that look like this:
$ ls -ld /var/tmp
drwxrwxrwt 25 root root 4096 Mar 3 17:22 /var/tmp
If it doesn't have permissions of 1777, then this could be the cause of your problems. Can you confirm what permissions you set on it when you re-created it ?
/var/tmp is one of the most important directories in HP-UX as used by the system... You are lucky you havent rebooted your box because there you would have known how important...
Thats years now I havent had a box around but I can tell you all the system writings go there and as drysdalk mentionned its permissions are important I cant think of scripts but links yes there are some.. so I would get a backup and have a look or restore from backup then do some cleaning up... mostly reducing the size of logs
drysdalks idea was a good one, but i think now is he time to resort to good old debugging techniques:
What exactly do you mean by that? Obviously the execute-privilege of these were not changed, no? So, how did the fail? Error messages? Log entries? Exit codes? Smoking guns?
Yes, this might be possible, but yet again the opposite is equally possible. Instead of making wild guesses, you might want to analyse the problem - see above: try something, gather evidence, analyse it, then start over.
This is the good thing about good debugging practice: you don't have to be overly creative in this regard. If a script you try to start fails with Error: failed to make the flurbishes grommicking it is quite obvious what happened.
If the script(s) you start fail to give any conclusive error message (in this case: shame on the programmers!) then look inside the scripts and search for the string "/var/tmp" to try to locate the places where it tries to access the directory in question.