Newsgroups: alt.folklore.computers From: Jay Maynard Subject: Call for information on virtual tape formats Reply-To: jmaynard@conmicro.cx Message-ID: User-Agent: slrn/0.9.8.0 (Linux) Lines: 17 Date: Wed, 16 Mar 2005 01:46:08 GMT NNTP-Posting-Host: 206.146.76.206 X-Complaints-To: abuse@onvoy.com X-Trace: news7.onvoy.net 1110937568 206.146.76.206 (Tue, 15 Mar 2005 19:46:08 CST) NNTP-Posting-Date: Tue, 15 Mar 2005 19:46:08 CST Organization: Onvoy Path: nightfall.franklin.ch!news1.ethz.ch!news-zh.switch.ch!switch.ch!solnet.ch!solnet.ch!news.glorb.com!newshosting.com!nx01.iad01.newshosting.com!novia!newspump.sol.net!upp1.onvoy!onvoy.com!news7.onvoy.net.POSTED!not-for-mail Xref: nightfall.franklin.ch alt.folklore.computers:200404 I'm finally getting around to writing the suite of virtual tape conversion programs I speculated on here a year or so ago. It's being structured as a library of routines to read and write various tape formats, and utilities (initially, just a copy program, but I've got ideas for more) built on top of that library. The library and utilities will be made available under the terms of a BSD-style license. I have documentation on the AWSTAPE format used by IBM and folks in the IBM world (and the HET (Hercules Emulated Tape) variant, which provides built-in compression), the virtual tape format used for the stuff in Tim Shoppa's library of DEC stuff (sometimes known as TPC format), and the two variants of the TAP format used by SIMH, E11, and DtCyber, among others. I know of the KLH10 RAW format, and I think I've got doc on how to do that one as well, but I haven't sat down yet to write the routines. Are there any other virtual tape formats out there in common, or even uncommon, use? Where might I find documentation on them? ###### NNTP-Posting-Date: Tue, 15 Mar 2005 22:52:09 -0600 From: Tom Van Vleck Newsgroups: alt.folklore.computers Subject: Re: Call for information on virtual tape formats Organization: Multicians References: User-Agent: MT-NewsWatcher/3.4 (PPC Mac OS X) Date: Tue, 15 Mar 2005 23:52:09 -0500 Message-ID: Lines: 6 NNTP-Posting-Host: 68.46.140.163 X-Trace: sv3-KhV2gDjy2hmAKixWWpa0TKy5puIg2DWDmEBZXp4+f1Y6pQe5P0bhXi9V4O9USjGJ4DFL4fiKjc3wcnp!6OlBWQ+f/Dj4Ldn/0a/Tj9M2NA4KNps3DrimppLRIOfxqizsO7d+Ac31UXwuhId4ORdaYvJeI/6Q!aEFezS0p X-Complaints-To: abuse@comcast.net X-DMCA-Complaints-To: dmca@comcast.net X-Abuse-and-DMCA-Info: Please be sure to forward a copy of ALL headers X-Abuse-and-DMCA-Info: Otherwise we will be unable to process your complaint properly X-Postfilter: 1.3.32 Path: nightfall.franklin.ch!news1.ethz.ch!news-zh.switch.ch!irazu.switch.ch!switch.ch!news.belwue.de!newsfeed01.sul.t-online.de!newsfeed00.sul.t-online.de!t-online.de!border2.nntp.dca.giganews.com!border1.nntp.dca.giganews.com!nntp.giganews.com!local01.nntp.dca.giganews.com!nntp.comcast.com!news.comcast.com.POSTED!not-for-mail Xref: nightfall.franklin.ch alt.folklore.computers:200433 Jay Maynard wrote: > Are there any other virtual tape formats out there in common, or even > uncommon, use? Where might I find documentation on them? Multics Standard Tape format: http://www.multicians.org/mspm-bb-3-01.html ###### Newsgroups: alt.folklore.computers From: Jay Maynard Subject: Re: Call for information on virtual tape formats References: Reply-To: jmaynard@conmicro.cx Message-ID: User-Agent: slrn/0.9.8.0 (Linux) Lines: 19 Date: Wed, 16 Mar 2005 05:23:02 GMT NNTP-Posting-Host: 206.146.76.206 X-Complaints-To: abuse@onvoy.com X-Trace: news7.onvoy.net 1110950582 206.146.76.206 (Tue, 15 Mar 2005 23:23:02 CST) NNTP-Posting-Date: Tue, 15 Mar 2005 23:23:02 CST Organization: Onvoy Path: nightfall.franklin.ch!news1.ethz.ch!news-zh.switch.ch!switch.ch!solnet.ch!solnet.ch!proxad.net!proxad.net!newshosting.com!nx02.iad01.newshosting.com!novia!newspump.sol.net!upp1.onvoy!onvoy.com!news7.onvoy.net.POSTED!not-for-mail Xref: nightfall.franklin.ch alt.folklore.computers:200436 On 2005-03-16, Tom Van Vleck wrote: > Jay Maynard wrote: >> Are there any other virtual tape formats out there in common, or even >> uncommon, use? Where might I find documentation on them? > Multics Standard Tape format: > http://www.multicians.org/mspm-bb-3-01.html I see I wasn't clear. Interesting reading, nonetheless. What I'm looking for is file formats that represent the entire physical tape as one file, to be fed to an emulator or transported over a network. Instead of a physical tape with blocks 1224 bytes long, a Multics standard tape might be represented as a file with a header, 1224 bytes of data, and a trailer, one group of these for each record on the tape. An emulator might present this file to a program running on it as though it were a physical tape mounted on a tape drive. It's a different level of abstraction. Did I clarify things, or confuse them more? ###### From: "Tim Shoppa" Newsgroups: alt.folklore.computers Subject: Re: Call for information on virtual tape formats Date: 16 Mar 2005 07:34:44 -0800 Organization: http://groups.google.com Lines: 27 Message-ID: <1110987284.154666.321070@g14g2000cwa.googlegroups.com> References: NNTP-Posting-Host: 170.121.15.35 Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Trace: posting.google.com 1110987289 5551 127.0.0.1 (16 Mar 2005 15:34:49 GMT) X-Complaints-To: groups-abuse@google.com NNTP-Posting-Date: Wed, 16 Mar 2005 15:34:49 +0000 (UTC) In-Reply-To: User-Agent: G2/0.2 Complaints-To: groups-abuse@google.com Injection-Info: g14g2000cwa.googlegroups.com; posting-host=170.121.15.35; posting-account=mAyfxAwAAABWbrxnXxYpn9RczUJc3B8w Path: nightfall.franklin.ch!news1.ethz.ch!news-zh.switch.ch!switch.ch!newscore.univie.ac.at!195.185.185.44.MISMATCH!feed.news.tiscali.de!news.netplace.de!news-FFM2.ecrc.net!news-raspail.gip.net!news.gsl.net!gip.net!grolier!v.t-online.fr!t-online.fr!news.glorb.com!postnews.google.com!g14g2000cwa.googlegroups.com!not-for-mail Xref: nightfall.franklin.ch alt.folklore.computers:200482 > the virtual tape format used for the stuff in Tim Shoppa's > library of DEC stuff (sometimes known as TPC format) I first saw the TPC format in the DECUS tools used to copy sigtapes for distribution up the tape tree. (The tools at the time were BIGTPC for RSX-11 and VMSTPCE for VMS.) Note that most of the tape images I distribute now have been converted to TAP format, because it works with all the emulators without any need for a conversion. TPC is exactly what you get if you write a RMS-11 variable-length-record file with the records you read from a tape. The only "funny" is for odd-length records, because of the 16-bit-word-orientation of RMS-11 there's an extra zero byte padded on the end of the record so the next record begins on a even byte boundary. Most DEC-ish tape formats use even-length records, but there certainly are many exceptions even in the DEC world and certainly lots of odd-length records in the larger world. Another gotcha, not at the container file level but at the ANSI labeled tape level, is that it's entirely legal to have an ANSI labeled tape with two tape marks in a row (for a zero length file) followed by other data. So "double tape mark == end of tape" is not always a good mapping for a tool dealing with tape images. Tim. ###### From: Steve O'Hara-Smith Newsgroups: alt.folklore.computers Subject: Re: Call for information on virtual tape formats Message-ID: <20050316165746.00e5b7ab.steveo@eircom.net> References: <1110987284.154666.321070@g14g2000cwa.googlegroups.com> X-Newsreader: Sylpheed version 1.9.6 (GTK+ 2.4.1; i586-pc-interix3) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Lines: 11 Date: Wed, 16 Mar 2005 16:57:46 +0000 NNTP-Posting-Host: 217.12.14.240 X-Complaints-To: abuse@verio.net X-Trace: newsread1.mlpsca01.us.to.verio.net 1110992170 217.12.14.240 (Wed, 16 Mar 2005 16:56:10 GMT) NNTP-Posting-Date: Wed, 16 Mar 2005 16:56:10 GMT Organization: NTT/VERIO Path: nightfall.franklin.ch!news1.ethz.ch!news-zh.switch.ch!switch.ch!newscore.univie.ac.at!news-fra1.dfn.de!news-lei1.dfn.de!newsfeed.freenet.de!newsfeed.news2me.com!arclight.uoregon.edu!news.u.washington.edu!newspeer1.mlpsca01.us.to.verio.net!verio!newsread1.mlpsca01.us.to.verio.net.POSTED!92c6ff8c!not-for-mail Xref: nightfall.franklin.ch alt.folklore.computers:200498 On 16 Mar 2005 07:34:44 -0800 "Tim Shoppa" wrote: > Another gotcha, not at the container file level but at the ANSI labeled > tape level, is that it's entirely legal to have an ANSI labeled tape > with two tape marks in a row (for a zero length file) followed by other > data. So "double tape mark == end of tape" is not always a good > mapping for a tool dealing with tape images. Seconded - we saw quite a lot of those when we collected tapes from every FI in the country. ###### X-Trace-PostClient-IP: 68.147.129.203 From: Brian Inglis Newsgroups: alt.folklore.computers Subject: Re: Call for information on virtual tape formats Organization: Systematic Software Reply-To: Brian.Inglis@SystematicSW.ab.ca Message-ID: References: <1110987284.154666.321070@g14g2000cwa.googlegroups.com> <20050316165746.00e5b7ab.steveo@eircom.net> X-Newsreader: Forte Agent 1.93/32.576 English (American) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Lines: 22 Date: Wed, 16 Mar 2005 19:00:19 GMT NNTP-Posting-Host: 24.71.223.147 X-Complaints-To: abuse@shaw.ca X-Trace: pd7tw1no 1110999619 24.71.223.147 (Wed, 16 Mar 2005 12:00:19 MST) NNTP-Posting-Date: Wed, 16 Mar 2005 12:00:19 MST Path: nightfall.franklin.ch!news1.ethz.ch!news-zh.switch.ch!switch.ch!solnet.ch!solnet.ch!news.glorb.com!border1.nntp.dca.giganews.com!nntp.giganews.com!pd7cy2so!pd7cy1no!shaw.ca!pd7tw1no.POSTED!53ab2750!not-for-mail Xref: nightfall.franklin.ch alt.folklore.computers:200511 fOn Wed, 16 Mar 2005 16:57:46 +0000 in alt.folklore.computers, Steve O'Hara-Smith wrote: >On 16 Mar 2005 07:34:44 -0800 >"Tim Shoppa" wrote: > >> Another gotcha, not at the container file level but at the ANSI labeled >> tape level, is that it's entirely legal to have an ANSI labeled tape >> with two tape marks in a row (for a zero length file) followed by other >> data. So "double tape mark == end of tape" is not always a good >> mapping for a tool dealing with tape images. > > Seconded - we saw quite a lot of those when we collected tapes >from every FI in the country. Thirded - every shop I've worked at used three TMs for EOT. -- Thanks. Take care, Brian Inglis Calgary, Alberta, Canada Brian.Inglis@CSi.com (Brian[dot]Inglis{at}SystematicSW[dot]ab[dot]ca) fake address use address above to reply ###### From: glen herrmannsfeldt Newsgroups: alt.folklore.computers Subject: Re: Call for information on virtual tape formats Date: Wed, 16 Mar 2005 14:06:27 -0800 Organization: University of Washington Lines: 39 Message-ID: References: NNTP-Posting-Host: 128.208.140.139 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Trace: gnus01.u.washington.edu 1111010711 4637 128.208.140.139 (16 Mar 2005 22:05:11 GMT) X-Complaints-To: help@cac.washington.edu NNTP-Posting-Date: Wed, 16 Mar 2005 22:05:11 +0000 (UTC) User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en In-Reply-To: Path: nightfall.franklin.ch!news1.ethz.ch!news-zh.switch.ch!switch.ch!solnet.ch!solnet.ch!newsfeed.freenet.de!newsfeed.news2me.com!canoe.uoregon.edu!arclight.uoregon.edu!news.u.washington.edu!not-for-mail Xref: nightfall.franklin.ch alt.folklore.computers:200532 Jay Maynard wrote: > On 2005-03-16, Tom Van Vleck wrote: >>Jay Maynard wrote: >>>Are there any other virtual tape formats out there in common, or even >>>uncommon, use? Where might I find documentation on them? >>Multics Standard Tape format: >>http://www.multicians.org/mspm-bb-3-01.html > I see I wasn't clear. Interesting reading, nonetheless. > What I'm looking for is file formats that represent the entire physical tape > as one file, to be fed to an emulator or transported over a network. Instead > of a physical tape with blocks 1224 bytes long, a Multics standard tape > might be represented as a file with a header, 1224 bytes of data, and a > trailer, one group of these for each record on the tape. An emulator might > present this file to a program running on it as though it were a physical > tape mounted on a tape drive. It's a different level of abstraction. > Did I clarify things, or confuse them more? The reason for virtual tape formats is to take into account the variable length blocks when the block information is not otherwise known. If all blocks are the same size, then I would say that a direct byte by byte image, as dd would produce when writing to disk, would qualify as a Multics standard virtual tape format, and so an answer to the original question. That is, a degenerate case of a virtual tape format, hopefully in the uncommon use category. Personally, I like the IBM AWSTAPE format, as it was designed with the ability to do READ BACKWARDS, even though IBM software doesn't support it. That is, the block length is in the block header and block trailer. -- glen ###### NNTP-Posting-Date: Wed, 16 Mar 2005 16:13:56 -0600 Date: Wed, 16 Mar 2005 22:13:58 +0000 From: Brian W Spoor User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4.2) Gecko/20040308 X-Accept-Language: en-us, en MIME-Version: 1.0 Newsgroups: alt.folklore.computers Subject: Re: Call for information on virtual tape formats References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <9PSdnTksY684MqXfRVnyiw@eclipse.net.uk> Lines: 22 NNTP-Posting-Host: 81.168.14.122 X-Trace: sv3-XYFLgALVMpoodcP/tHsfNwMjft1A51Ld4dbvxNlhYdvGRWbVKeQKbeHj0j3dAFoDWq7YP5jV3oAt6VM!Bt5k/j4PkEi00fJkWQooDWp/jC0S/fIAfSluilTVR2CgWuxPadd1yARog03u7Xx9uqnVRqPr1IXX!9h7esx4= X-Complaints-To: abuse@eclipse.net.uk X-DMCA-Complaints-To: abuse@eclipse.net.uk X-Abuse-and-DMCA-Info: Please be sure to forward a copy of ALL headers X-Abuse-and-DMCA-Info: Otherwise we will be unable to process your complaint properly X-Postfilter: 1.3.32 Path: nightfall.franklin.ch!news1.ethz.ch!news-zh.switch.ch!irazu.switch.ch!switch.ch!newsfeed00.sul.t-online.de!t-online.de!border2.nntp.dca.giganews.com!border1.nntp.dca.giganews.com!nntp.giganews.com!local01.nntp.dca.giganews.com!nntp.eclipse.net.uk!news.eclipse.net.uk.POSTED!not-for-mail Xref: nightfall.franklin.ch alt.folklore.computers:200533 > Are there any other virtual tape formats out there in common, or even > uncommon, use? Where might I find documentation on them? The format used by the ICL 1900 series machine's George 3 Emulator:- Byte Stream, where each block is written to the file byte-for-byte, preceded by a 32-bit big-endian word giving the length of the block in bytes, not including the block length word; Tapes Marks are written as a single 32-bit word of -1; Any single error, on transferring data from a tape, is written as a single 32-bit word of -2 A sample tape in this format (zipped) can be found at: http://www.fcs.eu.com/icl1900/libtape.html Details of ICL 1900 magetic tape formats can be found at: http://www.fcs.eu.com/icl1900/mtformat.html The ICL 1900 site can be found at: http://www.fcs.eu.com/index.html I hope to add details of the logical formats to the site soon. ###### From: Leif Harcke Newsgroups: alt.folklore.computers Subject: Re: Call for information on virtual tape formats Date: Wed, 16 Mar 2005 21:59:09 -0800 Organization: Stanford University Lines: 27 Message-ID: References: NNTP-Posting-Host: chirp.stanford.edu Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Trace: news.Stanford.EDU 1111039149 25124 171.64.90.26 (17 Mar 2005 05:59:09 GMT) X-Complaints-To: news@news.stanford.edu User-Agent: Pan/0.14.2 (This is not a psychotic episode. It's a cleansing moment of clarity.) Path: nightfall.franklin.ch!news1.ethz.ch!news-zh.switch.ch!irazu.switch.ch!switch.ch!news.tele.dk!news.tele.dk!small.news.tele.dk!newsfeed.stanford.edu!shelby.stanford.edu!not-for-mail Xref: nightfall.franklin.ch alt.folklore.computers:200585 On Wed, 16 Mar 2005 01:46:08 +0000, Jay Maynard wrote: > Are there any other virtual tape formats out there in common, or even > uncommon, use? Where might I find documentation on them? Here's a description of the format Paul Pierce uses to emulate the IBM 729 tapes on his s709 simulator: http://www.piercefuller.com/oldibm/tool/index.htm Tape images here: http://www.piercefuller.com/oldibm/709x/index.htm Paul's s709 simulator source code here: http://www.piercefuller.com/oldibm/709x/sim/ Dave Pitts' improved s709 simulator here: http://www.cozx.com/~dpitts/ibm7090.html Rob Storey's 7094 emulator here: http://members.optushome.com.au/intaemul/Emul7094.htm -Leif ###### From: Charles Richmond Newsgroups: alt.folklore.computers Subject: Re: Call for information on virtual tape formats Date: Thu, 17 Mar 2005 20:24:16 -0800 Organization: Canine Computer Center Message-ID: <423A57F0.7189889D@plano.net> Reply-To: richmond@nospam.plano.net X-Mailer: Mozilla 4.7C-CCK-MCD {C-UDP; EBM-APPLE} (Macintosh; I; PPC) X-Accept-Language: en MIME-Version: 1.0 References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: abuse@supernews.com Lines: 25 Path: nightfall.franklin.ch!news1.ethz.ch!news-zh.switch.ch!switch.ch!solnet.ch!solnet.ch!news.glorb.com!logbridge.uoregon.edu!newsfeed.stanford.edu!sn-xit-02!sn-xit-01!sn-post-01!supernews.com!corp.supernews.com!not-for-mail Xref: nightfall.franklin.ch alt.folklore.computers:200699 glen herrmannsfeldt wrote: > > [snip...] [snip...] [snip...] > > The reason for virtual tape formats is to take into account the > variable length blocks when the block information is not > otherwise known. If all blocks are the same size, then I would > say that a direct byte by byte image, as dd would produce when > writing to disk, would qualify as a Multics standard virtual > tape format, and so an answer to the original question. > That is, a degenerate case of a virtual tape format, hopefully > in the uncommon use category. > How many sectors does it take for a virtual 1/2" record separator??? "Do I add an egg??? ... It's a candy bar!!!" ;-) -- +----------------------------------------------------------------+ | Charles and Francis Richmond It is moral cowardice to leave | | undone what one perceives right | | richmond at plano dot net to do. -- Confucius | +----------------------------------------------------------------+ ###### From: prep@prep.synonet.com Newsgroups: alt.folklore.computers Subject: Re: Call for information on virtual tape formats Date: Mon, 21 Mar 2005 23:37:48 +0800 Organization: none Lines: 19 Message-ID: <87eke9c8mr.fsf@prep.synonet.com> References: <1110987284.154666.321070@g14g2000cwa.googlegroups.com> NNTP-Posting-Host: grimiore.conceptual.net.au Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: nnrp.waia.asn.au 1111421324 8816 203.190.192.5 (21 Mar 2005 16:08:44 GMT) X-Complaints-To: usenet@nnrp.waia.asn.au NNTP-Posting-Date: Mon, 21 Mar 2005 16:08:44 +0000 (UTC) User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) Cancel-Lock: sha1:hX3N+QvoSLW4gL2FKuo7xF7smBM= Cache-Post-Path: grimiore.conceptual.net.au!unknown@203-190-195-215.dial.usertools.net X-Cache: nntpcache 2.3.3 (see http://www.nntpcache.org/) Path: nightfall.franklin.ch!news1.ethz.ch!news-zh.switch.ch!switch.ch!news.ip-plus.net!newsfeed.ip-plus.net!news.tesion.net!news.belwue.de!news.tu-darmstadt.de!tsicnews.teliasonera.com!newshosting.com!nx02.iad01.newshosting.com!diablo.voicenet.com!216.196.98.140.MISMATCH!border1.nntp.dca.giganews.com!nntp.giganews.com!nntp.waia.asn.au!198.32.212.248.MISMATCH!nnrp.waia.asn.au!127.0.0.1!nobody Xref: nightfall.franklin.ch alt.folklore.computers:201124 "Tim Shoppa" writes: > Another gotcha, not at the container file level but at the ANSI > labeled tape level, is that it's entirely legal to have an ANSI > labeled tape with two tape marks in a row (for a zero length file) > followed by other data. So "double tape mark == end of tape" is not > always a good mapping for a tool dealing with tape images. The real problem is that two sequential tape marks are not a double tape mark. the later should have exactly 4 character spaces between each mark, the former has a full inter-record gap. -- Paul Repacholi 1 Crescent Rd., +61 (08) 9257-1001 Kalamunda. West Australia 6076 comp.os.vms,- The Older, Grumpier Slashdot Raw, Cooked or Well-done, it's all half baked. EPIC, The Architecture of the future, always has been, always will be. ###### Newsgroups: alt.folklore.computers From: Jay Maynard Subject: Re: Call for information on virtual tape formats References: <1110987284.154666.321070@g14g2000cwa.googlegroups.com> <87eke9c8mr.fsf@prep.synonet.com> Reply-To: jmaynard@conmicro.cx Message-ID: User-Agent: slrn/0.9.8.0 (Linux) Lines: 26 Date: Mon, 21 Mar 2005 17:09:01 GMT NNTP-Posting-Host: 206.146.76.206 X-Complaints-To: abuse@onvoy.com X-Trace: news7.onvoy.net 1111424941 206.146.76.206 (Mon, 21 Mar 2005 11:09:01 CST) NNTP-Posting-Date: Mon, 21 Mar 2005 11:09:01 CST Organization: Onvoy Path: nightfall.franklin.ch!news1.ethz.ch!news-zh.switch.ch!irazu.switch.ch!switch.ch!news.belwue.de!feed.news.tiscali.de!news.netplace.de!news-FFM2.ecrc.net!logbridge.uoregon.edu!pln-e!lotsanews.com!upp1.onvoy!onvoy.com!news7.onvoy.net.POSTED!not-for-mail Xref: nightfall.franklin.ch alt.folklore.computers:201127 Grumble. I see I've missed several messages in this thread... "Tim Shoppa" writes: > Another gotcha, not at the container file level but at the ANSI > labeled tape level, is that it's entirely legal to have an ANSI > labeled tape with two tape marks in a row (for a zero length file) > followed by other data. So "double tape mark == end of tape" is not > always a good mapping for a tool dealing with tape images. I do not plan to use anything but EOF of the disk file as end of tape. Interpreting the data is best left to the emulators and the programs running on them, or specific data conversion tools (which I do plan to have a few of in the package, but all will allow specifying any file on the virtual tape by number). I, too, have seen many cases where two tapemarks (or a double tapemark, in cases where they're different; many systems treat the two identically) are present in between valid data files. I got Brian's info, and a Google Groups search brought forth Paul Pierce's page. I will be dealing with both. While I'm here, the first extension I've done is to make vtapelist interpret ANSI tape labels, in both ASCII and EBCDIC character sets. I worked from the IBM tape label book, since that's what I'm familiar with (being an old MVS sysprog). Are there other systems out there that claim to do ANSI standard labels and get heartburn with the IBM version? If so, where might I find documentation? ###### Newsgroups: alt.folklore.computers From: Jay Maynard Subject: Re: Call for information on virtual tape formats References: Reply-To: jmaynard@conmicro.cx Message-ID: User-Agent: slrn/0.9.8.0 (Linux) Lines: 11 Date: Mon, 21 Mar 2005 17:11:00 GMT NNTP-Posting-Host: 206.146.76.206 X-Complaints-To: abuse@onvoy.com X-Trace: news7.onvoy.net 1111425060 206.146.76.206 (Mon, 21 Mar 2005 11:11:00 CST) NNTP-Posting-Date: Mon, 21 Mar 2005 11:11:00 CST Organization: Onvoy Path: nightfall.franklin.ch!news1.ethz.ch!news-zh.switch.ch!switch.ch!solnet.ch!solnet.ch!news.glorb.com!newsfeeds.sol.net!newspump.sol.net!upp1.onvoy!onvoy.com!news7.onvoy.net.POSTED!not-for-mail Xref: nightfall.franklin.ch alt.folklore.computers:201128 On 2005-03-16, glen herrmannsfeldt wrote: > Personally, I like the IBM AWSTAPE format, as it was designed > with the ability to do READ BACKWARDS, even though IBM software > doesn't support it. That is, the block length is in the block > header and block trailer. TAP format also has this ability: the header is repeated after the data block for nonzero block lengths. AWSTAPE doesn't have a block trailer, really; it's just that the next block header can serve, since it has the previous block length in it. ###### From: "Tim Shoppa" Newsgroups: alt.folklore.computers Subject: Re: Call for information on virtual tape formats Date: 22 Mar 2005 05:00:14 -0800 Organization: http://groups.google.com Lines: 35 Message-ID: <1111496414.624516.73550@o13g2000cwo.googlegroups.com> References: <1110987284.154666.321070@g14g2000cwa.googlegroups.com> <87eke9c8mr.fsf@prep.synonet.com> NNTP-Posting-Host: 170.121.15.35 Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Trace: posting.google.com 1111496418 27604 127.0.0.1 (22 Mar 2005 13:00:18 GMT) X-Complaints-To: groups-abuse@google.com NNTP-Posting-Date: Tue, 22 Mar 2005 13:00:18 +0000 (UTC) In-Reply-To: User-Agent: G2/0.2 Complaints-To: groups-abuse@google.com Injection-Info: o13g2000cwo.googlegroups.com; posting-host=170.121.15.35; posting-account=mAyfxAwAAABWbrxnXxYpn9RczUJc3B8w Path: nightfall.franklin.ch!news1.ethz.ch!news-zh.switch.ch!irazu.switch.ch!switch.ch!news.maxwell.syr.edu!postnews.google.com!o13g2000cwo.googlegroups.com!not-for-mail Xref: nightfall.franklin.ch alt.folklore.computers:201243 > Are there other systems out there that claim to do > ANSI standard labels and get heartburn > with the IBM version? One matter-of-interpretation is that some DEC OS's (for example RT-11 prior to V5.5 or so) write the tape labels with 512-byte blocks instead of the usual 80-byte blocks when doing ANSI labeled tapes. The way the standard was interpreted, was that the standard didn't actually say that the block has to be 80 bytes, only that it specified what was in the first 80 bytes. Just to confuse things even more, some DEC OS's (like VMS) insist that ANSI labels be only 80 byte records, so moving a tape between DEC OS's sometimes required some work (depending on version numbers...) There was also some liberal interpretation of the standard to allow boot blocks to go at the beginning of the tape while the tape still being ANSI-ish. Most minicomputer OS's had limits about how long physical and logical records could be. And there are occasional tapes that use ridiculously long physical records (megabytes!). TPC, with a 2-byte record length, doesn't deal well with these super-long records. Another gotcha, outside the realm of ANSI labeled tapes, is DOS-11 tapes. DOS-11 tape label records are just 14 bytes long, and some tape hardware does not do well with records so short. As long as you never go back to real physical tapes and always stick with tape images, I don't think there's a problem. Tim. ###### NNTP-Posting-Date: Tue, 22 Mar 2005 08:21:35 -0600 Newsgroups: alt.folklore.computers From: jmfbahciv@aol.com Subject: Re: Call for information on virtual tape formats Organization: UltraNet Communications, Inc. References: <1110987284.154666.321070@g14g2000cwa.googlegroups.com> <87eke9c8mr.fsf@prep.synonet.com> <1111496414.624516.73550@o13g2000cwo.googlegroups.com> X-Newsreader: News Xpress Version 1.0 Beta #4 Date: Tue, 22 Mar 05 13:26:43 GMT Message-ID: Lines: 25 NNTP-Posting-Host: 207.172.216.16 X-Trace: sv3-V0Rd4QX6QywyONvVM/bQKV0FKaF8Fb0F+XPoKJGKVhj00sYflzIjKRDyeo70JL6NLBT7yymahn4OtKn!JBZVBnUMRTYvmXxETyygvY69Zo0yBfsgJKtaulzjmRXHpyCavLBYiOVVvX2LV121jA== X-Complaints-To: abuse@rcn.net X-DMCA-Complaints-To: abuse@rcn.net X-Abuse-and-DMCA-Info: Please be sure to forward a copy of ALL headers X-Abuse-and-DMCA-Info: Otherwise we will be unable to process your complaint properly X-Postfilter: 1.3.32 Path: nightfall.franklin.ch!news1.ethz.ch!news-zh.switch.ch!switch.ch!solnet.ch!solnet.ch!news.glorb.com!border1.nntp.dca.giganews.com!nntp.giganews.com!local01.nntp.dca.giganews.com!nntp.rcn.net!news.rcn.net.POSTED!not-for-mail Xref: nightfall.franklin.ch alt.folklore.computers:201255 In article , Jay Maynard wrote: >On 2005-03-22, Tim Shoppa wrote: >> One matter-of-interpretation is that some DEC OS's (for example RT-11 >> prior to V5.5 or so) write the tape labels with 512-byte blocks instead >> of the usual 80-byte blocks when doing ANSI labeled tapes. The way the >> standard was interpreted, was that the standard didn't actually say >> that the block has to be 80 bytes, only that it specified what was in >> the first 80 bytes. > >Blarg. I know that IBM OSes will treat such tapes as nonlabeled. > >> There was also some liberal interpretation of the standard to allow >> boot blocks to go at the beginning of the tape while the tape still >> being ANSI-ish. > >Hm. ANSI-ish is right. It was easier to play whack-a-mole than implement ANSI-labels. /BAH Subtract a hundred and four for e-mail. ###### Newsgroups: alt.folklore.computers From: Jay Maynard Subject: Re: Call for information on virtual tape formats References: <1110987284.154666.321070@g14g2000cwa.googlegroups.com> <87eke9c8mr.fsf@prep.synonet.com> <1111496414.624516.73550@o13g2000cwo.googlegroups.com> Reply-To: jmaynard@conmicro.cx Message-ID: User-Agent: slrn/0.9.8.0 (Linux) Lines: 37 Date: Tue, 22 Mar 2005 13:46:04 GMT NNTP-Posting-Host: 206.146.76.206 X-Complaints-To: abuse@onvoy.com X-Trace: news7.onvoy.net 1111499164 206.146.76.206 (Tue, 22 Mar 2005 07:46:04 CST) NNTP-Posting-Date: Tue, 22 Mar 2005 07:46:04 CST Organization: Onvoy Path: nightfall.franklin.ch!news1.ethz.ch!news-zh.switch.ch!switch.ch!news.imp.ch!news.imp.ch!209.11.36.156.MISMATCH!nntp-server.pubsub.com!news.glorb.com!mpls-transit-01.news.qwest.net!ply1.onvoy!upp1.onvoy!onvoy.com!news7.onvoy.net.POSTED!not-for-mail Xref: nightfall.franklin.ch alt.folklore.computers:201252 On 2005-03-22, Tim Shoppa wrote: > One matter-of-interpretation is that some DEC OS's (for example RT-11 > prior to V5.5 or so) write the tape labels with 512-byte blocks instead > of the usual 80-byte blocks when doing ANSI labeled tapes. The way the > standard was interpreted, was that the standard didn't actually say > that the block has to be 80 bytes, only that it specified what was in > the first 80 bytes. Blarg. I know that IBM OSes will treat such tapes as nonlabeled. > There was also some liberal interpretation of the standard to allow > boot blocks to go at the beginning of the tape while the tape still > being ANSI-ish. Hm. ANSI-ish is right. > Most minicomputer OS's had limits about how long physical and logical > records could be. And there are occasional tapes that use ridiculously > long physical records (megabytes!). TPC, with a 2-byte record length, > doesn't deal well with these super-long records. Yeah. TAP, for that matter, would have trouble dealing with geophysical data, with records sometimes over 100 MB long. AWSTAPE itself has no such restriction, although most AWSTAPE processors would. > Another gotcha, outside the realm of ANSI labeled tapes, is DOS-11 tapes. > DOS-11 tape label records are just 14 bytes long, and some tape hardware > does not do well with records so short. As long as you never go back to > real physical tapes and always stick with tape images, I don't think > there's a problem. No, that wouldn't be. Getting the tape to a virtual tape file would get intereting, though; you'd have to use a tape drive that didn't throw away records shorter than 18 bytes as noise. I don't know of any that don't, though that's mainly because the thought never crossed my mind that it might be necessary. In any event, as you point out, that's not a problem so long as you're dealing strictl with virtual tape images. ###### From: "Tim Shoppa" Newsgroups: alt.folklore.computers Subject: Re: Call for information on virtual tape formats Date: 22 Mar 2005 06:18:01 -0800 Organization: http://groups.google.com Lines: 13 Message-ID: <1111501081.082591.87850@o13g2000cwo.googlegroups.com> References: <423A57F0.7189889D@plano.net> NNTP-Posting-Host: 170.121.15.35 Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Trace: posting.google.com 1111501085 1193 127.0.0.1 (22 Mar 2005 14:18:05 GMT) X-Complaints-To: groups-abuse@google.com NNTP-Posting-Date: Tue, 22 Mar 2005 14:18:05 +0000 (UTC) In-Reply-To: <423A57F0.7189889D@plano.net> User-Agent: G2/0.2 Complaints-To: groups-abuse@google.com Injection-Info: o13g2000cwo.googlegroups.com; posting-host=170.121.15.35; posting-account=mAyfxAwAAABWbrxnXxYpn9RczUJc3B8w Path: nightfall.franklin.ch!news1.ethz.ch!news-zh.switch.ch!switch.ch!solnet.ch!solnet.ch!proxad.net!216.239.36.134.MISMATCH!postnews.google.com!o13g2000cwo.googlegroups.com!not-for-mail Xref: nightfall.franklin.ch alt.folklore.computers:201254 > How many sectors does it take for a virtual 1/2" record separator??? Much/most hardware supported "write long gap" and sometimes this support worked its way higher in the interface to the application and OS level and filesystem level. I see and appreciate the intention of adding this "feature" decades ago... and I see the simplicity of many virtual tape container formats... and my gut feeling is that any attempts to destroy the simplicity should be "nipped in the bud" (my favorite Barney Fife phrase of the day. Any attempt at adding complexity today, I'll reflexively shout out "Nip it in the bud!"). Tim. ###### Date: 22 Mar 2005 15:53:28 -0000 Message-ID: From: "Don Salad" Subject: Re: Call for information on virtual tape formats Newsgroups: alt.folklore.computers,alt.religion.kibology Followup-To: alt.folklore.computers,alt.religion.kibology,alt.usenet.kooks References: Comments: This message probably did not originate at the above address. It was automatically remailed by one or more anonymous remailers. Please use abuse@dingoremailer.com to report abuse X-Remailer-Contact: Anonymous Mailer X-Spam-Processed: dingoremailer.com, Tue, 22 Mar 2005 09:53:30 -0600 (not processed: message from valid local sender) X-Return-Path: dingobounce@dingoremailer.com X-MDaemon-Deliver-To: mail2news@news.gradwell.net Lines: 10 NNTP-Posting-Date: 22 Mar 2005 15:53:28 GMT NNTP-Posting-Host: 193.111.200.92 X-Trace: 1111506808 news.gradwell.net 38044 mail2news/193.111.200.92 X-Complaints-To: news-abuse@gradwell.net Path: nightfall.franklin.ch!news1.ethz.ch!news-zh.switch.ch!irazu.switch.ch!switch.ch!news.tele.dk!news.tele.dk!small.news.tele.dk!newsfeed1.e.nsc.no!peernews.cix.co.uk!zen.net.uk!dedekind.zen.co.uk!news.anlx.net!caladan!news-peer-lilac.gradwell.net!not-for-mail Xref: nightfall.franklin.ch alt.folklore.computers:201259 > Are there any other virtual tape formats out there in common, or even > uncommon, use? Where might I find documentation on them? For most purposes I prefer duct tape. It's worth paying for "Scotch" or "Duck" because the cheap ones don't last as long and are messier to tear. Thanks. ###### From: glen herrmannsfeldt Newsgroups: alt.folklore.computers Subject: Re: Call for information on virtual tape formats Date: Tue, 22 Mar 2005 11:59:53 -0800 Organization: University of Washington Lines: 60 Message-ID: References: <1110987284.154666.321070@g14g2000cwa.googlegroups.com> <87eke9c8mr.fsf@prep.synonet.com> <1111496414.624516.73550@o13g2000cwo.googlegroups.com> NNTP-Posting-Host: 128.208.140.139 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Trace: gnus01.u.washington.edu 1111521595 25974 128.208.140.139 (22 Mar 2005 19:59:55 GMT) X-Complaints-To: help@cac.washington.edu NNTP-Posting-Date: Tue, 22 Mar 2005 19:59:55 +0000 (UTC) User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en In-Reply-To: <1111496414.624516.73550@o13g2000cwo.googlegroups.com> Path: nightfall.franklin.ch!news1.ethz.ch!news-zh.switch.ch!switch.ch!solnet.ch!solnet.ch!news.glorb.com!hammer.uoregon.edu!arclight.uoregon.edu!news.u.washington.edu!not-for-mail Xref: nightfall.franklin.ch alt.folklore.computers:201277 Tim Shoppa wrote: >>Are there other systems out there that claim to do >>ANSI standard labels and get heartburn >>with the IBM version? > One matter-of-interpretation is that some DEC OS's (for example RT-11 > prior to V5.5 or so) write the tape labels with 512-byte blocks instead > of the usual 80-byte blocks when doing ANSI labeled tapes. The way the > standard was interpreted, was that the standard didn't actually say > that the block has to be 80 bytes, only that it specified what was in > the first 80 bytes. Well, there are tape systems that can only write 512 byte blocks, most of the QIC formats. Some were designed around floppy disk controllers. > Just to confuse things even more, some DEC OS's (like VMS) insist > that ANSI labels be only 80 byte records, so moving a tape between > DEC OS's sometimes required some work (depending on version numbers...) > There was also some liberal interpretation of the standard to allow > boot blocks to go at the beginning of the tape while the tape still > being ANSI-ish. IBM S/360 style disks put the label on the 3rd block, so that IPL records can go on blocks 0 and 1. I would expect, then, that IPLable tapes can't be SL or AL. > Most minicomputer OS's had limits about how long physical and logical > records could be. And there are occasional tapes that use ridiculously > long physical records (megabytes!). TPC, with a 2-byte record length, > doesn't deal well with these super-long records. There are stories of people writing tapes with one (very long) record on S/370 using data chaining. That is, more than on CCW per tape block. > Another gotcha, outside the realm of ANSI labeled tapes, is >DOS-11 tapes. DOS-11 tape label records are just 14 bytes long, > and some tape hardware does not do well with records so short. > As long as you never go back to real physical tapes and always > stick with tape images, I don't think there's a problem. IBM mainframes will consider an error in reading a short block as noise, but I believe if it reads without error it is fine. Read errors were much more of a problem on 800 BPI (NRZI coded) tapes than on 1600 BPI (PE) or 6250 (GCR). NRZI depends on there being at least one transition per character, so must be odd parity. It is, then, very sensitive to head azimuth. All tracks are clocked together. PE and GCR clock each track separately, and so are much less sensitive to head azimuth. New or old, reading 800 BPI tapes on a different machine was never easy. You could always write a virtual tape file on a real tape. -- glen ###### Newsgroups: alt.folklore.computers From: Jay Maynard Subject: Re: Call for information on virtual tape formats References: <1110987284.154666.321070@g14g2000cwa.googlegroups.com> <87eke9c8mr.fsf@prep.synonet.com> <1111496414.624516.73550@o13g2000cwo.googlegroups.com> Reply-To: jmaynard@conmicro.cx Message-ID: User-Agent: slrn/0.9.8.0 (Linux) Lines: 31 Date: Tue, 22 Mar 2005 20:32:27 GMT NNTP-Posting-Host: 206.146.76.206 X-Complaints-To: abuse@onvoy.com X-Trace: news7.onvoy.net 1111523547 206.146.76.206 (Tue, 22 Mar 2005 14:32:27 CST) NNTP-Posting-Date: Tue, 22 Mar 2005 14:32:27 CST Organization: Onvoy Path: nightfall.franklin.ch!news1.ethz.ch!news-zh.switch.ch!switch.ch!solnet.ch!solnet.ch!newsfeed.freenet.de!newsfeed.news2me.com!canoe.uoregon.edu!hammer.uoregon.edu!logbridge.uoregon.edu!pln-e!lotsanews.com!upp1.onvoy!onvoy.com!news7.onvoy.net.POSTED!not-for-mail Xref: nightfall.franklin.ch alt.folklore.computers:201280 On 2005-03-22, glen herrmannsfeldt wrote: > IBM S/360 style disks put the label on the 3rd block, so that > IPL records can go on blocks 0 and 1. I would expect, then, > that IPLable tapes can't be SL or AL. Not that I've ever seen, no...although you could get there by hitting LOAD twice (once to IPL the label, which will fail, and once to IPL the actual program). > There are stories of people writing tapes with one (very long) > record on S/370 using data chaining. That is, more than on CCW > per tape block. It was common for geophysical data to be written as one loooooong record, taking up an entire tape. They had pretty stiff throughput/latency requirements while recording that make record gaps unacceptable. It made for some really fun APAR discussions with IBM, at one point: I no longer remember the details, but it amounted to IBM placing a restriction on a buffer that no longer made sense with a 2 GB address space. > IBM mainframes will consider an error in reading a short block > as noise, but I believe if it reads without error it is fine. Really? I'll have to take your word for it, never having done that. > New or old, reading 800 BPI tapes on a different machine was > never easy. No kidding. I've had very poor luck reading 800 BPI tapes on my 9-track drive, but 1600 and 6250 work quite well (as long as they're not MRX V with the binder migration problem). ###### X-Trace-PostClient-IP: 68.147.129.203 From: Brian Inglis Newsgroups: alt.folklore.computers Subject: Re: Call for information on virtual tape formats Organization: Systematic Software Reply-To: Brian.Inglis@SystematicSW.ab.ca Message-ID: References: <423A57F0.7189889D@plano.net> X-Newsreader: Forte Agent 1.93/32.576 English (American) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Lines: 12 Date: Tue, 22 Mar 2005 21:26:04 GMT NNTP-Posting-Host: 24.71.223.147 X-Complaints-To: abuse@shaw.ca X-Trace: pd7tw2no 1111526764 24.71.223.147 (Tue, 22 Mar 2005 14:26:04 MST) NNTP-Posting-Date: Tue, 22 Mar 2005 14:26:04 MST Path: nightfall.franklin.ch!news1.ethz.ch!news-zh.switch.ch!irazu.switch.ch!switch.ch!newsfeed00.sul.t-online.de!t-online.de!newshub.sdsu.edu!elnk-nf2-pas!elnk-pas-nf1!newsfeed.earthlink.net!pd7cy1no!shaw.ca!pd7tw2no.POSTED!53ab2750!not-for-mail Xref: nightfall.franklin.ch alt.folklore.computers:201290 On Thu, 17 Mar 2005 20:24:16 -0800 in alt.folklore.computers, Charles Richmond wrote: >How many sectors does it take for a virtual 1/2" record separator??? ISTR it was 0.3" PE or was that only with 6250bpi GCR? -- Thanks. Take care, Brian Inglis Calgary, Alberta, Canada Brian.Inglis@CSi.com (Brian[dot]Inglis{at}SystematicSW[dot]ab[dot]ca) fake address use address above to reply ###### X-Trace-PostClient-IP: 68.147.129.203 From: Brian Inglis Newsgroups: alt.folklore.computers Subject: Re: Call for information on virtual tape formats Organization: Systematic Software Reply-To: Brian.Inglis@SystematicSW.ab.ca Message-ID: <6f3141d8keoq03j63r3pbo2lkjvvjke8ab@4ax.com> References: <1110987284.154666.321070@g14g2000cwa.googlegroups.com> <87eke9c8mr.fsf@prep.synonet.com> <1111496414.624516.73550@o13g2000cwo.googlegroups.com> X-Newsreader: Forte Agent 1.93/32.576 English (American) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Lines: 18 Date: Tue, 22 Mar 2005 21:29:42 GMT NNTP-Posting-Host: 24.71.223.147 X-Complaints-To: abuse@shaw.ca X-Trace: pd7tw2no 1111526982 24.71.223.147 (Tue, 22 Mar 2005 14:29:42 MST) NNTP-Posting-Date: Tue, 22 Mar 2005 14:29:42 MST Path: nightfall.franklin.ch!news1.ethz.ch!news-zh.switch.ch!irazu.switch.ch!switch.ch!newsfeed00.sul.t-online.de!t-online.de!border2.nntp.dca.giganews.com!border1.nntp.dca.giganews.com!nntp.giganews.com!pd7cy2so!pd7cy1no!shaw.ca!pd7tw2no.POSTED!53ab2750!not-for-mail Xref: nightfall.franklin.ch alt.folklore.computers:201291 On 22 Mar 2005 05:00:14 -0800 in alt.folklore.computers, "Tim Shoppa" wrote: >Another gotcha, outside the realm of ANSI labeled tapes, is DOS-11 tapes. >DOS-11 tape label records are just 14 bytes long, and some tape hardware >does not do well with records so short. As long as you never go back to >real physical tapes and always stick with tape images, I don't think >there's a problem. ISTR 14 bytes minimum block length was a DEC standard for their tape drives. I can't remember what the limit was for IBM 3420s? -- Thanks. Take care, Brian Inglis Calgary, Alberta, Canada Brian.Inglis@CSi.com (Brian[dot]Inglis{at}SystematicSW[dot]ab[dot]ca) fake address use address above to reply ###### Newsgroups: alt.folklore.computers From: Jay Maynard Subject: Re: Call for information on virtual tape formats References: <1110987284.154666.321070@g14g2000cwa.googlegroups.com> <87eke9c8mr.fsf@prep.synonet.com> <1111496414.624516.73550@o13g2000cwo.googlegroups.com> <6f3141d8keoq03j63r3pbo2lkjvvjke8ab@4ax.com> Reply-To: jmaynard@conmicro.cx Message-ID: User-Agent: slrn/0.9.8.0 (Linux) Lines: 12 Date: Tue, 22 Mar 2005 21:38:52 GMT NNTP-Posting-Host: 206.146.76.206 X-Complaints-To: abuse@onvoy.com X-Trace: news7.onvoy.net 1111527532 206.146.76.206 (Tue, 22 Mar 2005 15:38:52 CST) NNTP-Posting-Date: Tue, 22 Mar 2005 15:38:52 CST Organization: Onvoy Path: nightfall.franklin.ch!news1.ethz.ch!news-zh.switch.ch!irazu.switch.ch!switch.ch!newsmi-eu.news.garr.it!newsmi-us.news.garr.it!NewsITBone-GARR!hammer.uoregon.edu!logbridge.uoregon.edu!pln-e!lotsanews.com!upp1.onvoy!onvoy.com!news7.onvoy.net.POSTED!not-for-mail Xref: nightfall.franklin.ch alt.folklore.computers:201292 On 2005-03-22, Brian Inglis wrote: > On 22 Mar 2005 05:00:14 -0800 in alt.folklore.computers, "Tim Shoppa" > wrote: >>Another gotcha, outside the realm of ANSI labeled tapes, is DOS-11 tapes. >>DOS-11 tape label records are just 14 bytes long, and some tape hardware >>does not do well with records so short. As long as you never go back to >>real physical tapes and always stick with tape images, I don't think >>there's a problem. > ISTR 14 bytes minimum block length was a DEC standard for their tape > drives. I can't remember what the limit was for IBM 3420s? 18 bytes. ###### From: arargh502NOSPAM@NOW.AT.arargh.com Newsgroups: alt.folklore.computers Subject: Re: Call for information on virtual tape formats Date: Tue, 22 Mar 2005 19:55:30 -0600 Organization: Not Really! Lines: 26 Message-ID: References: <1110987284.154666.321070@g14g2000cwa.googlegroups.com> <87eke9c8mr.fsf@prep.synonet.com> <1111496414.624516.73550@o13g2000cwo.googlegroups.com> NNTP-Posting-Host: tcr93.dynip.ripco.net Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Trace: e250.ripco.com 1111542976 5360 209.100.226.93 (23 Mar 2005 01:56:16 GMT) X-Complaints-To: usenet@ripco.com NNTP-Posting-Date: Wed, 23 Mar 2005 01:56:16 +0000 (UTC) X-Newsreader: Forte Agent 1.92/32.572 Path: nightfall.franklin.ch!news1.ethz.ch!news-zh.switch.ch!switch.ch!solnet.ch!solnet.ch!news.glorb.com!gail.ripco.com!not-for-mail Xref: nightfall.franklin.ch alt.folklore.computers:201328 On Tue, 22 Mar 2005 20:32:27 GMT, Jay Maynard wrote: >On 2005-03-22, glen herrmannsfeldt wrote: >> IBM S/360 style disks put the label on the 3rd block, so that >> IPL records can go on blocks 0 and 1. I would expect, then, >> that IPLable tapes can't be SL or AL. > >Not that I've ever seen, no...although you could get there by hitting LOAD >twice (once to IPL the label, which will fail, and once to IPL the actual >program). More: Label, (any user labels), T/M, Boot Record. Hopefully only the Boot Record actually does anything. At a PPOE, we had a bootable code dump program. The boot record wrote the first 32k of core to the tape, following the boot record. Then you had to keep hitting IPL to find the formatting program, which was futher down on the tape. -- Arargh502 at [drop the 'http://www.' from ->] http://www.arargh.com BCET Basic Compiler Page: http://www.arargh.com/basic/index.html To reply by email, remove the garbage from the reply address. ###### From: glen herrmannsfeldt Newsgroups: alt.folklore.computers Subject: Re: Call for information on virtual tape formats Date: Tue, 22 Mar 2005 18:15:10 -0800 Organization: University of Washington Lines: 27 Message-ID: References: <1110987284.154666.321070@g14g2000cwa.googlegroups.com> <87eke9c8mr.fsf@prep.synonet.com> <1111496414.624516.73550@o13g2000cwo.googlegroups.com> <6f3141d8keoq03j63r3pbo2lkjvvjke8ab@4ax.com> NNTP-Posting-Host: 128.208.140.139 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Trace: gnus01.u.washington.edu 1111544139 11772 128.208.140.139 (23 Mar 2005 02:15:39 GMT) X-Complaints-To: help@cac.washington.edu NNTP-Posting-Date: Wed, 23 Mar 2005 02:15:39 +0000 (UTC) User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en In-Reply-To: Path: nightfall.franklin.ch!news1.ethz.ch!news-zh.switch.ch!switch.ch!solnet.ch!solnet.ch!news.glorb.com!hammer.uoregon.edu!arclight.uoregon.edu!news.u.washington.edu!not-for-mail Xref: nightfall.franklin.ch alt.folklore.computers:201331 Jay Maynard wrote: (someone wrote) >>ISTR 14 bytes minimum block length was a DEC standard for their tape >> drives. I can't remember what the limit was for IBM 3420s? > 18 bytes. (for write operation) "To facilitate noise recognition, a minimum block length of 18 bytes is recommended. (To provide safety, the minimum block length is larger for write then for read. Tapes written by other than a 2400 tape unit may be read.) (also) "Note: To facilitate noise recognition, a minimum block length of 12 bytes is recommended for read and read backwards operations." It does say recommended, and not required. Besides, with BLKSIZE=1 a very large fraction of your tape is gaps! -- glen ###### From: "Dennis Ritchie" Newsgroups: alt.folklore.computers Subject: Re: Call for information on virtual tape formats Date: Wed, 23 Mar 2005 06:09:24 -0000 Organization: Bell Labs Lines: 24 Message-ID: <3acf75F698kt2U1@individual.net> References: <1110987284.154666.321070@g14g2000cwa.googlegroups.com> <87eke9c8mr.fsf@prep.synonet.com> <1111496414.624516.73550@o13g2000cwo.googlegroups.com> <6f3141d8keoq03j63r3pbo2lkjvvjke8ab@4ax.com> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Trace: individual.net Rhg5grO+XWJwGpjw4S49Vw0dUOQ0QkSmX/X8y6jf7dkgeiTSD9 X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 5.00.2919.6600 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Path: nightfall.franklin.ch!news1.ethz.ch!news-zh.switch.ch!switch.ch!solnet.ch!solnet.ch!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail Xref: nightfall.franklin.ch alt.folklore.computers:201350 "glen herrmannsfeldt" wrote in message news:d1qjgb$bfs$1@gnus01.u.washington.edu... .... > "Note: To facilitate noise recognition, a minimum block length > of 12 bytes is recommended for read and read backwards operations." > > It does say recommended, and not required. > > Besides, with BLKSIZE=1 a very large fraction of your tape is gaps! My slightly related tape story: In early Unix, the system supported serial byte-at-a-time writes to blocked magtape. If you did this, it would add the byte to the buffer, back up the drive, and rewrite the block. The mechanics or logic of the drive/controller would position the rewritten block just slightly further along. Thus the 512-byte records would migrate along the tape, creating huge gaps. (And of course the drive made peculiar sounds during the writing). The tapes were readable, though. Dennis ###### X-Trace-PostClient-IP: 68.147.129.203 From: Brian Inglis Newsgroups: alt.folklore.computers Subject: Re: Call for information on virtual tape formats Organization: Systematic Software Reply-To: Brian.Inglis@SystematicSW.ab.ca Message-ID: References: <1110987284.154666.321070@g14g2000cwa.googlegroups.com> <87eke9c8mr.fsf@prep.synonet.com> <1111496414.624516.73550@o13g2000cwo.googlegroups.com> <6f3141d8keoq03j63r3pbo2lkjvvjke8ab@4ax.com> X-Newsreader: Forte Agent 1.93/32.576 English (American) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Lines: 35 Date: Wed, 23 Mar 2005 16:22:20 GMT NNTP-Posting-Host: 24.71.223.147 X-Complaints-To: abuse@shaw.ca X-Trace: pd7tw2no 1111594940 24.71.223.147 (Wed, 23 Mar 2005 09:22:20 MST) NNTP-Posting-Date: Wed, 23 Mar 2005 09:22:20 MST Path: nightfall.franklin.ch!news1.ethz.ch!news-zh.switch.ch!irazu.switch.ch!switch.ch!news.tele.dk!news.tele.dk!small.news.tele.dk!feed.cgocable.net!pd7cy1no!shaw.ca!pd7tw2no.POSTED!53ab2750!not-for-mail Xref: nightfall.franklin.ch alt.folklore.computers:201408 fOn Tue, 22 Mar 2005 18:15:10 -0800 in alt.folklore.computers, glen herrmannsfeldt wrote: >Jay Maynard wrote: > >(someone wrote) > >>>ISTR 14 bytes minimum block length was a DEC standard for their tape >>>drives. I can't remember what the limit was for IBM 3420s? > >> 18 bytes. > >(for write operation) >"To facilitate noise recognition, a minimum block length >of 18 bytes is recommended. (To provide safety, the minimum >block length is larger for write then for read. Tapes written >by other than a 2400 tape unit may be read.) > >(also) > >"Note: To facilitate noise recognition, a minimum block length >of 12 bytes is recommended for read and read backwards operations." > >It does say recommended, and not required. > >Besides, with BLKSIZE=1 a very large fraction of your tape is gaps! As a manager found out, who insisted we write an external interchange "tape" with 80 byte blocks, and got back a box! -- Thanks. Take care, Brian Inglis Calgary, Alberta, Canada Brian.Inglis@CSi.com (Brian[dot]Inglis{at}SystematicSW[dot]ab[dot]ca) fake address use address above to reply ###### From: Joe Morris Newsgroups: alt.folklore.computers Subject: Re: Call for information on virtual tape formats Date: Wed, 23 Mar 2005 18:13:23 +0000 (UTC) Organization: The MITRE Organization Lines: 33 Message-ID: References: <1110987284.154666.321070@g14g2000cwa.googlegroups.com> <87eke9c8mr.fsf@prep.synonet.com> <1111496414.624516.73550@o13g2000cwo.googlegroups.com> NNTP-Posting-Host: mm127387-pc-1.mitre.org X-Trace: newslocal.mitre.org 1111601603 4089 128.29.24.19 (23 Mar 2005 18:13:23 GMT) X-Complaints-To: news@mitre.org NNTP-Posting-Date: Wed, 23 Mar 2005 18:13:23 +0000 (UTC) User-Agent: nn/6.6.5 Path: nightfall.franklin.ch!news1.ethz.ch!news-zh.switch.ch!irazu.switch.ch!switch.ch!newsmi-eu.news.garr.it!newsmi-us.news.garr.it!NewsITBone-GARR!canoe.uoregon.edu!arclight.uoregon.edu!news.tufts.edu!newstransit.mitre.org!news.mitre.org!jcmorris Xref: nightfall.franklin.ch alt.folklore.computers:201413 Jay Maynard writes: >No, that wouldn't be. Getting the tape to a virtual tape file would get >intereting, though; you'd have to use a tape drive that didn't throw away >records shorter than 18 bytes as noise. I don't know of any that don't, >though that's mainly because the thought never crossed my mind that it might >be necessary. I think that you'll find that in many cases tape drives will read the short records if everything goes well, but if anything hiccups and the system goes into error recovery the short records will be dismissed as noise. We had that problem at a PPOE: the University had a rule that any computer purchase had to be coordinated by a campus-wide office. The bookstore did an end run around the rules by purchasing an "electronic cash register system" -- even though the system included a computer and a tape drive on which the transactions were recorded. The idea was that the tape would then be read on our S/360 and uploaded into the University's financial database. All fine and dandy...except that the idjuts who wrote the code on the "electronic cash register system" in numerous situations would deliberately generate one-byte records, and with the tape drive located in a corner of the bookstore manager's office the quality of the tape wasn't particularly good...meaning that ERP was frequently invoked when the tape was being read. Lots of effort was spent by the administrative programmers (thankfully, not my responsibility) to build workarounds to handle the loss of the short records. Joe Morris ###### From: Joe Morris Newsgroups: alt.folklore.computers Subject: Re: Call for information on virtual tape formats Date: Wed, 23 Mar 2005 18:27:12 +0000 (UTC) Organization: The MITRE Organization Lines: 45 Message-ID: References: <1110987284.154666.321070@g14g2000cwa.googlegroups.com> <87eke9c8mr.fsf@prep.synonet.com> <1111496414.624516.73550@o13g2000cwo.googlegroups.com> NNTP-Posting-Host: mm127387-pc-1.mitre.org X-Trace: newslocal.mitre.org 1111602432 5088 128.29.24.19 (23 Mar 2005 18:27:12 GMT) X-Complaints-To: news@mitre.org NNTP-Posting-Date: Wed, 23 Mar 2005 18:27:12 +0000 (UTC) User-Agent: nn/6.6.5 Path: nightfall.franklin.ch!news1.ethz.ch!news-zh.switch.ch!irazu.switch.ch!switch.ch!newsmi-eu.news.garr.it!newsmi-us.news.garr.it!NewsITBone-GARR!hammer.uoregon.edu!arclight.uoregon.edu!news.tufts.edu!newstransit.mitre.org!news.mitre.org!jcmorris Xref: nightfall.franklin.ch alt.folklore.computers:201416 arargh502NOSPAM@NOW.AT.arargh.com writes: >At a PPOE, we had a bootable code dump program. The boot record wrote >the first 32k of core to the tape, following the boot record. Then >you had to keep hitting IPL to find the formatting program, which was >futher down on the tape. Wasn't that Mort's Post Mortem? With very good formatting of the MFT control blocks. The key was that using that technique you were able to create a dump of everything but the low three doublewords in memory. The structure of the tape when created was something like this: IPL record: CCW to write 32K to the tape CCW to write a tape mark disabled PSW Lots and lots of IPL blocks to occupy more than enough tape space to hold 32K of data: CCW to forward space file dword space disabled PSW Tape mark IPL record to load dump program dump program IPL the tape once: it will run the first boot record and dump 32K of memory to the tape, then load the disabled PSW IPL the tape again: it will probably be in the middle of a record and will get a tape error. IPL the tape again: it will read the IPL block with the FSF CCW. IPL the tape again: the dump program comes into memory, and writes the formatted dump to the printer at 00E. Joe Morris ###### From: arargh502NOSPAM@NOW.AT.arargh.com Newsgroups: alt.folklore.computers Subject: Re: Call for information on virtual tape formats Date: Wed, 23 Mar 2005 13:50:52 -0600 Organization: Not Really! Lines: 42 Message-ID: References: <1110987284.154666.321070@g14g2000cwa.googlegroups.com> <87eke9c8mr.fsf@prep.synonet.com> <1111496414.624516.73550@o13g2000cwo.googlegroups.com> NNTP-Posting-Host: tcr52.dynip.ripco.net Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Trace: e250.ripco.com 1111607502 22041 209.100.226.52 (23 Mar 2005 19:51:42 GMT) X-Complaints-To: usenet@ripco.com NNTP-Posting-Date: Wed, 23 Mar 2005 19:51:42 +0000 (UTC) X-Newsreader: Forte Agent 1.92/32.572 Path: nightfall.franklin.ch!news1.ethz.ch!news-zh.switch.ch!switch.ch!solnet.ch!solnet.ch!news.glorb.com!gail.ripco.com!not-for-mail Xref: nightfall.franklin.ch alt.folklore.computers:201423 On Wed, 23 Mar 2005 18:27:12 +0000 (UTC), Joe Morris wrote: >arargh502NOSPAM@NOW.AT.arargh.com writes: > >>At a PPOE, we had a bootable code dump program. The boot record wrote >>the first 32k of core to the tape, following the boot record. Then >>you had to keep hitting IPL to find the formatting program, which was >>futher down on the tape. > >Wasn't that Mort's Post Mortem? With very good formatting of the MFT >control blocks. I have no idea. I only used it, or saw it used, a few times, 35 years ago. >The key was that using that technique you were able to create a dump >of everything but the low three doublewords in memory. The structure >of the tape when created was something like this: > > IPL record: CCW to write 32K to the tape > CCW to write a tape mark > disabled PSW > > Lots and lots of IPL blocks to occupy more than enough tape space > to hold 32K of data: > > CCW to forward space file > dword space > disabled PSW Or, a do several erase gap's. IPL will search for a record, IIRC. > > Tape mark -- Arargh502 at [drop the 'http://www.' from ->] http://www.arargh.com BCET Basic Compiler Page: http://www.arargh.com/basic/index.html To reply by email, remove the garbage from the reply address. ###### From: glen herrmannsfeldt Newsgroups: alt.folklore.computers Subject: Re: Call for information on virtual tape formats Date: Wed, 23 Mar 2005 12:25:11 -0800 Organization: University of Washington Lines: 33 Message-ID: References: <1110987284.154666.321070@g14g2000cwa.googlegroups.com> <87eke9c8mr.fsf@prep.synonet.com> <1111496414.624516.73550@o13g2000cwo.googlegroups.com> NNTP-Posting-Host: 128.208.140.139 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Trace: gnus01.u.washington.edu 1111609567 27109 128.208.140.139 (23 Mar 2005 20:26:07 GMT) X-Complaints-To: help@cac.washington.edu NNTP-Posting-Date: Wed, 23 Mar 2005 20:26:07 +0000 (UTC) User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en In-Reply-To: Path: nightfall.franklin.ch!news1.ethz.ch!news-zh.switch.ch!switch.ch!solnet.ch!solnet.ch!news.glorb.com!logbridge.uoregon.edu!arclight.uoregon.edu!news.u.washington.edu!not-for-mail Xref: nightfall.franklin.ch alt.folklore.computers:201428 arargh502NOSPAM@NOW.AT.arargh.com wrote: (someone wrote) >> Lots and lots of IPL blocks to occupy more than enough tape space >> to hold 32K of data: >> CCW to forward space file >> dword space >> disabled PSW > Or, a do several erase gap's. IPL will search for a record, IIRC. As far as I know, it is the drive that will search for a record. If you mount a brand new tape, with no label or tape mark, and specify SL, AL, or NL (standard, ANSI, or no label) OS will attempt to read the label, and the drive will run the tape off the reel. The physical EOT mark (reflective strip) is only used when writing. The drive should finish the current record and signal EOT. The ability to write into large gaps without overwriting the data following the gap is, as far as I know, not implemented in any virtual tape format. Another one that I don't know about an implementation of is block addressable devices like DECtape, or QIC floppy-tape formats like QIC-40 and QIC-80. -- glen ###### X-Trace-PostClient-IP: 68.147.129.203 From: Brian Inglis Newsgroups: alt.folklore.computers Subject: Re: Call for information on virtual tape formats Organization: Systematic Software Reply-To: Brian.Inglis@SystematicSW.ab.ca Message-ID: References: <1110987284.154666.321070@g14g2000cwa.googlegroups.com> <87eke9c8mr.fsf@prep.synonet.com> <1111496414.624516.73550@o13g2000cwo.googlegroups.com> X-Newsreader: Forte Agent 1.93/32.576 English (American) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Lines: 48 Date: Wed, 23 Mar 2005 21:23:43 GMT NNTP-Posting-Host: 24.71.223.147 X-Complaints-To: abuse@shaw.ca X-Trace: pd7tw1no 1111613023 24.71.223.147 (Wed, 23 Mar 2005 14:23:43 MST) NNTP-Posting-Date: Wed, 23 Mar 2005 14:23:43 MST Path: nightfall.franklin.ch!news1.ethz.ch!news-zh.switch.ch!switch.ch!solnet.ch!solnet.ch!newspeer1.nwr.nac.net!in.100proofnews.com!in.100proofnews.com!pd7cy1no!shaw.ca!pd7tw1no.POSTED!53ab2750!not-for-mail Xref: nightfall.franklin.ch alt.folklore.computers:201432 On Wed, 23 Mar 2005 18:13:23 +0000 (UTC) in alt.folklore.computers, Joe Morris wrote: >Jay Maynard writes: > >>No, that wouldn't be. Getting the tape to a virtual tape file would get >>intereting, though; you'd have to use a tape drive that didn't throw away >>records shorter than 18 bytes as noise. I don't know of any that don't, >>though that's mainly because the thought never crossed my mind that it might >>be necessary. Elsepost quotes a recommended minimum read block length of 12 bytes. >I think that you'll find that in many cases tape drives will read the >short records if everything goes well, but if anything hiccups and the >system goes into error recovery the short records will be dismissed >as noise. I always understood that the risk was of short blocks looking like tape marks: anyone know what a tape mark looked like on the media? >We had that problem at a PPOE: the University had a rule that any >computer purchase had to be coordinated by a campus-wide office. The >bookstore did an end run around the rules by purchasing an "electronic >cash register system" -- even though the system included a computer >and a tape drive on which the transactions were recorded. The >idea was that the tape would then be read on our S/360 and uploaded >into the University's financial database. > >All fine and dandy...except that the idjuts who wrote the code on >the "electronic cash register system" in numerous situations would >deliberately generate one-byte records, and with the tape drive >located in a corner of the bookstore manager's office the quality >of the tape wasn't particularly good...meaning that ERP was frequently >invoked when the tape was being read. > >Lots of effort was spent by the administrative programmers (thankfully, >not my responsibility) to build workarounds to handle the loss of the >short records. Hope the bookstore was billed for the development time and the system time including ERP: teach them that cheap's not always inexpensive. -- Thanks. Take care, Brian Inglis Calgary, Alberta, Canada Brian.Inglis@CSi.com (Brian[dot]Inglis{at}SystematicSW[dot]ab[dot]ca) fake address use address above to reply ###### From: arargh502NOSPAM@NOW.AT.arargh.com Newsgroups: alt.folklore.computers Subject: Re: Call for information on virtual tape formats Date: Wed, 23 Mar 2005 17:14:05 -0600 Organization: Not Really! Lines: 52 Message-ID: References: <1110987284.154666.321070@g14g2000cwa.googlegroups.com> <87eke9c8mr.fsf@prep.synonet.com> <1111496414.624516.73550@o13g2000cwo.googlegroups.com> NNTP-Posting-Host: tcr52.dynip.ripco.net Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Trace: e250.ripco.com 1111619694 19193 209.100.226.52 (23 Mar 2005 23:14:54 GMT) X-Complaints-To: usenet@ripco.com NNTP-Posting-Date: Wed, 23 Mar 2005 23:14:54 +0000 (UTC) X-Newsreader: Forte Agent 1.92/32.572 Path: nightfall.franklin.ch!news1.ethz.ch!news-zh.switch.ch!switch.ch!solnet.ch!solnet.ch!news.glorb.com!gail.ripco.com!not-for-mail Xref: nightfall.franklin.ch alt.folklore.computers:201441 On Wed, 23 Mar 2005 12:25:11 -0800, glen herrmannsfeldt wrote: >arargh502NOSPAM@NOW.AT.arargh.com wrote: > >(someone wrote) >>> Lots and lots of IPL blocks to occupy more than enough tape space >>> to hold 32K of data: > >>> CCW to forward space file >>> dword space >>> disabled PSW > >> Or, a do several erase gap's. IPL will search for a record, IIRC. > >As far as I know, it is the drive that will search for a record. Yes, but the end result is the same. >If you mount a brand new tape, with no label or tape mark, >and specify SL, AL, or NL (standard, ANSI, or no label) OS will >attempt to read the label, and the drive will run the tape off >the reel. That is why there is/was a special program to label new tapes. I remember watching an operator do just that. >The physical EOT mark (reflective strip) is only used when >writing. The drive should finish the current record and signal >EOT. > >The ability to write into large gaps without overwriting the >data following the gap is, as far as I know, not implemented in >any virtual tape format. I doubt that there is any use for a virtual tape dump program. And, in any case, programs that read then write then read a tape should be considered HIGHLY non-standard. I wouldn't even waste time thinking about how to handle that. >Another one that I don't know about an implementation of is >block addressable devices like DECtape, or QIC floppy-tape >formats like QIC-40 and QIC-80. That should be trivial. They are all fixed block size, are they not? Well, I don't know about DECtape, however, AFAIK, all the QIC formats are 512 byte fixed sized blocks, at least on the media. -- Arargh502 at [drop the 'http://www.' from ->] http://www.arargh.com BCET Basic Compiler Page: http://www.arargh.com/basic/index.html To reply by email, remove the garbage from the reply address. ###### X-Trace-PostClient-IP: 68.147.129.203 From: Brian Inglis Newsgroups: alt.folklore.computers Subject: Re: Call for information on virtual tape formats Organization: Systematic Software Reply-To: Brian.Inglis@SystematicSW.ab.ca Message-ID: References: <87eke9c8mr.fsf@prep.synonet.com> <1111496414.624516.73550@o13g2000cwo.googlegroups.com> X-Newsreader: Forte Agent 1.93/32.576 English (American) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Lines: 23 Date: Thu, 24 Mar 2005 02:28:39 GMT NNTP-Posting-Host: 24.71.223.147 X-Complaints-To: abuse@shaw.ca X-Trace: pd7tw2no 1111631319 24.71.223.147 (Wed, 23 Mar 2005 19:28:39 MST) NNTP-Posting-Date: Wed, 23 Mar 2005 19:28:39 MST Path: nightfall.franklin.ch!news1.ethz.ch!news-zh.switch.ch!switch.ch!solnet.ch!solnet.ch!news.glorb.com!newshub.sdsu.edu!peer01.west.cox.net!cox.net!pd7cy1no!shaw.ca!pd7tw2no.POSTED!53ab2750!not-for-mail Xref: nightfall.franklin.ch alt.folklore.computers:201452 On Wed, 23 Mar 2005 17:14:05 -0600 in alt.folklore.computers, arargh502NOSPAM@NOW.AT.arargh.com wrote: >On Wed, 23 Mar 2005 12:25:11 -0800, glen herrmannsfeldt > wrote: >>Another one that I don't know about an implementation of is >>block addressable devices like DECtape, or QIC floppy-tape >>formats like QIC-40 and QIC-80. >That should be trivial. They are all fixed block size, are they not? >Well, I don't know about DECtape, however, AFAIK, all the QIC formats >are 512 byte fixed sized blocks, at least on the media. IIRC DECtape blocks were 1536 * 3 bit bytes duped on 6 tracks, or 512 * 9 bit bytes, 384 * 12 bit words, 256 * 18 bit words, or 128 * 36 bit words; and DEC disks normally had the sectors with the same capacity. -- Thanks. Take care, Brian Inglis Calgary, Alberta, Canada Brian.Inglis@CSi.com (Brian[dot]Inglis{at}SystematicSW[dot]ab[dot]ca) fake address use address above to reply ###### From: arargh502NOSPAM@NOW.AT.arargh.com Newsgroups: alt.folklore.computers Subject: Re: Call for information on virtual tape formats Date: Wed, 23 Mar 2005 23:02:28 -0600 Organization: Not Really! Lines: 27 Message-ID: <9ei441l2991o9a3t68f2618778pn296ggs@4ax.com> References: <87eke9c8mr.fsf@prep.synonet.com> <1111496414.624516.73550@o13g2000cwo.googlegroups.com> NNTP-Posting-Host: tcr52.dynip.ripco.net Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Trace: e250.ripco.com 1111640595 26208 209.100.226.52 (24 Mar 2005 05:03:15 GMT) X-Complaints-To: usenet@ripco.com NNTP-Posting-Date: Thu, 24 Mar 2005 05:03:15 +0000 (UTC) X-Newsreader: Forte Agent 1.92/32.572 Path: nightfall.franklin.ch!news1.ethz.ch!news-zh.switch.ch!irazu.switch.ch!switch.ch!news-fra1.dfn.de!news-lei1.dfn.de!newsfeed.freenet.de!ecngs!feeder2.ecngs.de!216.251.47.205.MISMATCH!feeder2.on.meganewsservers.com!meganewsservers.com!textfeed1.on.meganewsservers.com!gail.ripco.com!not-for-mail Xref: nightfall.franklin.ch alt.folklore.computers:201455 On Thu, 24 Mar 2005 02:28:39 GMT, Brian Inglis wrote: >On Wed, 23 Mar 2005 17:14:05 -0600 in alt.folklore.computers, >arargh502NOSPAM@NOW.AT.arargh.com wrote: > >>On Wed, 23 Mar 2005 12:25:11 -0800, glen herrmannsfeldt >> wrote: > >>>Another one that I don't know about an implementation of is >>>block addressable devices like DECtape, or QIC floppy-tape >>>formats like QIC-40 and QIC-80. > >>That should be trivial. They are all fixed block size, are they not? >>Well, I don't know about DECtape, however, AFAIK, all the QIC formats >>are 512 byte fixed sized blocks, at least on the media. > >IIRC DECtape blocks were 1536 * 3 bit bytes duped on 6 tracks, or 512 >* 9 bit bytes, 384 * 12 bit words, 256 * 18 bit words, or 128 * 36 bit >words; and DEC disks normally had the sectors with the same capacity. I thought it was something like that, but I wasn't sure. Thanks. -- Arargh502 at [drop the 'http://www.' from ->] http://www.arargh.com BCET Basic Compiler Page: http://www.arargh.com/basic/index.html To reply by email, remove the garbage from the reply address. ###### From: Peter Flass User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 Newsgroups: alt.folklore.computers Subject: Re: Call for information on virtual tape formats References: <1110987284.154666.321070@g14g2000cwa.googlegroups.com> <87eke9c8mr.fsf@prep.synonet.com> <1111496414.624516.73550@o13g2000cwo.googlegroups.com> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Lines: 12 Message-ID: Date: Thu, 24 Mar 2005 11:04:42 GMT NNTP-Posting-Host: 24.194.58.188 X-Complaints-To: abuse@rr.com X-Trace: twister.nyroc.rr.com 1111662282 24.194.58.188 (Thu, 24 Mar 2005 06:04:42 EST) NNTP-Posting-Date: Thu, 24 Mar 2005 06:04:42 EST Organization: Road Runner Path: nightfall.franklin.ch!news1.ethz.ch!news-zh.switch.ch!switch.ch!solnet.ch!solnet.ch!newspeer1.nwr.nac.net!news.maxwell.syr.edu!news-rtr.nyroc.rr.com!news-out.nyroc.rr.com!twister.nyroc.rr.com.POSTED!53ab2750!not-for-mail Xref: nightfall.franklin.ch alt.folklore.computers:201472 arargh502NOSPAM@NOW.AT.arargh.com wrote: > At a PPOE, we had a bootable code dump program. The boot record > wrote > the first 32k of core to the tape, following the boot record. Then > you had to keep hitting IPL to find the formatting program, which was > futher down on the tape. > Sloppy. The program could have written a small boot program on the tape tp forward space to tapemark (=end of core dump), and then load the formatting program. could possibly fit in 80 bytes... ###### From: arargh502NOSPAM@NOW.AT.arargh.com Newsgroups: alt.folklore.computers Subject: Re: Call for information on virtual tape formats Date: Thu, 24 Mar 2005 05:38:34 -0600 Organization: Not Really! Lines: 27 Message-ID: <2e95415aajn13rh9ipcr4t3h5rdjmvpoq1@4ax.com> References: <1110987284.154666.321070@g14g2000cwa.googlegroups.com> <87eke9c8mr.fsf@prep.synonet.com> <1111496414.624516.73550@o13g2000cwo.googlegroups.com> NNTP-Posting-Host: tcr52.dynip.ripco.net Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Trace: e250.ripco.com 1111664359 3829 209.100.226.52 (24 Mar 2005 11:39:19 GMT) X-Complaints-To: usenet@ripco.com NNTP-Posting-Date: Thu, 24 Mar 2005 11:39:19 +0000 (UTC) X-Newsreader: Forte Agent 1.92/32.572 Path: nightfall.franklin.ch!news1.ethz.ch!news-zh.switch.ch!switch.ch!solnet.ch!solnet.ch!newspeer1.nwr.nac.net!news.maxwell.syr.edu!border1.nntp.dca.giganews.com!nntp.giganews.com!feeder2.on.meganewsservers.com!meganewsservers.com!textfeed1.on.meganewsservers.com!gail.ripco.com!not-for-mail Xref: nightfall.franklin.ch alt.folklore.computers:201474 On Thu, 24 Mar 2005 11:04:42 GMT, Peter Flass wrote: >arargh502NOSPAM@NOW.AT.arargh.com wrote: >> >> At a PPOE, we had a bootable code dump program. The boot record wrote >> the first 32k of core to the tape, following the boot record. Then >> you had to keep hitting IPL to find the formatting program, which was >> futher down on the tape. >> > >Sloppy. The program could have written a small boot program on the tape >tp forward space to tapemark (=end of core dump), and then load the >formatting program. could possibly fit in 80 bytes... Which overwrites a fair bit of useful data in low core. They way this works, you only lose the first 24 bytes. And, the operators knew how to display and write down those bytes, which means nothing got lost. And, besides, what's wrong with pushing the stupid button 3 or 4 times? -- Arargh502 at [drop the 'http://www.' from ->] http://www.arargh.com BCET Basic Compiler Page: http://www.arargh.com/basic/index.html To reply by email, remove the garbage from the reply address. ###### From: Joe Morris Newsgroups: alt.folklore.computers Subject: Re: Call for information on virtual tape formats Date: Thu, 24 Mar 2005 13:46:11 +0000 (UTC) Organization: The MITRE Organization Lines: 20 Message-ID: References: <1110987284.154666.321070@g14g2000cwa.googlegroups.com> <87eke9c8mr.fsf@prep.synonet.com> <1111496414.624516.73550@o13g2000cwo.googlegroups.com> NNTP-Posting-Host: mm127387-pc-1.mitre.org X-Trace: newslocal.mitre.org 1111671971 7630 128.29.24.19 (24 Mar 2005 13:46:11 GMT) X-Complaints-To: news@mitre.org NNTP-Posting-Date: Thu, 24 Mar 2005 13:46:11 +0000 (UTC) User-Agent: nn/6.6.5 Path: nightfall.franklin.ch!news1.ethz.ch!news-zh.switch.ch!switch.ch!solnet.ch!solnet.ch!news.glorb.com!logbridge.uoregon.edu!arclight.uoregon.edu!news.tufts.edu!newstransit.mitre.org!news.mitre.org!jcmorris Xref: nightfall.franklin.ch alt.folklore.computers:201486 Peter Flass writes: >arargh502NOSPAM@NOW.AT.arargh.com wrote: >> At a PPOE, we had a bootable code dump program. The boot record wrote >> the first 32k of core to the tape, following the boot record. Then >> you had to keep hitting IPL to find the formatting program, which was >> futher down on the tape. >Sloppy. The program could have written a small boot program on the tape >tp forward space to tapemark (=end of core dump), and then load the >formatting program. could possibly fit in 80 bytes... The purpose of this hack was to preserve as much of memory as possible, and it succeeds by losing the contents of only the low 18 (hex) bytes. Since low memory is frequently where one could find the information required to explain the failure, this isn't a trivial requirement, and doesn't impose any need for special skills on the part of the operator. Joe Morris ###### From: Eric Sosman Newsgroups: alt.folklore.computers Subject: Re: Call for information on virtual tape formats Date: Thu, 24 Mar 2005 11:47:23 -0500 Organization: Sun Microsystems Corporation Lines: 59 Message-ID: References: <1110987284.154666.321070@g14g2000cwa.googlegroups.com> <87eke9c8mr.fsf@prep.synonet.com> <1111496414.624516.73550@o13g2000cwo.googlegroups.com> NNTP-Posting-Host: tardis.east.sun.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Trace: news1brm.Central.Sun.COM 1111682844 1045 129.148.168.113 (24 Mar 2005 16:47:24 GMT) X-Complaints-To: usenet@news1brm.central.sun.com NNTP-Posting-Date: Thu, 24 Mar 2005 16:47:24 +0000 (UTC) User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.4) Gecko/20041214 X-Accept-Language: en-us, en In-Reply-To: Path: nightfall.franklin.ch!news1.ethz.ch!news-zh.switch.ch!irazu.switch.ch!switch.ch!news.tele.dk!news.tele.dk!small.news.tele.dk!newsfeed.media.kyoto-u.ac.jp!newsfeeds.ihug.co.nz!ihug.co.nz!news.compaq.com!newsfeed1.sea.pnap.net!newsfeed2.sea.pnap.net!newsfeed.pnap.net!brmea-news-1.sun.com!news1brm.central.sun.com!not-for-mail Xref: nightfall.franklin.ch alt.folklore.computers:201502 Joe Morris wrote: > Peter Flass writes: > > >>arargh502NOSPAM@NOW.AT.arargh.com wrote: > > >>>At a PPOE, we had a bootable code dump program. The boot record wrote >>>the first 32k of core to the tape, following the boot record. Then >>>you had to keep hitting IPL to find the formatting program, which was >>>futher down on the tape. > > >>Sloppy. The program could have written a small boot program on the tape >>tp forward space to tapemark (=end of core dump), and then load the >>formatting program. could possibly fit in 80 bytes... > > > The purpose of this hack was to preserve as much of memory as possible, > and it succeeds by losing the contents of only the low 18 (hex) bytes. > Since low memory is frequently where one could find the information > required to explain the failure, this isn't a trivial requirement, and > doesn't impose any need for special skills on the part of the operator. I recall a card-resident dump program for the S/360 model 44 that could dump all of main memory, including the low-address goodies. The basic 44 was a stripped-down S/360 that did not implement all the instructions described in PofO. There was an extra-cost add-on that gave the 44 the ability to emulate the missing instructions; it amounted to a bag of normally-unaddressable memory plus some extra goodies to divert "invalid opcode" traps to an emulator that resided there. (There was also hardware to implement a few of the missing instructions directly: Load Multiple and Store Multiple were among them, and there may have been one or two others.) The extra memory was not even addressable by the I/O channels, except when a special "emulator IPL" button was used -- and that, of course, is how the dumper worked. You put the deck in the 2540, dialed up 00C, hit "emulator IPL," and the dumper program got loaded into the extra memory leaving main memory intact. There were a lot of things you couldn't do while running from the emulator memory, but one thing you could manage was to use the DIagnose instruction to move data between the two realms. So the dumper copied some stuff from main memory to extra memory, then copied itself to main memory, issued a couple more DI for some mode switches and stuff, and could then proceed to do I/O for the dump. (Fading memory: I'm pretty sure the "emulator IPL" button didn't have that exact legend on it, but I can't recall what it actually did say.) -- Eric.Sosman@sun.com ###### From: Rich Alderson Newsgroups: alt.folklore.computers Subject: Re: Call for information on virtual tape formats Date: 24 Mar 2005 19:12:32 -0500 Organization: PANIX Public Access Internet and UNIX, NYC Lines: 25 Sender: alderson+news@panix5.panix.com Message-ID: References: <1110987284.154666.321070@g14g2000cwa.googlegroups.com> <87eke9c8mr.fsf@prep.synonet.com> <1111496414.624516.73550@o13g2000cwo.googlegroups.com> NNTP-Posting-Host: panix5.panix.com X-Trace: reader1.panix.com 1111709552 23668 166.84.1.5 (25 Mar 2005 00:12:32 GMT) X-Complaints-To: abuse@panix.com NNTP-Posting-Date: Fri, 25 Mar 2005 00:12:32 +0000 (UTC) X-Newsreader: Gnus v5.7/Emacs 21.3 Path: nightfall.franklin.ch!news1.ethz.ch!news-zh.switch.ch!switch.ch!news.imp.ch!news.imp.ch!nntp-out.monmouth.com!newspeer.monmouth.com!nntp.abs.net!news2.wam.umd.edu!bloom-beacon.mit.edu!panix!not-for-mail Xref: nightfall.franklin.ch alt.folklore.computers:201526 glen herrmannsfeldt writes: > Another one that I don't know about an implementation of is block addressable > devices like DECtape, or QIC floppy-tape formats like QIC-40 and QIC-80. The SimH family of simulators for DEC equipment has DECtape devices for the systems that support--meaning that the KS10 simulator does not (damn it!). The files are simply streams of 16bit (for 12- or 16-bit systems) or 32bit words (for 18-bit systems). I've been thinking for a long time that the DECtape file format should be standard across all the emulators (as was the physical medium), as a block of 999996 bytes formatted to mimic the content of DECtape lines: 6456 bytes of leader, 6462 bytes of trailer, and 922488 bytes of content (for 16-, 18-, and 36-bit systems; 12-bit systems use only 849024 bytes of the same 999996, so headers and trailers would expand accordingly). Content is in 6-byte groups: mark code bit, inverted markcode bit, 3 inverted data bits, and 3 data bits. I can get more explicit if anyone is interested. -- Rich Alderson | /"\ ASCII ribbon | news@alderson.users.panix.com | \ / campaign against | "You get what anybody gets. You get a lifetime." | x HTML mail and | --Death, of the Endless | / \ postings | ###### X-Trace-PostClient-IP: 68.147.129.203 From: Brian Inglis Newsgroups: alt.folklore.computers Subject: Re: Call for information on virtual tape formats Organization: Systematic Software Reply-To: Brian.Inglis@SystematicSW.ab.ca Message-ID: References: <1110987284.154666.321070@g14g2000cwa.googlegroups.com> <87eke9c8mr.fsf@prep.synonet.com> <1111496414.624516.73550@o13g2000cwo.googlegroups.com> X-Newsreader: Forte Agent 1.93/32.576 English (American) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Lines: 31 Date: Fri, 25 Mar 2005 02:18:55 GMT NNTP-Posting-Host: 24.71.223.147 X-Complaints-To: abuse@shaw.ca X-Trace: pd7tw3no 1111717135 24.71.223.147 (Thu, 24 Mar 2005 19:18:55 MST) NNTP-Posting-Date: Thu, 24 Mar 2005 19:18:55 MST Path: nightfall.franklin.ch!news1.ethz.ch!news-zh.switch.ch!irazu.switch.ch!switch.ch!news.maxwell.syr.edu!border1.nntp.dca.giganews.com!nntp.giganews.com!pd7cy2so!pd7cy1no!shaw.ca!pd7tw3no.POSTED!53ab2750!not-for-mail Xref: nightfall.franklin.ch alt.folklore.computers:201529 On 24 Mar 2005 19:12:32 -0500 in alt.folklore.computers, Rich Alderson wrote: >glen herrmannsfeldt writes: > >> Another one that I don't know about an implementation of is block addressable >> devices like DECtape, or QIC floppy-tape formats like QIC-40 and QIC-80. > >The SimH family of simulators for DEC equipment has DECtape devices for the >systems that support--meaning that the KS10 simulator does not (damn it!). >The files are simply streams of 16bit (for 12- or 16-bit systems) or 32bit >words (for 18-bit systems). > >I've been thinking for a long time that the DECtape file format should be >standard across all the emulators (as was the physical medium), as a block of >999996 bytes formatted to mimic the content of DECtape lines: 6456 bytes of >leader, 6462 bytes of trailer, and 922488 bytes of content (for 16-, 18-, and >36-bit systems; 12-bit systems use only 849024 bytes of the same 999996, so >headers and trailers would expand accordingly). Content is in 6-byte groups: >mark code bit, inverted markcode bit, 3 inverted data bits, and 3 data bits. > >I can get more explicit if anyone is interested. If it's not on a public web page in text, expound expansively. ASCII boxes are great, too. -- Thanks. Take care, Brian Inglis Calgary, Alberta, Canada Brian.Inglis@CSi.com (Brian[dot]Inglis{at}SystematicSW[dot]ab[dot]ca) fake address use address above to reply ###### From: "Charlie Gibbs" Newsgroups: alt.folklore.computers Subject: Re: Call for information on virtual tape formats Date: 05 Apr 05 08:48:48 -0800 Organization: http://newsguy.com Lines: 40 Message-ID: <1774.956T2408T5286173@kltpzyxm.invalid> References: <1111496414.624516.73550@o13g2000cwo.googlegroups.com> <6f3141d8keoq03j63r3pbo2lkjvvjke8ab@4ax.com> <3acf75F698kt2U1@individual.net> NNTP-Posting-Host: p-758.newsdawg.com X-Newsreader: THOR 2.5a (Amiga;TCP/IP) Path: nightfall.franklin.ch!news1.ethz.ch!news-zh.switch.ch!switch.ch!solnet.ch!solnet.ch!news.glorb.com!pln-e!spln!rex!extra.newsguy.com!newsp.newsguy.com!news2 Xref: nightfall.franklin.ch alt.folklore.computers:202371 In article <3acf75F698kt2U1@individual.net>, dmr@bell-labs.com (Dennis Ritchie) writes: > "glen herrmannsfeldt" wrote in message > news:d1qjgb$bfs$1@gnus01.u.washington.edu... > .... >> "Note: To facilitate noise recognition, a minimum block length >> of 12 bytes is recommended for read and read backwards operations." >> >> It does say recommended, and not required. >> >> Besides, with BLKSIZE=1 a very large fraction of your tape is gaps! > > My slightly related tape story: In early Unix, the system supported > serial byte-at-a-time writes to blocked magtape. If you did this, > it would add the byte to the buffer, back up the drive, and > rewrite the block. > > The mechanics or logic of the drive/controller would position > the rewritten block just slightly further along. Thus the 512-byte > records would migrate along the tape, creating huge gaps. > (And of course the drive made peculiar sounds during > the writing). The tapes were readable, though. My slightly less related tape story: I had a tape with 9600-byte blocks that I wanted to read on a system that supported a maximum block size of 8K. I wrote a program that read the first 8K of a block (ignoring the length error), then issued a read backward of the same block with a memory address such that the data was spliced together to leave a proper 9600-byte image in memory. Forward space over the block and repeat until end of file. The drive made noises like a boiler about to explode, but it successfully read the tape. -- /~\ cgibbs@kltpzyxm.invalid (Charlie Gibbs) \ / I'm really at ac.dekanfrus if you read it the right way. X Top-posted messages will probably be ignored. See RFC1855. / \ HTML will DEFINITELY be ignored. Join the ASCII ribbon campaign! ###### X-Trace-PostClient-IP: 68.147.129.203 From: Brian Inglis Newsgroups: alt.folklore.computers Subject: Re: Call for information on virtual tape formats Organization: Systematic Software Reply-To: Brian.Inglis@SystematicSW.ab.ca Message-ID: References: <1110987284.154666.321070@g14g2000cwa.googlegroups.com> <87eke9c8mr.fsf@prep.synonet.com> <1111496414.624516.73550@o13g2000cwo.googlegroups.com> <6f3141d8keoq03j63r3pbo2lkjvvjke8ab@4ax.com> <3acf75F698kt2U1@individual.net> X-Newsreader: Forte Agent 1.93/32.576 English (American) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Lines: 33 Date: Tue, 05 Apr 2005 19:09:53 GMT NNTP-Posting-Host: 24.71.223.147 X-Complaints-To: abuse@shaw.ca X-Trace: pd7tw1no 1112728193 24.71.223.147 (Tue, 05 Apr 2005 13:09:53 MDT) NNTP-Posting-Date: Tue, 05 Apr 2005 13:09:53 MDT Path: nightfall.franklin.ch!news1.ethz.ch!news-zh.switch.ch!switch.ch!news.imp.ch!news.imp.ch!news.moat.net!news-out.newsfeeds.com!propagator3-LAX.newsfeeds.com!news-in.usenet.com!pd7cy1no!shaw.ca!pd7tw1no.POSTED!53ab2750!not-for-mail Xref: nightfall.franklin.ch alt.folklore.computers:202381 ffOn Wed, 23 Mar 2005 06:09:24 -0000 in alt.folklore.computers, "Dennis Ritchie" wrote: > >"glen herrmannsfeldt" wrote in message news:d1qjgb$bfs$1@gnus01.u.washington.edu... > .... >> "Note: To facilitate noise recognition, a minimum block length >> of 12 bytes is recommended for read and read backwards operations." >> >> It does say recommended, and not required. >> >> Besides, with BLKSIZE=1 a very large fraction of your tape is gaps! > >My slightly related tape story: In early Unix, the system supported >serial byte-at-a-time writes to blocked magtape. If you did this, >it would add the byte to the buffer, back up the drive, and >rewrite the block. > >The mechanics or logic of the drive/controller would position >the rewritten block just slightly further along. Thus the 512-byte >records would migrate along the tape, creating huge gaps. >(And of course the drive made peculiar sounds during >the writing). The tapes were readable, though. Gaps and tolerances on 7 track tapes must have been large enough that we could *update* 512 byte magtape blocks on the PDP-15, whereas that never even seemed to be considered a possibility on 9 track tapes. -- Thanks. Take care, Brian Inglis Calgary, Alberta, Canada Brian.Inglis@CSi.com (Brian[dot]Inglis{at}SystematicSW[dot]ab[dot]ca) fake address use address above to reply ###### X-Trace-PostClient-IP: 68.147.129.203 From: Brian Inglis Newsgroups: alt.folklore.computers Subject: Re: Call for information on virtual tape formats Organization: Systematic Software Reply-To: Brian.Inglis@SystematicSW.ab.ca Message-ID: References: <1111496414.624516.73550@o13g2000cwo.googlegroups.com> <6f3141d8keoq03j63r3pbo2lkjvvjke8ab@4ax.com> <3acf75F698kt2U1@individual.net> <1774.956T2408T5286173@kltpzyxm.invalid> X-Newsreader: Forte Agent 1.93/32.576 English (American) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Lines: 25 Date: Tue, 05 Apr 2005 19:20:05 GMT NNTP-Posting-Host: 24.71.223.147 X-Complaints-To: abuse@shaw.ca X-Trace: pd7tw1no 1112728805 24.71.223.147 (Tue, 05 Apr 2005 13:20:05 MDT) NNTP-Posting-Date: Tue, 05 Apr 2005 13:20:05 MDT Path: nightfall.franklin.ch!news1.ethz.ch!news-zh.switch.ch!irazu.switch.ch!switch.ch!news.maxwell.syr.edu!elnk-pas-nf1!newsfeed.earthlink.net!pd7cy1no!shaw.ca!pd7tw1no.POSTED!53ab2750!not-for-mail Xref: nightfall.franklin.ch alt.folklore.computers:202383 On 05 Apr 05 08:48:48 -0800 in alt.folklore.computers, "Charlie Gibbs" wrote: >My slightly less related tape story: I had a tape with 9600-byte >blocks that I wanted to read on a system that supported a maximum >block size of 8K. I wrote a program that read the first 8K of a >block (ignoring the length error), then issued a read backward >of the same block with a memory address such that the data was >spliced together to leave a proper 9600-byte image in memory. >Forward space over the block and repeat until end of file. >The drive made noises like a boiler about to explode, but it >successfully read the tape. None of the standard copy or magtape handling utilities on systems I used seemed to be able to read variable length blocks from unlabelled tapes, and some couldn't handle variable length blocks on labelled tapes, which specified the maximum block size, either. ISTR writing assembler utilities on every system worked on to ignore length errors in order to get data from such tapes onto disk. -- Thanks. Take care, Brian Inglis Calgary, Alberta, Canada Brian.Inglis@CSi.com (Brian[dot]Inglis{at}SystematicSW[dot]ab[dot]ca) fake address use address above to reply ###### From: prep@prep.synonet.com Newsgroups: alt.folklore.computers Subject: Re: Call for information on virtual tape formats Date: Wed, 06 Apr 2005 23:59:03 +0800 Organization: none Lines: 20 Message-ID: <878y3vzyk8.fsf@prep.synonet.com> References: <1110987284.154666.321070@g14g2000cwa.googlegroups.com> <87eke9c8mr.fsf@prep.synonet.com> <1111496414.624516.73550@o13g2000cwo.googlegroups.com> NNTP-Posting-Host: grimiore.conceptual.net.au Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: nnrp.waia.asn.au 1112878685 2727 203.190.192.5 (7 Apr 2005 12:58:05 GMT) X-Complaints-To: usenet@nnrp.waia.asn.au NNTP-Posting-Date: Thu, 7 Apr 2005 12:58:05 +0000 (UTC) User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) Cancel-Lock: sha1:LSmGn84ZXSQLHAdlTYzfz7yM2Ws= Cache-Post-Path: grimiore.conceptual.net.au!unknown@203-190-196-130.dial.usertools.net X-Cache: nntpcache 2.3.3 (see http://www.nntpcache.org/) Path: nightfall.franklin.ch!news1.ethz.ch!news-zh.switch.ch!irazu.switch.ch!switch.ch!newsfeed00.sul.t-online.de!t-online.de!border2.nntp.dca.giganews.com!border1.nntp.dca.giganews.com!nntp.giganews.com!nntp.waia.asn.au!198.32.212.248.MISMATCH!nnrp.waia.asn.au!127.0.0.1!nobody Xref: nightfall.franklin.ch alt.folklore.computers:202580 Brian Inglis writes: > I always understood that the risk was of short blocks looking like > tape marks: anyone know what a tape mark looked like on the media? Varied with the format some. You had a gap of some frame times, a possible LRC as the write drivers went to off, some more blank frames then the `mark'. A double mark puts 4 blamk frames here, then a seconf copy of the `mark'. IT did NOT use a 1/2" interrecord gap between marks as writing two EOT marks would. PE/GCR was somewhat differennt, and I think GCR used a 1/3" IRG. -- Paul Repacholi 1 Crescent Rd., +61 (08) 9257-1001 Kalamunda. West Australia 6076 comp.os.vms,- The Older, Grumpier Slashdot Raw, Cooked or Well-done, it's all half baked. EPIC, The Architecture of the future, always has been, always will be. ###### X-Trace-PostClient-IP: 68.147.129.203 From: Brian Inglis Newsgroups: alt.folklore.computers Subject: Re: Call for information on virtual tape formats Organization: Systematic Software Reply-To: Brian.Inglis@SystematicSW.ab.ca Message-ID: References: <1110987284.154666.321070@g14g2000cwa.googlegroups.com> <87eke9c8mr.fsf@prep.synonet.com> <1111496414.624516.73550@o13g2000cwo.googlegroups.com> <878y3vzyk8.fsf@prep.synonet.com> X-Newsreader: Forte Agent 1.93/32.576 English (American) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Lines: 34 Date: Thu, 07 Apr 2005 18:42:14 GMT NNTP-Posting-Host: 24.71.223.147 X-Complaints-To: abuse@shaw.ca X-Trace: pd7tw3no 1112899334 24.71.223.147 (Thu, 07 Apr 2005 12:42:14 MDT) NNTP-Posting-Date: Thu, 07 Apr 2005 12:42:14 MDT Path: nightfall.franklin.ch!news1.ethz.ch!news-zh.switch.ch!switch.ch!solnet.ch!solnet.ch!newsfeed.inode.at!news-out.newsfeeds.com!propagator3-LAX.newsfeeds.com!news-in.usenet.com!pd7cy1no!shaw.ca!pd7tw3no.POSTED!53ab2750!not-for-mail Xref: nightfall.franklin.ch alt.folklore.computers:202622 On Wed, 06 Apr 2005 23:59:03 +0800 in alt.folklore.computers, prep@prep.synonet.com wrote: >Brian Inglis writes: > >> I always understood that the risk was of short blocks looking like >> tape marks: anyone know what a tape mark looked like on the media? > >Varied with the format some. You had a gap of some frame times, a >possible LRC as the write drivers went to off, some more blank frames >then the `mark'. A double mark puts 4 blamk frames here, then a seconf >copy of the `mark'. IT did NOT use a 1/2" interrecord gap between >marks as writing two EOT marks would. I was looking more for a description of frame count and contents for the EOF mark, as might be seen on a multi-channel scope or logic analyser attached to the heads or frame buffer, although your description provides more info than I've come across. I assume there were magtape interoperability standards published, but have never come across any, even back in the days when those were relevant. >PE/GCR was somewhat differennt, and I think GCR used a 1/3" IRG. GCR did use 1/3" IRG: used to have scripts that would calculate fairly accurately how much tape would be required to hold a disk file at various block factors, and how long they would take to read/write, for various drives and densities, assuming overlapped disk I/O and tape streaming. -- Thanks. Take care, Brian Inglis Calgary, Alberta, Canada Brian.Inglis@CSi.com (Brian[dot]Inglis{at}SystematicSW[dot]ab[dot]ca) fake address use address above to reply ###### From: "Tim Shoppa" Newsgroups: alt.folklore.computers Subject: Re: Call for information on virtual tape formats Date: 11 Apr 2005 06:19:28 -0700 Organization: http://groups.google.com Lines: 22 Message-ID: <1113225568.025384.168220@z14g2000cwz.googlegroups.com> References: <1110987284.154666.321070@g14g2000cwa.googlegroups.com> <87eke9c8mr.fsf@prep.synonet.com> <1111496414.624516.73550@o13g2000cwo.googlegroups.com> <878y3vzyk8.fsf@prep.synonet.com> NNTP-Posting-Host: 170.121.15.35 Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Trace: posting.google.com 1113225574 32493 127.0.0.1 (11 Apr 2005 13:19:34 GMT) X-Complaints-To: groups-abuse@google.com NNTP-Posting-Date: Mon, 11 Apr 2005 13:19:34 +0000 (UTC) In-Reply-To: <878y3vzyk8.fsf@prep.synonet.com> User-Agent: G2/0.2 Complaints-To: groups-abuse@google.com Injection-Info: z14g2000cwz.googlegroups.com; posting-host=170.121.15.35; posting-account=mAyfxAwAAABWbrxnXxYpn9RczUJc3B8w Path: nightfall.franklin.ch!news1.ethz.ch!news-zh.switch.ch!switch.ch!solnet.ch!solnet.ch!news.glorb.com!postnews.google.com!z14g2000cwz.googlegroups.com!not-for-mail Xref: nightfall.franklin.ch alt.folklore.computers:202808 > [tape marks] PE/GCR was somewhat differennt I remember some truly bizarro install tapes that had both 800 BPI NRZ and 1600 BPI PE on the same tape. The DEC-compatible tape formatters I worked with would not write such tapes (well, not obviously...) and I never figured out how they were made, short of adding a "fake" reflective marker where you want to change density. IIRC they began at 1600 BPI but you could issue some skip commands to get to the 800 BPI stuff. Maybe it was the other way around, my memory is clouded by the PE burst at the beginning of a vanilla 1600 BPI tape. Getting back to the original subject line, I have no idea if any container file format for virtual tape images would allow mixed-density tapes. Mixed-density 8-inch floppies (first track (or tracks) is single-density, remaining tracks are higher-density) were quite common in the CP/M world, and I think Teledisk for example allows this in their container file format. Tim. ###### From: arargh504NOSPAM@NOW.AT.arargh.com Newsgroups: alt.folklore.computers Subject: Re: Call for information on virtual tape formats Date: Mon, 11 Apr 2005 16:15:39 -0500 Organization: Not Really! Lines: 28 Message-ID: <1vpl51tfuhd90nchq98i5g6mgefj8dvk0m@4ax.com> References: <1110987284.154666.321070@g14g2000cwa.googlegroups.com> <87eke9c8mr.fsf@prep.synonet.com> <1111496414.624516.73550@o13g2000cwo.googlegroups.com> <878y3vzyk8.fsf@prep.synonet.com> <1113225568.025384.168220@z14g2000cwz.googlegroups.com> NNTP-Posting-Host: tcr72.dynip.ripco.net Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Trace: e250.ripco.com 1113254157 5348 209.100.226.72 (11 Apr 2005 21:15:57 GMT) X-Complaints-To: usenet@ripco.com NNTP-Posting-Date: Mon, 11 Apr 2005 21:15:57 +0000 (UTC) X-Newsreader: Forte Agent 1.92/32.572 Path: nightfall.franklin.ch!news1.ethz.ch!news-zh.switch.ch!irazu.switch.ch!switch.ch!news.tele.dk!news.tele.dk!small.news.tele.dk!news.glorb.com!gail.ripco.com!not-for-mail Xref: nightfall.franklin.ch alt.folklore.computers:202822 On 11 Apr 2005 06:19:28 -0700, "Tim Shoppa" wrote: >> [tape marks] PE/GCR was somewhat differennt > >I remember some truly bizarro install tapes that had both 800 BPI NRZ >and 1600 BPI PE on the same tape. The DEC-compatible tape formatters I >worked with would not write such tapes (well, not obviously...) and I >never figured out how they were made, short of adding a "fake" >reflective marker where you want to change density. IIRC they began at >1600 BPI but you could issue some skip commands to get to the 800 BPI >stuff. Maybe it was the other way around, my memory is clouded by the >PE burst at the beginning of a vanilla 1600 BPI tape. To write either denisity first: Do a lot of skip and blank tape, write a TM, and then write the second file. Rewind, change denisity, and write the first file. However, for reading or writing, a lot of drives will refuse to change denisity at other than load point. -- Arargh504 at [drop the 'http://www.' from ->] http://www.arargh.com BCET Basic Compiler Page: http://www.arargh.com/basic/index.html To reply by email, remove the garbage from the reply address. ###### Sender: eric@ruckus.brouhaha.com From: Eric Smith Newsgroups: alt.folklore.computers Subject: Re: Call for information on virtual tape formats References: <1110987284.154666.321070@g14g2000cwa.googlegroups.com> <87eke9c8mr.fsf@prep.synonet.com> <1111496414.624516.73550@o13g2000cwo.googlegroups.com> <878y3vzyk8.fsf@prep.synonet.com> <1113225568.025384.168220@z14g2000cwz.googlegroups.com> Organization: Eric Conspiracy Secret Labs X-Eric-Conspiracy: There is no conspiracy. Date: 11 Apr 2005 14:27:24 -0700 Message-ID: Lines: 8 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii NNTP-Posting-Host: ruckus.brouhaha.com X-Trace: news.spies.com 1113254844 64.62.206.2 (11 Apr 2005 14:27:24 -0700) Path: nightfall.franklin.ch!news1.ethz.ch!news-zh.switch.ch!irazu.switch.ch!switch.ch!HSNX.atgi.net!news.kjsl.com!news.spies.com!not-for-mail Xref: nightfall.franklin.ch alt.folklore.computers:202823 "Tim Shoppa" writes: > Mixed-density 8-inch floppies (first track (or tracks) is > single-density, remaining tracks are higher-density) were quite common > in the CP/M world, and I think Teledisk for example allows this in > their container file format. As does the DMK floppy image file format, which has the distinct advantage over Teledisk format that it is open and fairly well documented. ###### NNTP-Posting-Date: Tue, 12 Apr 2005 06:51:28 -0500 Newsgroups: alt.folklore.computers From: jmfbahciv@aol.com Subject: Re: Call for information on virtual tape formats Organization: UltraNet Communications, Inc. References: <1110987284.154666.321070@g14g2000cwa.googlegroups.com> <87eke9c8mr.fsf@prep.synonet.com> <1111496414.624516.73550@o13g2000cwo.googlegroups.com> <878y3vzyk8.fsf@prep.synonet.com> <1113225568.025384.168220@z14g2000cwz.googlegroups.com> X-Newsreader: News Xpress Version 1.0 Beta #4 Date: Tue, 12 Apr 05 09:52:44 GMT Message-ID: <996dnXMQetbcK8bfRVn-2A@rcn.net> Lines: 28 NNTP-Posting-Host: 208.59.181.239 X-Trace: sv3-lPy1F/ZmSqaYMdHLTEFEhwoZ5pUJqFXIlFTGL/xUJDtSBdGr19Im2FPZ0/2fJ4ZWoZ842LeinOs3e2n!3LPhqYyJ2EzJH6OYsskxPjrHsVghuZg3OyrhGcCxICEKH+ERh0SO7kh/kwNMCATCTA== X-Complaints-To: abuse@rcn.net X-DMCA-Complaints-To: abuse@rcn.net X-Abuse-and-DMCA-Info: Please be sure to forward a copy of ALL headers X-Abuse-and-DMCA-Info: Otherwise we will be unable to process your complaint properly X-Postfilter: 1.3.31 Path: nightfall.franklin.ch!news1.ethz.ch!news-zh.switch.ch!irazu.switch.ch!switch.ch!news.belwue.de!newsfeed01.sul.t-online.de!newsfeed00.sul.t-online.de!t-online.de!border2.nntp.dca.giganews.com!border1.nntp.dca.giganews.com!nntp.giganews.com!local01.nntp.dca.giganews.com!nntp.rcn.net!news.rcn.net.POSTED!not-for-mail Xref: nightfall.franklin.ch alt.folklore.computers:202865 In article <1113225568.025384.168220@z14g2000cwz.googlegroups.com>, "Tim Shoppa" wrote: >> [tape marks] PE/GCR was somewhat differennt > >I remember some truly bizarro install tapes that had both 800 BPI NRZ >and 1600 BPI PE on the same tape. The DEC-compatible tape formatters I >worked with would not write such tapes (well, not obviously...) and I >never figured out how they were made, short of adding a "fake" >reflective marker where you want to change density. SET DENSITY MTA0:1600 ;THIS COMMAND IS SPELLED INCORRECTLY R BACKUP SAVE FOO.MAC ^C SET DENSITY MTA0:800 R BACKUP SAVE FOO.MAC ^C UNLOAD MTAO: Or we could move the tape from one drive to the next and skip the first logical file, then copy to the tape. /BAH Subtract a hundred and four for e-mail.