am trying to find out on behalf of a network user in our group who runs sas jobs on a 
unix server (solaris, /bin/csh shell)

apparently the connection is via a SSH terminal and the jobs are submitted in the 
format
<command> <filename>

ie. sas job1.sas

the jobs write no output to the users home folder or any other location, all dataset 
references are in the format work.tempNN

ie. proc sql; create table work.temp1 as .....

or data temp1; set temp0;

at the end of the job, all output is written directly via ftp to a mainframe location

ok, now the question:

why would the user have only a couple megabytes of files in the home folder, yet the 
system vxquota reports

Disk quotas for xxxxx (uid 1234):
Filesystem     usage         quota      limit     timeleft  files  quota  limit 
timeleft
/xx/home     2147483647 200000 250000                  -1      0      0

we don't know where that massive storage exists and the sas job itself does not create 
anything permanent.

Hi

This is a question best asked your SAS Admin or if you're the SAS
Admin then ask SAS Tech Support.

I assume that <command> <filename>  means <command> is a shell script
and <filename> is a text file containing sas script.

There will be a SAS log. The location of this log is either defined in
this <command> script or is the default location as defined as part of
the installation (and documented in the SAS installation manual).

There are also SAS Server logs. Your SAS Admin should know where they
are.

I've worked in an environment as you describe it but nothing got
stored in the $HOME directory unless someone scripted it. But who
knows - may be someone points the SAS Work directory to $HOME. SAS
work tables would then be stored there while the SAS batch job runs
and be destroyed at the end of the job.

HTH
Patrick

....and what I forgot: Most likely the command will be:    nohup
<command> <filename> &

There will be a nohup.out in the directory where the user started the
script from which also might give some information.

Patrick wrote:
> I assume that <command> <filename>  means <command> is a shell script
> and <filename> is a text file containing sas script.

no, incorrect.

as I wrote, all jobs are executed via SSH terminal in the format
sas job1.sas

manually. nothing is running automatically. user logs on, opens a SSH terminal and 
types.

there are no scripts being used, unless the command "sas" before the filename 
(job1.sas) is a script


> There will be a SAS log. The location of this log is either defined in
> this <command> script or is the default location as defined as part of
> the installation (and documented in the SAS installation manual).

of course. sas logs show proc sql creating a work.temp1 and then a data _null_ with an 
ftp for work.temp1

all job complete normal and NOTHING is written into sas libraries (permanent) other 
than WORK

so, unless WORK is stored permanently (makes no sense!) the user does not write sas 
libraries and does not
store any work files on Unix other than the short piece of code in "job1.sas" which is 
just a text file with proc sql and
data _null_ and the file statement which send the output to a windows server (again, 
nothing is stored or written
to the unix server)

> and be destroyed at the end of the job.

that is the problem. User has only a few megabytes in files yet vxquota output shows 
several gigabytes of quota.

> There will be a nohup.out in the directory where the user started the
> script from which also might give some information.

incorrect.

the user home directory contains no such file, just looked.

thanks for the comments

Look for "hidden" file.  In Unix file names that start with period (.)
do not normally show up in the ls command output.
You can add the -a option to the ls command to see the files.
Use the du command to find out how much space your files are using.
Inside your SAS program you can get the location of the WORK directory
by using the PATHNAME function.
  %put workdir=3D%sysfunc(pathname(work));
As a last resort ask the system people for the unix machine.
Sometimes they know something about how their machines are configured.

On May 15, 1:21=A0pm, "morris" <mor...@utantjej.no> wrote:
> > There will be a nohup.out in the directory where the user started the
> > script from which also might give some information.
>
> incorrect.
>
> the user home directory contains no such file, just looked.
>
> thanks for the comments

Tom Abernathy wrote:
> You can add the -a option to the ls command to see the files.
> Use the du command to find out how much space your files are using.

both ls -a and du show just a few megabytes in total files in home and subfolder

It's a bug of vxquota.
First hit when using "system vxquota space" as search terms in Google:
http://seer.entsupport.symantec.com/docs/302586.htm

HTH
Patrick