home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #18 / NN_1992_18.iso / spool / comp / lang / fortran / 3115 < prev    next >
Encoding:
Text File  |  1992-08-22  |  2.8 KB  |  79 lines
  1. Newsgroups: comp.lang.fortran
  2. Path: sparky!uunet!cs.utexas.edu!hermes.chpc.utexas.edu!aswx266
  3. From: aswx266@chpc.utexas.edu (Michael Lemke)
  4. Subject: Re: programming style question
  5. Message-ID: <1992Aug22.205756.21870@chpc.utexas.edu>
  6. Organization: The University of Texas System - CHPC
  7. References: <1992Aug13.081049.4648@newssrv.edvz.univie.ac.at> <1992Aug14.002538.3929@monu6.cc.monash.edu.au> <1992Aug21.184751.9673@draco.macsch.com>
  8. Date: Sat, 22 Aug 92 20:57:56 GMT
  9. Lines: 68
  10.  
  11. In article <1992Aug21.184751.9673@draco.macsch.com> drd@macsch.com (Daniel R. Dawson) writes:
  12. >>pm@katz.cc.univie.ac.at (Peter Marksteiner) writes:
  13. >>>ecmtwhk@ccu1.aukuni.ac.nz (Thomas Koenig) writes: 
  14. >>>
  15. >>>>It's a real shame that Unix does not have standard way of attatching
  16. >>>>FORTRAN units to file descriptors, that would make things much easier.
  17. >>>>Does POSIX have anything to say about that?
  18. >>>
  19. >>>Try symbolic links. For example,
  20. >>>
  21. >>>    ln -s /whatever/pathname/you/want fort.3
  22. >>>
  23. >>>may not be as beautiful as
  24. >>>
  25. >>>//FT03F001  DD  DSN=REVOLTING.MVS.DATASET,DISP=NEW
  26. >>>
  27. >>>but it works almost as well. 
  28. >>
  29. >>Unfortunately `almost' is important here.  One of the nice features of
  30. >>VMS (gargle) was the ability to use:
  31. >>
  32. >>$ define/user_mode 'P1'.dat for005
  33. >>$ define/user_mode 'P1'.out for006
  34. >>$ run myprog
  35. >>
  36. >>in a command procedure.  The advantage here is that you can have that
  37. >>program running on at least two different sets of data in the same directory
  38. >>at the same time.  The only way you can do this with symbolic links is to 
  39. >>place the data files in different directories.  A royal pain if you are 
  40. >>doing a lot of batch processing, which I suspect applies to most serious 
  41. >>FORTRAN users.  A very bad design decision from a supposedly flexible 
  42. >>operating system.
  43. >>
  44. >>I, and probably many others, get around the problem by passing the 
  45. >>argument (P1, above) into the program using getarg, doing some string
  46. >>handling to create the file names and using open explicitly.  Messy.
  47. >>
  48. >
  49. >Forget about using links, man!
  50. >
  51. >Here's how I'd handle this problem for Unix boxes:
  52. >
  53. >(C-Shell script fragment similar to the DCL script fragment above)
  54. >setenv FOR005 ${1}.dat
  55. >setenv FOR006 ${1}.out
  56. >myprog
  57. >unsetenv FOR005
  58. >unsetenv FOR006
  59. >
  60. >Then, in the Fortran, just use getenv() to get the filenames
  61. >for the open statements.
  62. >
  63. >Easy as pie!
  64.  
  65. Except it is no standard Fortran anymore.  And it won't run on VMS 
  66. anymore either.  Of course you can conconct a getenv function but that 
  67. would have to be changed for the IBM again (can it be done?).
  68.  
  69. But the actual solution for this particular problem is terribly easy in 
  70. Unix:
  71.  
  72. myprog <${1}.dat >${2}.out
  73.  
  74. or whatever variables you want to use.
  75. -- 
  76. Michael Lemke
  77. Astronomy, UT Austin, Texas
  78. (michael@io.as.utexas.edu or UTSPAN::UTADNX::IO::MICHAEL [SPAN])
  79.