home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #1 / NN_1993_1.iso / spool / comp / os / vms / 20350 < prev    next >
Encoding:
Internet Message Format  |  1993-01-05  |  4.4 KB
  1. Path: sparky!uunet!zaphod.mps.ohio-state.edu!pacific.mps.ohio-state.edu!linac!att!ucbvax!lrw.com!leichter
  2. From: leichter@lrw.com (Jerry Leichter)
  3. Newsgroups: comp.os.vms
  4. Subject: re:  Variable length records to tape
  5. Message-ID: <9301051329.AA11729@uu3.psi.com>
  6. Date: 5 Jan 93 12:28:44 GMT
  7. Sender: daemon@ucbvax.BERKELEY.EDU
  8. Distribution: world
  9. Organization: The Internet
  10. Lines: 76
  11.  
  12.  
  13.     Can someone tell me how to write variable length physical blocks to
  14.     tape with VMS, so that the tape can be read again on a foreign system?
  15.  
  16.     In better detail:
  17.  
  18.     If my file has record format "Variable length, maximum 2048 bytes",
  19.     and I have a record that is 2100 bytes,
  20.  
  21. Such a record can't exist.  What do you think "maximum 2048 bytes" means?
  22. *You* may have some convention for considering successive records to be part
  23. of one "unit", but that doesn't make them records.  It's important to keep
  24. the terms straight so we know what we are talking about!
  25.  
  26.                             then I need the first 2048
  27.     bytes written in one physical block and the next 52 bytes written in
  28.     the next physical block, immediately followed by a physical
  29.     end-of-block.  No leading size- of-block info, no trailing filler to
  30.     complete 2048 bytes; just my data and physical end-of-block markers.
  31.     On disk, my file is stored just as I want it:  logical blocks are
  32.     headed by 2 bytes to indicate their size, but these 2 bytes are not
  33.     included in that size -- just my data.  I need VMS to write this file
  34.     to tape using these 2 bytes to determine how long to make the physical
  35.     block, with no extraneous overhead.  The size of the physical block
  36.     would tell the system reading the tape how long the logical block is.
  37.  
  38. The "extraneous data" is there whether the file is on disk or on tape.  It's
  39. just a question of how the sizes of the records are described.  For VMS disk
  40. files, the length field describes only the user data, and when you access the
  41. file using record-mode operations, you never see the length, only the data.
  42. For tape files, VMS follows ANSI tape conventions, which specify that the
  43. length field INCLUDES itself in defining the length of a record.
  44.  
  45. To add to the confusion, VMS disk files use a 2-byte binary length field,
  46. which can take on any value from 0 to 32765; the actual record is padded to
  47. an even length, although the record length may be odd.  ANSI variable-length
  48. tape records use a four-byte decimal length (i.e., the length field contains
  49. ASCII digits specifying a length in decimal), which can take on any value from
  50. 4 to 9999 (indicating 0 to 9995 bytes of data).
  51.  
  52.     VMS will *read* a file this way, but when I use COPY to write one to
  53.     tape and use "dd" to read it back on a UNIX system, each logical block
  54.     is headed by it's size, and this header takes physical space in the
  55.     block.
  56.  
  57. It ALWAYS takes physical space.  The issue is whether you SEE the length bytes
  58. as data or not.  Were you to read the tape back on VMS, you would not see
  59. the length bytes.  Who knows what dd will give you - it depends on one of the
  60. thousands of obscure options you've specified.
  61.  
  62.             The last block in a record is padded to fill 2048 bytes.
  63.  
  64. Let's step back a moment.  VMS supports ANSI-labeled tapes with two formats:
  65. Fixed length records and variable length records.  (I've described variable
  66. length records above; a fixed-length record contains, as you'd expect just
  67. user data.)  The records are gathered together into blocks (which according
  68. to ANSI spec can be up to 2048 bytes long, though VMS and many other systems
  69. let you go larger).  The blocks themselves are always of fixed length, no
  70. matter what the record format; there is a physical "end of block" indication
  71. on the tape.  The unit of I/O to the tape is this physical block.
  72.  
  73. The format you are describing - encoding your logical units as one or more
  74. varying-length blocks - is not a supported VMS ANSI format.  You cannot
  75. write such a tape using RMS operations, which also means that you cannot
  76. use any of the standard VMS utilities (like COPY and CONVERT) to write it.
  77. Apparently RMS is much more forgiving when it comes to READING such a tape,
  78. but that doesn't help you.
  79.  
  80. It is straightforward to write a tape of this format yourself.  If you mount
  81. the tape /FOREIGN and then use QIO's, you can organize the contents of the
  82. tape pretty much any way you like:  The operation you'll use is "write n bytes
  83. as a block".  Of course, if you also want ANSI labels, you'll have to write
  84. them yourself.  But in any case you'll have to write a program to do this.
  85.  
  86.                             -- Jerry
  87.  
  88.