home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #16 / NN_1992_16.iso / spool / comp / os / vms / 12787 < prev    next >
Encoding:
Internet Message Format  |  1992-07-25  |  3.9 KB
  1. Path: sparky!uunet!sun-barr!ames!agate!ucbvax!NSCVAX.PRINCETON.EDU!dragon
  2. From: dragon@NSCVAX.PRINCETON.EDU (Mighty Firebreather)
  3. Newsgroups: comp.os.vms
  4. Subject: RE: VMS/Un*x media exchange compatibilities
  5. Message-ID: <0095E1A1.5FB6FDA0.7100@nscvax.princeton.edu>
  6. Date: 25 Jul 92 16:51:13 GMT
  7. Sender: daemon@ucbvax.BERKELEY.EDU
  8. Distribution: world
  9. Organization: The Internet
  10. Lines: 74
  11.  
  12.  
  13.     Chris Marzec <MARZEC%GUNBRF.BITNET@VTVM2.CC.VT.EDU> writes:
  14. >
  15. >We are interested in methods of data exchange between VMS and other systems
  16. >such as Un*x via magnetic tape media preferably DAT. At present we have been
  17. >able to distribute to non-VMS sites by using the following protocol for mag
  18. >tape and TK dirves:
  19. >
  20. >  1. rewrite VMS files from "variable length records / CR carriagecontrol"
  21. >                         to "fixed-length 80-byte rec / CR carriagecontrol"
  22. >  2. INITIALIZE tape device with some label
  23. >  3. MOUNT/FOREIGN/RECORDSIZE=80/BLOCKSIZE=4800 device:
  24. >                                          =2048 for TK50, TK70 (and DAT) tape
  25.  
  26.     This probably overwrites your label.  It certainly will result in 
  27. no HDR1, HDR2, HDR3 labels being written and no trailer labels either!  If 
  28. you MOUNT /FOREIGN you do not get an ANSI labeled tape!
  29.  
  30. >  4. COPY VMS-file device:
  31. >
  32. >In the past most all non-VMS sites were able to use this media. We assume that
  33. >this protocol yields an industry standard ANSI-labeled tape. However, lately
  34. >we attempted to distribute data via the above protocol except using a WangDAT
  35. >Model 1300 DDS DAT tape drive. The system used is a VAXstation 3100 running
  36. >V5.5. The customer was able to read/copy only the first file of the volume
  37. >after which no more data was accessible. We are curious to get feedback from
  38. >this protocol, specifically if it can be used for all non-VMS systems and if
  39. >it is an efficient procedure (time and space).
  40. >
  41. >Questions:
  42. >  1. is "VMS-ANSI-labeled" synonymous with "ANSI-labeled"
  43.  
  44.     Sort of.  There are various revisions or levels of the ANSI standard
  45. and I believe that VMS uses level 3 while level 4 is the current version 
  46. (or something like that).
  47.  
  48. >  2. the DAT drive spec for blocksize is 36, is this significant because we
  49. >     are able to read the tape inhouse when made using the above protocol
  50.  
  51.     A blocksize of 36????? 36 byte blocks???  I don't believe it!  36K 
  52. maybe?
  53.  
  54. >  3. does VMS file attributes affect the format of data when written to tape
  55. >     ie. fixed-length vs. stream_LF (is one better than the other)
  56.  
  57.     For years, the one tape format that *any* system can read, has 
  58. been 80 byte *unblocked* fixed length records with *no* labels!  With the 
  59. advent of streaming cartridge drives, this may no longer be true.  It was 
  60. never very efficient in terms of either speed or tape usage; it was just so
  61. simple and standard that even the brain damaged could read it.
  62.  
  63.     These days anybody, with the possible exceptions of IBM and Unix 
  64. systems should be able to read an ANSI labeled tape.
  65.  
  66.     To make an ANSI labeled tape:
  67. $ ALLOCATE MUA0: TAPE
  68. $ INITIALIZE TAPE label
  69. $ MOUNT /BLOCKSIZE=xxxx /RECORDSIZE=yyy TAPE:
  70. $ COPY MYFILE.DAT TAPE:
  71. $
  72.     If MYFILE.DAT has the fixed length record attribute, you will get 
  73. fixed length records on tape.  If the records are 80 bytes long, you will
  74. get 80 byte fixed length records.  If yyy is less than the actual record 
  75. size you will get an error.  Blocksize defaults to 2048.  You might want to
  76. use a larger value.
  77.  
  78. *************************************************************************
  79. *                                                                       *
  80. *                        Here, there be dragons!                        *
  81. *                      dragon@nscvax.princeton.edu                      *
  82. *                                                                       *
  83. *                                                Richard B. Gilbert     *
  84. *************************************************************************
  85.  
  86.