home *** CD-ROM | disk | FTP | other *** search
/ CP/M / CPM_CDROM.iso / cpm / msoft / msftnw-1.apr < prev    next >
Text File  |  1983-09-09  |  9KB  |  179 lines
  1.  
  2.                       MICROSOFT NEWSLETTER
  3.  
  4.                            APRIL, 1982
  5.  
  6.                 ================================
  7.  
  8.                          16 BIT PRODUCTS
  9.                          ---------------
  10.  
  11.   There appears to be some confusion about our 16 bit products.  
  12. I hope this will explain our current policies and procedures.
  13.   First, at this time, *NONE* of our 16 bit products (8086, 8088, 
  14. Z8000, 68000) are available as Microsoft Corporation End User 
  15. Products.  Instead, these products (MS-DOS, Xenix, Fortran, 
  16. Cobol, Pascal, etc) are licensed to a number of commercial 
  17. customers who then market them in conjunction with their own 
  18. hardware and/or systems.  We often refer to these customers as 
  19. "OEMs".   Since the marketing of a product licensed in this 
  20. manner is strictly up to the OEM, we cannot answer any questions 
  21. regarding the availability (or price) of these products.  In 
  22. addition, since the product may have been modified for the 
  23. specific hardware involved, we cannot answer any questions 
  24. regarding a particular implementation.
  25.   In summary, our 16 bit products are "custom" products; for 
  26. information regarding these products, one should contact a 
  27. particular OEM, and NOT Microsoft. 
  28.  
  29.       FILE ACCESS (CONT'D)
  30.       --------------------
  31.   Last issue we talked a bit about files, and the way CP/M 
  32. allocates file space on disk. This issue, let's look at 
  33. sequential file access as performed by MBasic/Bascom, Fortran and 
  34. Cobol.
  35.   First, a quick review.  A sequential file is a file that is 
  36. accessed in sequence.  This "sequence" is the order in which the 
  37. records were entered.  If we write a file that contains 100 
  38. records;  and then attempt to read that file, if we want the 98th 
  39. record, we first have to read past records 1 thru 97. There is no 
  40. way to access a record "out of sequence" or randomly.  Usually, 
  41. if we want to update a sequential file, we read the old file as 
  42. input and write a new file containing the changed information.
  43.   Now let's look at how each language handles sequential files. 
  44.  
  45.   MBASIC/BASCOM 
  46.   The commands Basic uses for sequential I/O include OPEN, CLOSE, 
  47. LINE INPUT#, INPUT#, PRINT#, and WRITE#, and PRINT# USING.  When 
  48. we OPEN a sequential file in Basic, it must be OPENed as either 
  49. an input (I) or output (O) file.  
  50.   A file is then written by using a PRINT or WRITE statement for 
  51. each record you wish to write.  For example, the following code 
  52. segment opens a file, and writes 100 records to the file: 
  53.      OPEN "O",1,"TEST.DAT"
  54.      FOR I= 1 TO 100
  55.      J = I + I
  56.      PRINT #1,"RECORD # ";I;J
  57.      NEXT I
  58.      CLOSE 
  59.   Note that we wrote both a string variable and a numeric 
  60. variable.  The resulting file will look something like this: 
  61.  RECORD # 1  2
  62.  RECORD # 2  4
  63.  ... 
  64.   The file will contain 100 records and each record will be 
  65. terminated with a carriage return/line feed pair.  The file 
  66. itself is terminated with a control-Z (Hexadecimal 1A).  
  67.   In the example above, we used the PRINT statement.  If we had 
  68. used the WRITE statement, the string would have been placed in 
  69. quotes, and there would have been a comma between the values of I 
  70. and J.  This is particularly useful when we attempt to read the 
  71. file again, as we'll see below.  PRINT# USING will produce 
  72. formatted output to a file, just a PRINT USING produces formatted 
  73. output to your terminal.
  74.   Just as we have the WRITE and PRINT statements for output, we 
  75. have two corresponding statements for input:  LINE INPUT, and 
  76. INPUT.  The difference is the manner in which data is delimited.  
  77. LINE INPUT will read an entire record, up to (but not including) 
  78. the CR/LF (carriage return/line feed) pair.  This allows us to 
  79. input entire strings of data at one time. The INPUT statement 
  80. expects each numeric data item to be delimited by commas, and 
  81. strings contained in quotes.  
  82.   On input, the end of a file is detected by the EOF function, as 
  83. illustrated below: 
  84.      WHILE NOT E0F(1)
  85.      .
  86.      .
  87.      WEND
  88.   Here, we're checking file number 1 for end of file.  
  89.   To summarize, the file I/O statements in Basic format output 
  90. just as they would to the screen or printer.  The WRITE statement 
  91. writes a file that can be read easily with the INPUT statement;  
  92. and PRINT will generate data readable by the LINE INPUT 
  93. statement.
  94.  
  95.   FORTRAN 
  96.   Like Basic, FORTRAN uses the same I/O statements for sequential 
  97. disk files as it does for I/O to the console. However, in FORTRAN 
  98. we have a few extensions.  First, we can make use of UNFORMATTED 
  99. I/O to and from disk.  We also have access to the END= branch in 
  100. the READ statement, and the ERR= branch in the READ and WRITE 
  101. statements.  Finally, one should remember that FORTRAN limits 
  102. disk records to 128 characters of less.
  103.   Let's look at formatted I/O first.  Sequential disk I/O in 
  104. FORTRAN is performed in the same manner as console I/O, with one 
  105. important difference.  When FORTRAN reads or writes a disk 
  106. record, the record is terminated with a carriage return ONLY (no 
  107. line feed).  Similarly, when FORTRAN reads a disk file, it 
  108. assumes that the records are terminated with only a carriage 
  109. return, and the line feed is treated as data.  
  110.   This idiosyncrasy can be annoying, but is fairly easy to deal 
  111. with.  On input, we can simply skip the first character of the 
  112. second thru last records. On output, define a LOGICAL variable as 
  113. the line feed character and write in an A1 format, as below: 
  114.      LOGICAL LF
  115.      LF=10
  116.      DO 10 I=1,10
  117.      WRITE(6, 20) I,LF 10   CONTINUE 20   FORMAT(I4,A1)
  118.   This will write a line feed character at the end of each line 
  119. of output.  Notice that we do not need to allow one character at 
  120. the beginning of the record for carriage control, as we would if 
  121. we were writing to a printer.   Unformatted I/O is performed in 
  122. the same manner as formatted I/O, but without the FORMAT 
  123. statement.  This allows us to write records to disk files in 
  124. "memory image" or binary format, which saves disk space, and is 
  125. faster.  Files written in this manner may be read only by another 
  126. FORTRAN program, also using unformatted I/O.
  127.   As mentioned earlier, we can use the END= and ERR= branches 
  128. with disk I/O statements.  The format of these statements is as 
  129. shown in your FORTRAN manual.  The END= will transfer control to 
  130. the specified statement number when an end of file is 
  131. encountered.  The ERR= will transfer control to the specified 
  132. statement when a physical I/O error occurs.  Note that ERR= will 
  133. NOT trap "logical" errors, such as errors in format width or 
  134. specification.   FORTRAN allows us to use a file name other than 
  135. the standard "FORTnn.DAT";  by using the OPEN subroutine.  This 
  136. statement is formatted as follows: 
  137.  CALL OPEN(filenumber,filename,  drivenumber) 
  138.   Where filenumber is the LUN (6-10) of the file, filename is the 
  139. name of the file (in quotes), and drivenumber is the drive number 
  140. according to the following table: 
  141.    drivenumber    drive
  142.    -----------    -----
  143.           0       currently 
  144.                   logged 
  145.           1         A:
  146.           2         B:
  147.              etc.
  148.   An example of this statement is shown below.  Note that the 
  149. filename is filled to 8 spaces, and the extension to 3 spaces. 
  150. Also, the period separating the filename and the extension is 
  151. also left out. 
  152.     CALL OPEN(6,'TEST    DAT',0) 
  153.   This statement will open the file TEST.DAT on the default 
  154. drive, for use as logical unit (LUN) 6. 
  155.  
  156.   COBOL 
  157.   COBOL has two different formats for sequential files.  
  158.   The first (and default) is SEQUENTIAL.  In the SEQUENTIAL 
  159. format, records are considered variable length, and each record 
  160. begins with several characters of control information.  Files 
  161. written with the SEQUENTIAL organization can be read only by 
  162. another COBOL program.
  163.   The second format is called LINE SEQUENTIAL, and is the 
  164. familiar CP/M "text" file format.  Each record is variable 
  165. length, terminated by a carriage return/ line feed pair, and 
  166. consists of a string of ASCII characters.
  167.   Like BASIC, COBOL sequential files may be opened for input or 
  168. output.  There is also a special mode allowed for COBOL files, 
  169. called EXTEND.  A file that is OPENed EXTEND may have records 
  170. added to it at the end of the file.
  171.   While COBOL code is a bit to lengthy for an example here, watch 
  172. the public access space for examples of COBOL file and screen 
  173. handling in the near future.
  174.  
  175.   That's all for this issue.  In the next issue we'll talk about 
  176. random access files and how they are implemented in the various 
  177. Microsoft languages.
  178.  
  179.