home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #18 / NN_1992_18.iso / spool / comp / unix / aix / 8979 < prev    next >
Encoding:
Text File  |  1992-08-21  |  2.8 KB  |  62 lines
  1. Newsgroups: comp.unix.aix
  2. Path: sparky!uunet!cis.ohio-state.edu!pacific.mps.ohio-state.edu!linac!convex!constellation!geohub.gcn.uoknor.edu!dwight
  3. From: dwight@geohub.gcn.uoknor.edu (Dwight D. Moore)
  4. Subject: Re: HELP: Change blocksize on 8mm tape on RS/6000
  5. Message-ID: <1992Aug21.145733.24320@constellation.ecn.uoknor.edu>
  6. Keywords: 8mm Tape RS/6000 Blocksize
  7. Sender: usenet@constellation.ecn.uoknor.edu (Nets)
  8. Reply-To: dwight@geohub.gcn.uoknor.edu
  9. Organization: Geosciences Computing Network, Univ. of Oklahoma
  10. References:  <1992Aug19.171332.15803@bert.eecs.uic.edu>
  11. Date: Fri, 21 Aug 1992 14:57:33 GMT
  12. Lines: 48
  13.  
  14. In article <1992Aug19.171332.15803@bert.eecs.uic.edu>, artn@bert.eecs.uic.edu (Ellyn
  15. Sandor) writes:
  16. |>
  17. |>    Is there any way to change the blocksize on an RS/6000 8mm
  18. |>tape drive?  After a lot of messing around, I finally figured out
  19. |>that one of the problems with what I'm working on is that if I try
  20. |>to write() a record with a number of bytes that is not a multiple of
  21. |>1024 bytes, I get an "bad argument" message.  Is there a switch for
  22. |>this, or do I have to work with it?
  23. |>    I am trying to emulate tape formats for graphic arts systems,
  24. |>including the LV3 format and DDES.  The LV3 format I was trying to write
  25. |>wanted a blocksize of 36000 bytes, and DDES wants a bunch of 80 byte
  26. |>headers written.
  27. |>    Or... is this a dumb question?  Are 8mm tapes constrained
  28. |>by convention to blocksizes that are multiples of 1K?  In other words,
  29. |>do I just THINK the computer on the other end wants another blocksize,
  30. |>but really, I should just be padding out the data?
  31. |>    (Oh, yeah, if anyone is familiar with DDES, do the VOL1, HDR1, 
  32. |>UHL1, etc records have to be (a) 80 byte blocks (b) padded to 1024 byte
  33. |>blocks with one of these records in each block or (c) all the 80 byte
  34. |>blocks lumped together in one 1024 byte block?  The ANSI standard does
  35. |>not seem to deal with this, although the writing is sort of dense...)
  36. |>
  37. |>    Thanks in advance!
  38. |>                Stephan Meyers
  39. |>-- 
  40. |>--
  41. |>Stephan Meyers | artn@uicbert.eecs.uic.edu
  42. Yes, we have had a similar problem with NEXRAD radar data tapes which have a very
  43. non-ANSI standard maximum block size of 145920. You can change the 8mm block
  44. size as such:
  45.     chdev -l rmt0 -a block_size=1024
  46.  
  47. To check the current settings, use
  48.     lsattr -E -l rmt0
  49.  
  50. As a matter of fact, I understand that a 1024 block size is more efficient on Exabytes
  51. 8mm since that is the actual block size the hardware uses to write to the media. I
  52. believe the ANSI standard only restricts the maximum record size to 64K bytes.
  53.  
  54. ----------------------------------------------------------------------------
  55. Dwight D. Moore
  56. Geosciences Computing Network
  57. University of Oklahoma
  58.  
  59. dwight@geohub.gcn.uoknor.edu (129.15.40.10)
  60. These opinions do not necessarily represent the opinions of OU or the GCN.
  61. ----------------------------------------------------------------------------
  62.