home *** CD-ROM | disk | FTP | other *** search
/ C/C++ Interactive Guide / c-cplusplus-interactive-guide.iso / c_ref / csource4 / 216_01 / c_user.txt < prev    next >
Text File  |  1979-12-31  |  7KB  |  133 lines
  1.                                                  July 15, 1986
  2. Donna S. Ward
  3. Operations Manager
  4. C Users Group
  5. P.O. Box 97
  6. McPherson, Kansas  67460
  7.  
  8. Dear Ms Ward,
  9.  
  10.      Ref your letter of June 23, you are welcome to the code, and may publish
  11. it if you wish. If Mr Apsey is a Fortranner, he should have no difficulty
  12. adapting it to his needs. I'm sorry its in Fortran, and would like to convert
  13. it to C, but it will be Christmas before I have a spare day. I hope another
  14. of your readers will volunteer to translate it to C, if found worthy.
  15.  
  16.      The software is in two pieces, a batch file and the Fortran program. In
  17. this application, I think the batch file plays a more than usually important
  18. role. It does more than most of my batch files.
  19.  
  20.      The batch file, which is baptized CLL.BAT copies files to RAM disk and
  21. invokes dBase. When dBase is quit, CLL saves any newly created or updated
  22. files. I haven't tried, but I expect this could be made to work with any
  23. other language, or no language - not just dBase. One of the commands in CLL
  24. is "scanfils", which calls up the Fortran routine, SCANFILS.
  25.  
  26.      Fortran routine SCANFILS checks the latest directory to see what files
  27. have been created, or altered, and builds the batch file SAVEFILS, containing
  28. copy commands, which CLL uses to save the necessary files.
  29.  
  30.      The first statement in CLL.BAT;
  31.           if exist c:mims.prg goto dbase2
  32. makes it possible to work in RAM for a while, then quit dBase. All changed
  33. files will be saved. You can later go back to work on the files without
  34. re-copying everything back to RAM again.
  35.  
  36.      After saving a copy of the directory, dBase is called up, followed by
  37. MIMS (a root menu type of program). The programs and data files comprise a
  38. a small system which contains file update screens, prints mailing labels,
  39. member phone directory and file listing. When dBase is quit, another copy
  40. of the directory is taken, and the program SCANFILS checks for new or changed
  41. files.
  42.  
  43.      SAVEFILS is a batch file created by SCANFILS, and contains the names of
  44. new or changed files in the format;
  45.           copy e:filename.ext b:.
  46.  
  47.      SCANFILS is written in Fortran 77, and is pretty straightforward. But
  48. of course there are always some things which a few words of explanation may
  49. save someone else a lot of time trying to figure out what the author is up to.
  50.  
  51.      The usual declarations and initializations are there. Here I guess I
  52. should mention an old habit of mine, born of reading lots of source code
  53. with lots of logical unit numbers, like "read(17,1001)iolist". If there are
  54. as few as 3 or 4 such numbers you will find yourself flipping back and forth
  55. between source and job control listing to see which files are associated with
  56. which numbers. So I set up data statements to make the correlations for me.
  57. Example:  data gpcin /17/
  58.                   .
  59.                   .
  60.           read(gpcin,1001)iolist
  61. Using this, I wouldn't have to go to the control file or anyplace else to know
  62. that I was reading the gpc input file. So that is what the statement
  63.           data oldir,nudir,report,savefi /2,3,4,8/
  64. is doing. Its keeping me from getting mixed up.
  65.  
  66.      A couple of lines farther down, the statement
  67.           data tmpfmt /.........../
  68. initializes an array containing an execution time format statement. It turns
  69. out that MS-DOS will not tolerate any spaces between filename and extension,
  70. just the period. So the number of characters in filename is counted, and the
  71. A8, which you see in tmpfmt will be changed to A7 or A4, or whatever is the
  72. number of characters in filename.
  73.  
  74.      The entire old and new directories are read into arrays, except for the
  75. headers and trailers, and the size column.
  76.  
  77.      The "end = ..." in line 47 is not needed. (Line numbers are contained
  78. in SCANFILS.LST). It is a defensive coding habit. The statement, "...bytes
  79. free " in the directory trailer, has the " free " right under the time column.
  80. I use that instead of EOF as a signal to quit the read loop.
  81.  
  82.      Since the directory listings are so short, not more than 50 in this
  83. program, I do not sort/merge. The program simply looks at an entry in the
  84. old directory and then goes thru the new directory from the beginning till
  85. it finds a match (maybe).
  86.  
  87.      Beginning on line 88 of scanfils.lst, the program counts the number of
  88. characters in filename. Fortran 77 uses the internal file concept instead of
  89. the old encode-decode of Fortran 5. "fname" on lines 88 and 89 is the internal
  90. file name. I write to it with an A8 format, and read from it with 8A1 format.
  91. "Nurch", for number of characters in lines 94,95, is another use of the
  92. internal file.
  93.  
  94.      The "* Pack nudir arrays " paragraph deletes from the arrays data
  95. pertaining to files that have been matched up. This may be an inefficient
  96. use of cpu time. True, it will save some time in the match up process. At any
  97. rate, the code's there, and it has the plus feature that whatever is left in
  98. the nudir arrays at the end is a list of newly created files. The "do 300"
  99. loop, beginning at line 121 writes whatever amy remain in the nudir arrays
  100. to savefils.
  101.  
  102.      The last three loops write to report.txt a list of actions taken in the
  103. RAM disk session, namely;
  104.           files deleted,
  105.           files added,
  106.           files changed.
  107.  
  108.      Note that a file deleted in RAM is not deleted by the batch file. For the
  109. few files that I may delete in this application I use DOS. Also, it is
  110. sometimes handy to be able to get an unneeded file out of RAM by deleting it,
  111. knowing that it wont be deleted from your floppy.
  112.  
  113.      This was originally designed to work on a Tandy 2000 with 2 floppies and
  114. no fixed disk. It first ran with the RAM in c:, but when I got the fixed disk,
  115. (and a later version of MS-DOS) I had to change it to e:. I did that and
  116. checked it out. It still works.
  117.  
  118.       With the application files in b:, and the dBase2 working disk,
  119. (containing CLL.BAT, SCANFILS.BAT, and CONFIG.SYS capable of establishing a
  120. RAM disk) in a:, enter CLL, and it will take off. Surprise! You will get
  121. a copy of new.dir in b: in addition to any other creations or changes.
  122.  
  123.                         Cordially,
  124.  
  125.  
  126.  
  127.  
  128.                         Frank H. Jeys
  129.                         414 Bay Colony
  130.                         LaPorte, Tex 77571
  131.  
  132.                         (713) 471-2462
  133.