Multiple runs in the background.

[Greg Kamer]

> This may seem trivial to you UNIX gurus, but as I'm fairly new
> to UNIX please bare with me.  
>  
> What follows is a section from a DCL file which assigns fortran
> I/O units to logical names.  I realise you can do something similar
> using the "setenv FORxxx CUO_Cxxx.DAT" on UNIX.  What I'd like to
> do is set up a procedure which will prompt the user to supply the
> name of a data file, use this name for all output, and then
> submit the fortran program to run in the background of an Ultrix
> system.

> I'd like to do multiple runs using various data files.  Would it be
> simpler to write: (1) a "makefile", (2) a fortran subroutine, or
> (3) a "C" program, and pass the name to my main routine written
> in fortran? 

> DCL procedure ...

> 	$ ! ***************************************************
> 	$ ! CUO_C
> 	$ ! ***************************************************
> 	$ ASSIGN/USER [DILLON.SCRATCH]CUO_C01.JNK FOR001
> 	$ ASSIGN/USER [DILLON.SCRATCH]CUO_C08.JNK FOR008
> 	$ ASSIGN/USER [DILLON.DATA]CUO_C.CON FOR022
> 	$ ASSIGN/USER [DILLON.DATA]CUO_C.OPT FOR021
> 	$ ASSIGN/USER [DILLON.DATA]CUO_C.DAT FOR005
> 	$ ASSIGN/USER [DILLON.OUT]CUO_C.OUT FOR006  
>                                       |          \
>                                       |           \
>                                       |            \
>                                 logical name    I/O unit

There is a better way to do this using absolutely standard fortran 77 and
not having to write any DCL on VMS or scripts on Unix. Its called the
OPEN statement. It works well on every system I have ever worked on
(VMS, VSOS and Unix) for all files except std input and output. (There
are a few system specific peculiarities about how std input and output
are handled which make it hard to make it quite as general.

(What follows is a "canned" answer I pass on to anyone who brings this up...)

Its real simple. You make the names of the files you want to work with
the 1st part of the input from std input (unit 5). The you use open
to open the desired files. The example also shows how to open a couple
of internally used scratch files, which will automatically be made
unique by every operating system I've ever used.
e.g. -

      program sample
*      - max file length for the operating system
      parameter (maxflen = 32) 
      character*(maxflen) datin,datout
      logical batch

*      - do anything you need to do to open std input and output.
*      - I work on 3 different operating systems (VMS,Unix and Cyber 205 VSOS)
*	 but I made the calling sequence the same for all of 'em.
*        The internals are a bit operating system specific, but they
*	 do the same thing. arg 1 = unit for std input, arg 2 = unit for
*	 std output, arg 3 is a return of type logical that tells you
*	 whether you are running in batch or interactive.
*      - i stick the opensio (mnemonic for OPEN Standard IO) in a centralized
*	 libarary on whatever computer I am working with.
      call opensio (5, 6, batch)
      if (batch) then
	 read (5, '(a)') datin
	 print *,' Input atomic coords on file = ',datin
	 read (5, '(a)') datout
	 print *,' Output atomic coords on file = ',datout
      else
	 print *,' Name of Input atomic coord file ? '
	 read (5, '(a)') datin
	 print *,' Name of atomic coord file ? '
	 read (5, '(a)') datout
      endif
      open (20, file=datin, status='old', form='unformatted')
      open (21, file=datout, status='new', form='unformatted')
*      - open a couple of scratch units
      open (22, status='scratch', form='unformatted')
      open (23, status='scratch', form='formatted')
      
*      - do whatever it is the program needs to do...

      close (20)
      close (21)
      close (22)
      close (23)

      stop
      end

The advantage of this technique should be obvious if you have to run
programs on several operating systems. You don't have to write any
DCl or script language except for a few rudiments to deal with std input
and output redirection, if required. All input to the program is part
of a simple text file- no DCL or script language to confuse new users.
e.g.-
given that file user.dat looks like (on Unix)
/usr/kamer/Atomruns/atomin.dat
/usr/kamer/Atomruns/atomout.dat
(rest of user input to the program)

or (on VMS)
[KAMER.ATOMRUNS]ATOMIN.DAT
[KAMER.ATOMRUNS]ATOMOUT.DAT
(rest of user input to the program...)

you can use something like (Unix)
atomprog < run1.input > run1.output &

$ ASSIGN/USER [KAMER.ATOMRUNS]RUN1.DAT FOR005
$ ASSIGN/USER [KAMER.ATOMRUNS]RUN1.OUT FOR006  
RUN ATOMPROG

There are, of course, fancier input/output redirections which can be
used (when running interactively on Unix it is often handy to tee the
std output to a file so that you have a permanent copy) but the real
advantage is that -
a) you minimize the amount of DCL and script you have to write.
    (we do only interactive work on our VMS system, and
    for that, the ASSIGN's are not needed. In fact, no DCL at all is
    needed...).
b) even more importantly- in a "mixed" shop such as ours where we run
   on several operating systems, it cuts the learning curve for new
   users to a minimum. All programs read the names of the files that
   they have to deal with from std input; the amount of DCL/VSOS JCL/script
   that the user has to learn is cut to an absolute minimum.
   This is the real beauty of the setup. I have been working on VMS
   for about 3 years, VSOS for about 6 and Unix for about 10 years.
   To this day I would have to find a document for Unix shell that
   tells me how to assign files to units in script - I simply have
   never had a need to do it. The same also holds true for VMS, with
   the occasional exception of std input and output. VSOS is another
   matter- there is a bit of jcl required to attach the files (the
   old local .vs. batch file environment problem).
c) last but not least, the only thing I have to do to port the programs
   is to change the value of the maximum file length parameter to
   port the programs. Since there is no DCL/script associated with
   running the program, all I have to do is move the program, data
   files and user input file to another operating system, change
   the names of the files in the user input stream to match the
   conventions of operating system, and I'm off and running.

Hope this helps....now if the Fortran 88 standard would only some into
reality and I could forget about changing crap like
integer*2,real*2 and real*4 to integer, half precision and real
when I port things to/from UNIX / Cyber 205 VSOS...


-- 
Greg Kamer
Purdue Macromolecular Crystallography Computer Specialist