Path: utzoo!mnetor!uunet!lll-winken!lll-lcc!ames!hao!gatech!purdue!i.cc.purdue.edu!j.cc.purdue.edu!tsh
From: tsh@j.cc.purdue.edu (Greg Kamer)
Newsgroups: comp.lang.fortran
Subject: Re: F8X response (long)
Message-ID: <6518@j.cc.purdue.edu>
Date: 26 Feb 88 22:30:14 GMT
References: <705@elxsi.UUCP> <44400017@hcx2> <6502@j.cc.purdue.edu> <2883@alvin.mcnc.org>
Organization: Purdue University Computing Center
Lines: 42
Summary: use of status=scratch and mktemp



>>
>>compare a "sample" script required to run three programs that pass
>>some very large temporary files.
>>
>>Unix -
>># prog1 uses as input a file called 'myin'.
>>prog1.
>># prog1 creates a temp file called 'temp1'.
>
>	Instead of explicitly naming the temporary file, the "open"
>statement which opens the file can specify "status=scratch", and Unix
>will give it a file which has the process-id as part of the file name;
>since each process has a unique pid, the program can be run as many 
>times as needed, concurrently, and all the temporary files will have 
>unique names.
>
>-ravi


Nope. Note that the process being run uses more than one program.
You can create scratch files in the 1st program using the 
  "status=scratch" option (I use it quite often) but 
  1) you can't give it a name
  2) it ceases to exist at the termination of program 1 and
     is thus not available to the 2nd program.

In a related article, someone suggested the use of mktemp to
generate unique file names. I'm not sure what type of Unix they
are running; we are running BSD4.3 and mktemp is a C utility for
which there is no f77 equivalent (try man 3f mktemp).
While it would be (and indeed was...) possible to write a C routine
that could be called from a f77 program and return such a file
name by using an indirect call to mktemp, the original mktemp
cannot be called from a f77 program, since its argument is
a pointer structure, and as we all know, you can't call any
of the C routines which pass structures as arguments from
a fortran routine. (try it- you will get an interesting core dump...)

-- 
Greg Kamer
Purdue Macromolecular Crystallography Computer Specialist