eravin@panix.uucp (Ed Ravin) (04/23/91)
1) Under SUN OS 3, there's a handy dandy utility called "mt" which lets you skip ahead or back on a tape with several files written on it. For example, # mt fsf 2 Would skip forward 2 file marks on the tape. But a peek through Info Intruder revealed only the device driver interface to do same via ioctl(). Does AIX give you a command to manipulate the tape or shall I have to go write one myself? 2) My IBM 1/4" tape drive will let me read DC-300 XL tapes written on my Sun 3/160, but won't let me write on them (write: invalid argument). It would be nice to recycle this big stack of DC-300 cartridges lying around. Can anyone explain what's happening here? -- Ed Ravin | I'm sorry, sir, but POSTAL REGULATIONS don't allow cmcl2!panix!eravin | PLASTIC tape over PAPER tape and NYLON cord on an philabs!trintex!elr | 86 inch girth to LITHUANIA... +1 914 993 4737 |
hubler@galaxy.lerc.nasa.gov (Dale Hubler) (04/23/91)
In article <1991Apr22.195656.10564@panix.uucp> eravin@panix.uucp (Ed Ravin) writes: >1) Under SUN OS 3, there's a handy dandy utility called "mt" which lets you >skip ahead or back on a tape with several files written on it. For example, > ># mt fsf 2 > >Would skip forward 2 file marks on the tape. But a peek through Info >Intruder revealed only the device driver interface to do same via ioctl(). Look in info explorer for the tctl command. Why they didn't make this named mt or set up as a link escapes me. Must be a difference between BSD and SYS V. I was looking for mt for a while also. -- Dale A. Hubler -- Sverdrup Technology -- (216) 977-7014 hubler@galaxy.lerc.nasa.gov I am logged in, therefore I am.
rtp1@quads.uchicago.edu (raymond thomas pierrehumbert) (04/24/91)
Under AIX, the command "tctl" is the equivalent of "mt". It works, so far as I can tell. Don't ask me why they changed the name. I couldn't find this out via info explorer either. I had to ask my software engineer. It underscores that searching in info explorer is not as useful as it could be.
mfineman@cadev5.intel.com (Mark Fineman ~) (04/24/91)
In article <1991Apr23.152922.20686@eagle.lerc.nasa.gov> hubler@galaxy.lerc.nasa.gov (Dale Hubler) writes: >In article <1991Apr22.195656.10564@panix.uucp> eravin@panix.uucp (Ed Ravin) writes: >Look in info explorer for the tctl command. Why they didn't make this >named mt or set up as a link escapes me. Must be a difference between >BSD and SYS V. I was looking for mt for a while also. How do I get the tape off-line or unloaded or write locked? The idea is that operator intervention should be required before more writes can occur to a given cassette. (E.g., when running backup I want to be able to force the operator to mount another tape, not just say he did. I can't quite do this with mt, but at least I can do an mt offline or mt unload to force him to go over to the drive and do something. tctl doesn't have offline, unload, writelock, etc.) (408) 765-4277; MS SC3-36, 3065 Bowers Ave, Santa Clara, CA 95052 / decwrl \ | hplabs | -| oliveb |- !intelca!mipos3!cadev6!mfineman | amd | \ qantel /
tli@Morgan.COM (Thomas Y. Li ) (04/24/91)
In article <1991Apr22.195656.10564@panix.uucp> eravin@panix.uucp (Ed Ravin) writes: >1) Under SUN OS 3, there's a handy dandy utility called "mt" which lets you >skip ahead or back on a tape with several files written on it. For example, > ># mt fsf 2 > >Would skip forward 2 file marks on the tape. But a peek through Info >Intruder revealed only the device driver interface to do same via ioctl(). >Does AIX give you a command to manipulate the tape or shall I have to >go write one myself? > IBM has the tctl command for Tape ConTroL. >-- >Ed Ravin | I'm sorry, sir, but POSTAL REGULATIONS don't allow >cmcl2!panix!eravin | PLASTIC tape over PAPER tape and NYLON cord on an >philabs!trintex!elr | 86 inch girth to LITHUANIA... >+1 914 993 4737 | Regards, Tom =============================================================== Thomas Y. Li Email: tli@nycvmic4.iinus1.ibm.com IBM Corporation tli%nycvmic4@iinus1.ibm.com 33 Maiden Lane 10th Floor tli@morgan.com New York, NY 10038 (212) 493-2516 T/L 340 VNET: tli at nycvmic4
ng@cfd.di.nrc.ca (Kai Ng) (04/24/91)
In article <1991Apr23.194408.14080@midway.uchicago.edu>, rtp1@quads.uchicago.edu (raymond thomas pierrehumbert) writes: |> |> Under AIX, the command "tctl" is the equivalent of "mt". It works, |> so far as I can tell. Don't ask me why they changed the name. Not exactly. There is no 'mt eom' equivalent for tctl (at least not up to 3003). -- ----------------------------------------------------------------------------- Kai S. Ng Informatics, National Research Council Canada INTERNET ng@cfd.di.nrc.ca M-60 Montreal Road, Ottawa, Canada K1A 0R6 BITNET kain@nrcvm01.bitnet VOICE (613) 993-0240 FAX (613) 954-2561
slh@gibdo.engr.washington.edu (04/24/91)
In article <1991Apr22.195656.10564@panix.uucp> eravin@panix.uucp (Ed Ravin) writes: |1) Under SUN OS 3, there's a handy dandy utility called "mt" which lets you |skip ahead or back on a tape with several files written on it. For example, | |# mt fsf 2 | |Would skip forward 2 file marks on the tape. But a peek through Info |Intruder revealed only the device driver interface to do same via ioctl(). |Does AIX give you a command to manipulate the tape or shall I have to |go write one myself? | I think dd -fskip=2 would be equivalent.
frank@leopard.austin.ibm.com (04/24/91)
> 1) Under SUN OS 3, there's a handy dandy utility called "mt" which lets you > skip ahead or back on a tape with several files written on it. For example, > # mt fsf 2 Look at the tctl command > 2) My IBM 1/4" tape drive will let me read DC-300 XL tapes written on my > Sun 3/160, but won't let me write on them (write: invalid argument). Sorry, you can read but not write to these low density tapes. Also, to write to -600 tapes you have to use /dev/rmt0.4. The default is a higher density (1200?) - Frank Feuerbacher Disclaimer: I speak only for me! And I don't even do a good job of that!
eravin@panix.uucp (Ed Ravin) (04/25/91)
In article <mumble@eagle.lerc.nasa.gov> hubler@galaxy.lerc.nasa.gov (Dale Hubler) writes: >Look in info explorer for the tctl command. Why they didn't make this >named mt or set up as a link escapes me. Must be a difference between >BSD and SYS V. I was looking for mt for a while also. Thanks, and thanks to the other handful of people who either posted or mailed me the answer. The real problem here is not what they call it, but that "tctl" is not cross-referenced anywhere. The obvious place would be in the "rmt" section in Special Files. Less obvious would be the "dd" command, the "backup" command, etc. To give you an idea how bad the indexes are in IBM's manuals, in Special Files, there's not even any entries for "Tape" in the index, just "rmt". Unix from any other vendor always has the "permuted index" -- not the best way of doing things, but at least all the information is there. -- Ed Ravin | I'm sorry, sir, but POSTAL REGULATIONS don't allow cmcl2!panix!eravin | PLASTIC tape over PAPER tape and NYLON cord on an philabs!trintex!elr | 86 inch girth to LITHUANIA... +1 914 993 4737 |
mbrown@testsys.austin.ibm.com (Mark Brown) (04/25/91)
rtp1@quads.uchicago.edu (raymond thomas pierrehumbert) writes: |Under AIX, the command "tctl" is the equivalent of "mt". It works, |so far as I can tell. Don't ask me why they changed the name. | |I couldn't find this out via info explorer either. I had to ask my |software engineer. It underscores that searching in info explorer |is not as useful as it could be. I think I'm responsible for this...the point was to take the many BSD commands and put them into tctl (if they would logically go there) so that a user would only have to look in one place to find tape control functions.... Perhaps a link to mt would be the best thing here....I'll look into it. -- Mark Brown IBM PSP Austin, TX. (512) 823-3741 VNET: MBROWN@AUSVMQ MAIL: mbrown@testsys.austin.ibm.com OR uunet!testsys.austin.ibm.com!mbrown Which came first: The Chicken or the Legba? DISCLAIMER: Any personal opinions stated here are just that.
rmilner@zia.aoc.nrao.edu (Ruth Milner) (04/25/91)
In article <1991Apr23.194408.14080@midway.uchicago.edu> rtp1@quads.uchicago.edu (raymond thomas pierrehumbert) writes: > >I couldn't find this out via info explorer either. I had to ask my >software engineer. It underscores that searching in info explorer >is not as useful as it could be. At no time in this brief discussion has anyone mentioned trying the following: zuni<1>% man -k tape rmt(1) - Allows remote access to magnetic tape devices. tapechk(1) - Performs consistency checking of the streaming tape device. tcopy(1) - Copies a magnetic tape. tctl(1) - Gives subcommands to a streaming tape device. topen, tclose, tread, twrite, trewin, tskipf, tstate (3F) - f77 tape I/O Building the "whatis" database is the first thing I do on any new system, and man -k is one of the most useful ways to use the man pages. I hope this doesn't sound like bragging, but it took me all of 5 seconds to find tctl this way. BTW, it isn't simply a name change, it's a rewrite with a *lot* of missing functionality. No way to take the tape offline (like "offl" or "rewoffl"), no way to skip to the end of recorded media ("eom"), *NO STATUS CHECK* ("status" - how on earth could they leave this one out?????). We have found the Exabyte tape handling (don't have any other kind) to be ... unusual ... compared to the Suns. For example, on a Sun, if you write a file onto Exabyte, you can take it away and later on put it back in, skip to the end of that file, and write another one. On the RS/6000, not only will it not do this at all (I/O error), but if you take a tape with a file written on it by the IBM over to the Sun, the Sun won't write at the end of it any more either! Clearly it's writing something different, but we haven't been able to find out what. Anybody have any clues? According to the documentation, they both write a double eof on close, and that doesn't really cause us any serious problems. -- Ruth Milner Systems Manager NRAO/VLA Socorro NM Computing Division Head rmilner@zia.aoc.nrao.edu
bware@slate.mines.colorado.edu (Bob Ware) (04/26/91)
>rtp1@quads.uchicago.edu (raymond thomas pierrehumbert) writes: >|Under AIX, the command "tctl" is the equivalent of "mt". It works, >|so far as I can tell. Don't ask me why they changed the name. >| >|I couldn't find this out via info explorer either. I had to ask my >|software engineer. It underscores that searching in info explorer >|is not as useful as it could be. > >I think I'm responsible for this...the point was to take the many BSD commands >and put them into tctl (if they would logically go there) so that a user >would only have to look in one place to find tape control functions.... > ... >-- >Mark Brown IBM PSP Austin, TX. (512) 823-3741 VNET: MBROWN@AUSVMQ One of the most serious problems with tctl is the lack of a way to take a tape offline. This means that after making a backup of user files, ANYONE can read what is on the tape until the operator manually takes the tape offline. In effect, this creates a window when anyone can read anyone else's files!! ....a very serious security hole. If an operator were to start a backup at night just before they leave, the window would be several hours. -- Bob Ware, Colorado School of Mines, Golden, Co 80401, USA (303) 273-3987 bware@mines.colorado.edu bware@slate.mines.colorado.edu bware@mines.bitnet
wjones@nwnexus.WA.COM (Warren Jones) (04/26/91)
rmilner@zia.aoc.nrao.edu (Ruth Milner) writes: >We have found the Exabyte tape handling (don't have any other kind) to be ... >unusual ... compared to the Suns. For example, on a Sun, if you write a file >onto Exabyte, you can take it away and later on put it back in, skip to the >end of that file, and write another one. On the RS/6000, not only will it not >do this at all (I/O error), but if you take a tape with a file written on it >by the IBM over to the Sun, the Sun won't write at the end of it any more >either! Clearly it's writing something different, but we haven't been able >to find out what. Anybody have any clues? According to the documentation, >they both write a double eof on close, and that doesn't really cause us any >serious problems. I think one of the tricks to appending files on the end of a tape is to _always_ write to the no-rewind-on-close device, e.g. /dev/rmt0.1. But there seem to be other problems related to tctl. To put a new file at the end of the tape, you have to use tctl to skip over the stuff at the beginning, and "tctl fsf N" doesn't seem to work as advertised. I've been calling IBM software defect support about this for over _six_weeks_ now, and still haven't gotten a satisfactory answer. I'd be glad to hear from anyone else out there who has dealt with this. Warren Jones wjones@nwnexus.wa.com
duty@ariel.ucs.unimelb.edu.au (Duty Programmer) (04/30/91)
In article <496@nwnexus.WA.COM> wjones@nwnexus.WA.COM (Warren Jones) writes: >rmilner@zia.aoc.nrao.edu (Ruth Milner) writes: > >>We have found the Exabyte tape handling (don't have any other kind) to be ... >>unusual ... compared to the Suns. For example, on a Sun, if you write a file >>onto Exabyte, you can take it away and later on put it back in, skip to the >>end of that file, and write another one. On the RS/6000, not only will it not >>do this at all (I/O error), but if you take a tape with a file written on it >>by the IBM over to the Sun, the Sun won't write at the end of it any more >>either! Clearly it's writing something different, but we haven't been able >>to find out what. Anybody have any clues? According to the documentation, >>they both write a double eof on close, and that doesn't really cause us any >>serious problems. > I sympathise. The AIX tape i/o has been driving me crazy for several weeks. However, I think this last problem you mention may be something else. You don't mention whether you can read the IBM tapes on the Sun. If you can't, then it may be that the Sun is using CRC error correction and the IBM is using ECC. You can get the IBM to use CRC by either changing the characteristics of the tape driver (via chdev), or by piping tape writes through 'tctl t write'. Check InfoExplorer for more information. We have had no trouble with 8mm tapes, but the QIC tapes are driving us crazy. Both 'tar' and 'dd' seem to be broken with respect to tape i/o, although it seems that 'tctl' can always read and write tapes. The diagnostic is always 'bad argument', which is rather unhelpful. We have changed the block size from 512 to 0 (variable), and the damn thing still doesn't work. In case IBM is listening, we are running release 3.01.0004.0017 bos.obj. rab --- Richard Brown | E-mail: rab@tauon.ph.unimelb.edu.au School of Physics | Phone : +61 3 344 5081 University of Melbourne | Fax : +61 3 347 4783 Parkville Victoria AUSTRALIA 3052 | Telex : AA35185
rmilner@zia.aoc.nrao.edu (Ruth Milner) (05/01/91)
In article <595@ariel.ucs.unimelb.edu.au> duty@ariel.ucs.unimelb.edu.au (Duty Programmer) writes: >In article <496@nwnexus.WA.COM> wjones@nwnexus.WA.COM (Warren Jones) writes: >>rmilner@zia.aoc.nrao.edu (Ruth Milner) writes: >> >>>unusual ... compared to the Suns. For example, on a Sun, if you write a file >>>onto Exabyte, you can take it away and later on put it back in, skip to the >>>end of that file, and write another one. On the RS/6000, not only will it not >>>do this at all (I/O error), but if you take a tape with a file written on it >>>by the IBM over to the Sun, the Sun won't write at the end of it any more >>>either! > >I sympathise. The AIX tape i/o has been driving me crazy for several weeks. > >However, I think this last problem you mention may be something else. You don't >mention whether you can read the IBM tapes on the Sun. If you can't, then it >may be that the Sun is using CRC error correction and the IBM is using ECC. Yes, the data that has been written can be read back (we'd have found out *very* quickly if this weren't the case). But you cannot do an "mt fsf 2", for example, and then start writing at the end of the second file the IBM wrote. When the first n files were originally written by the Sun, the Sun has no trouble skipping over and starting to write. Also, this doesn't explain why the IBM can't append to its own tapes. If it is truly a restriction in the hardware, then it is a restriction that IBM has added, not one that Exabyte put in. This *severely* restricts the usefulness of the drive. "smit" gives no information about choosing an error detection/correction method. However, it does ask whether to use "extended file marks". The default appears to be "no"; should I change this to "yes"? Is the problem simply that the file marks aren't long enough (?) for positioning purposes? I vaguely recall reading somewhere the distinction between short and extended file marks, but I don't remember the details now on the effects. -- Ruth Milner Systems Manager NRAO/VLA Socorro NM Computing Division Head rmilner@zia.aoc.nrao.edu
pa@curly.appmag.com (Pierre Asselin) (05/01/91)
In article <1991Apr30.201002.24679@nmt.edu> rmilner@zia.aoc.nrao.edu (Ruth Milner) writes: > Also, this doesn't explain why the IBM can't append to its own tapes. > If it is truly a restriction in the hardware, then it is a restriction > that IBM has added, not one that Exabyte put in. This *severely* > restricts the usefulness of the drive. I pulled the following from IBMLink (APAR IX18487). I didn't try it myself. Hope it helps. Does it do any good with the Sun? Problem conclusion: this is a limitation of the tape drive. "write" is only allowed either at the beginning of a tape (bot) or at the end of a tape (eot). The user can still write to the tape after rewind and forward it to the last file written by issuing an extra "read" to the tape. This extra "read" will put the tape at eot position. Here is a scenario: - echo "test 1" dd of=/dev/rmt0.5 bs=512b conv=sync - echo "test 2" dd of=/dev/rmt0.5 bs=512b conv=sync - tctl -f /dev/rmt0.5 rew - tctl -f /dev/rmt0.5 fsf 2 - dd if=/dev/rmt0.5 bs=512b # ====extra read===== - echo "test 3" dd of=/dev/rmt0.5 bs=512b conv=sync --Pierre Asselin, R&D, Applied Magnetics. I speak for me.
frank@leopard.austin.ibm.com (05/01/91)
Several comments on tape questions. 1) In response to getting the 'invalid argument' when doing a tape operation: This may occur when you have a tape density mismatch (just a guess). The default is something like 1200. /dev/rmt0.1 writes to 600 tapes. They can not write to 300 tapes. Also, I think it would be worth calling in the ambiguous message 'invalid argument', I am not fond of it either. 2) ECC: I believe that this has been withdrawn from support in later updates. This could be why you don't see it as an option on your smit tape configuration menu. - Frank Feuerbacher Disclaimer: I speak only for me! And I don't even do a good job of that!
Andreas.Kaiser@f7014.n244.z2.stgt.sub.org (Andreas Kaiser) (05/02/91)
>"smit" gives no information about choosing an error >detection/correction >method. However, it does ask whether to use "extended file >marks". The default appears to be "no"; should I change this to "yes"? >Is the problem simply that the file marks aren't long enough (?) for >positioning I don't know about the changes in IBMs tape firmware but the mechanically identical tape Tandberg 3660 (and this magic name or number is written somewhere in the papers of the 6000) has no trouble writing at the end of the tape, when used with my own software under MSDOS. But it is not possible to overwrite existing tape data except at the beginning of the tape. There are just two places, where data can be written: at the beginning and the so-called "logical end of tape". And there is another (but nonstandard) feature missing in the 6000's software: Direct tape positioning. The Tandberg tape can be commanded to directly position to a given block number, which is done using an efficient seeking algorithm and takes at most two track times (~30 seconds to ~4 minutes). This is a really nice feature, when it comes to restore a single file from a full archive tape (~15 seconds to ~30 minutes). Gruss, Andreas * Origin: kaiser@ananke.stgt.sub.org - Stuttgart FRG (2:244/7014)
jpe@egr.duke.edu (John P. Eisenmenger) (05/02/91)
From article <7204@awdprime.UUCP>, by frank@leopard.austin.ibm.com: > 1) In response to getting the 'invalid argument' when doing a tape operation: > This may occur when you have a tape density mismatch (just a guess). > The default is something like 1200. /dev/rmt0.1 writes to 600 tapes. > They can not write to 300 tapes. > Also, I think it would be worth calling in the ambiguous message > 'invalid argument', I am not fond of it either. The usual case for me is a blocking mismatch. Your writes should be a multiple of the "BLOCK size" parameter as specified in SMIT. Anything else will yield the "A system call has received an invalid parameter" message. > 2) ECC: I believe that this has been withdrawn from support in later > updates. This could be why you don't see it as an option on your smit > tape configuration menu. Yes, I noticed that this was withdrawn in a Customer Announcement Letter. Then again, I have yet to receive AIX 3.1.5 which was to finish shipping last Friday -- it seems we're on the end of their list again... -John
rmilner@zia.aoc.nrao.edu (Ruth Milner) (05/03/91)
In article <709@curly.appmag.com> pa@curly.UUCP (Pierre Asselin) writes: >In article <1991Apr30.201002.24679@nmt.edu> >rmilner@zia.aoc.nrao.edu (Ruth Milner) writes: >> Also, this doesn't explain why the IBM can't append to its own tapes. >> If it is truly a restriction in the hardware, then it is a restriction >> that IBM has added, not one that Exabyte put in. This *severely* >> restricts the usefulness of the drive. > >I pulled the following from IBMLink (APAR IX18487). I didn't try it >myself. Hope it helps. Does it do any good with the Sun? [ code deleted] This is no doubt a useful workaround at the command-line level, but from within an application, it is completely impractical to say "if this is an IBM, do an extra read before writing the real data". It can't be considered a real solution - especially since you might be running on a Sun at the time. There is no way to know what system wrote the tape originally. As stated before, the Sun has *no problems whatsoever* appending after existing data, *unless* that data was written by the RS/6000. I.e., this "hardware restriction" does not apply to generic Exabyte drives. And whatever causes the problem appears to be something the IBM writes, because it goes with the tape. (But it isn't the tape itself, because you can overwrite it on the Sun and go back and it will append again). It may be possible to read past it, but the point is to *fix* the problem. It is totally absurd not to be able to skip to the end of a file and start writing a new one. It is a basic function in a tape drive. Even when tapes only held 150MB, it was important to be able to write files at different times, to make use of the full capacity. It is absolutely *vital* when a tape can hold 2GB. -- Ruth Milner Systems Manager NRAO/VLA Socorro NM Computing Division Head rmilner@zia.aoc.nrao.edu
graeme@ccu1.aukuni.ac.nz (Graeme Moffat) (05/03/91)
jpe@egr.duke.edu (John P. Eisenmenger) writes: >Yes, I noticed that this was withdrawn in a Customer Announcement Letter. >Then again, I have yet to receive AIX 3.1.5 which was to finish shipping >last Friday -- it seems we're on the end of their list again... Try living down in this part of the world. If it weren't for the net, we wouldn't even hear about it until you guys had had it for at least a month *B^) -- Graeme Moffat g.moffat@aukuni.ac.nz \ Time wastes us all, Computer Aided Design Centre, Fax: +64-9-366-0702 / our bodies & our wits School of Engineering, Ph: +64-9-737-999 x8384 / But we waste time, University of Auckland, Private Bag, Auckland, NZ \ so time & we are quits