dillon@uhccux.UUCP (Ian Dillon) (05/21/88)
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 Any advice would be greatly appreciated. Mahalo in advance! Ian -- | UUCP: dillon@uhccux.UUCP | | ARPA: dillon%uhccux.uhcc.hawaii.edu@rutgers.edu | | INTERNET: dillon@uhccux.UHCC.HAWAII.EDU | | BITNET: dillon@uhccux.bitnet |
tsh@mace.cc.purdue.edu (Greg Kamer) (05/26/88)
> 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
hirchert@uxe.cso.uiuc.edu (05/29/88)
I have three quibbles about the quoted article from tsh@mace.cc.purdue.edu: 1. >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 ^^^^^^^^^^^^^^^^^^ READ(*,'(A)')VAR reads from FORTRAN standard input READ '(A)',VAR reads from FORTRAN standard input READ(5,'(A)')VAR reads from FORTRAN unit 5 There are a number of systems on which unit 5 and standard input denote the same file or device, but this connection is far from universal. 2. >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. This approach is fine for Unix (which is what the original question was about), but be warned that there are systems where either there is no fixed name for files and/or some kind of control language _must_ be executed to make files accessible through the OPEN statement. In other words, there are systems where this approach won't work as expected. 3. >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... The Fortran 8x draft released for public comment included a facility for portable specification of REAL variables but not for INTEGERs. The comments received were largely negative, so I wouldn't hold my breath waiting for it to be adopted. Extensive changes are likely to result. Generalized REAL precision is a probable casualty, but there is still a reasonable chance for it to be replaced by some simpler facility that would still allow for portable specification of REAL representation. There were comments requesting similar capabilities for INTEGERs, LOGICALs (1 bit logicals), and CHARACTERs (they need multibyte characters in Japan, China, Korea, etc.), but extension in these areas seems fairly unlikely in the current committee climate. >Greg Kamer >Purdue Macromolecular Crystallography Computer Specialist Kurt W. Hirchert hirchert@ncsa.uiuc.edu National Center for Supercomputing Applications