test-drb May 2002

test-drb@ccmp.vtda.org

246 participants
947 discussions

by dquebbeman＠acm.org

> At 04:10 PM 5/2/2002 -0400, Douglas H. Quebbeman wrote: > >No. And I see no useful purpose in including that in the format. > >If the read was recovered, you have the data; surely you would > >*not* want to recreate a tape and make a previously marginal > >block, marginal again on a clone? > > Choosing between the loss of all the data, and a partial > copy, I'll take the partial copy. > > I have many 8-inch disks with bad blocks. I'd like to preserve > the data if at all possible. A simplistic 'dd'-style read > won't preserve everything; it'll bail out when it has a problem. ??? I just did a 'dd' of a bad QIC-80 tape; it read the entire tape as a single file, and didn't bail out. I've not done that with magtape, but ISTR someone else here saying that 'dd' does raw reads, bad blocks and all... My bad if not true. -dq

23 years, 1 month

Tape dumping programs for Unix/Linux..

by dquebbeman＠acm.org

> However, if I notice recovered-reads (or hard errors) on old 9-track > tapes, I often see fewer recovered reads (or hard errors) if I try > the tape one more time. I assume that going over the heads once > may have knocked off a bit of dust/dirt/something that affected > the tape the first time. Note that I don't discard the > results of the first run until the second run finishes... hey! Me too! > I've had one tape break during a second run :) Ouch! Acetate backing? > > > Go buy a 9-track drive and hang it on your *nix box. > > > Let me send you a 9-track tape. You read it any way > > > you want. You send me the tape back. > > > > > Then you go get a second tape, and put the data back on > > > any way you want. Then send it to me, and I'll tell you > > > if your technique works or not. > > BTW, the only way you can be *SURE* you got all the data on > the tape is if *EVERY* read-request returned fewer characters > than you asked for. E.g., if you did: > bytesread = read(fromfd, buffer, BUFSIZE); > and you get BUFSIZE bytes in, then there's a chance that that > tape record had BUFSIZE + 100 bytes ... and you've just lost > those last 100 bytes. I *just* recently discovered this, and will incorporate that into a utility I'll be hosting on the Prime. -dq

23 years, 1 month

S/36 OS?

by xds_sigma7＠hotmail.com

SSP... Why, do you need a copy or something? I have it on 8" floppies... SSP stands for System Support Program, FYI. Will J _________________________________________________________________ Join the world’s largest e-mail service with MSN Hotmail. http://www.hotmail.com

23 years, 1 month

New Finds for the Museum

by jrkeys＠concentric.net

This week has been a little slow and have to watch the cashflow. 1. 30 plus cartridges for the Intellivision (free) 2. hp 82901M Flexible Disc Drive excellent shape ($1.99) 3. IBM 3.5 FD external type 4865 ($1.99) 4. PowerBook 150 with adapter and case (Targus) ($20) 5. NCD ExploraPro x-terminal ($1) 6. Sun SPARCStation IPC ($1) 7. Two AppleCD 600e ($1ea) 8. Four AppleCD 300 ($1ea) 9. MicroScribe model 450/2013 ($1) 10.WYSE model WY-150-03-01 ($6) 11. TOMY robot ($1) 12. digital VT420-C2 (free) 13. AMT FormsWriter-242 (free) 14. AMIGA 500 (free) 15. digital VT240 model VS240-B ($8) That's it for this week the balance is too new to post.

23 years, 1 month

Tape dumping programs for Unix/Linux..

by dquebbeman＠acm.org

> Fair enough, but remember my post was about cat vs dd, and > was not dealing with all these other issues being tossed > up, it was to point out that what he was doing would be easier > with a simpler tool > > It certainly didnt apply to preserving the information > needed to rewrite a new 9 track tape. > > I think your being a bit rough on me here, your givin me > a GI bath for things that was outside of the scope of my > focus. Ok, and fair enough... several of us detected that you might not quite grasp the scope of the issue, yet your dogged assertiveness was sending a different message. I apologize for any part of my remarks that came off like an attack. Regards, -doug q

23 years, 1 month

Tektronix 4052A GPIB Programming Guide Item # 1727379522

by rigdonj＠cfl.rr.com

<http://cgi.ebay.com/ws/eBayISAPI.dll?ViewItem&item=1727379522>

23 years, 1 month

Tektronix 4050 Series Basic Reference Guide HURRY!

by rigdonj＠cfl.rr.com

<http://cgi.ebay.com/ws/eBayISAPI.dll?ViewItem&item=1726561113> It closes in 54 minutes!

23 years, 1 month

Tape dumping programs for Unix/Linux...

by Lee.Davison＠merlincommunications.com

Engineers are great- they're like laser beams. They are intense and highly focusable. .. and they bounce around the room until you don't know which direction they're comming from. Lee. ---------------------------------------------------------------------------- ---- This email is intended only for the above named addressee(s). The information contained in this email may contain information which is confidential. The views expressed in this email are personal to the sender and do not in any way reflect the views of the company. If you have received this email and you are not a named addressee please delete it from your system and contact Merlin Communications International IT Department on +44 20 7344 5888. ________________________________________________________________________ This e-mail has been scanned for all viruses by Star Internet. The service is powered by MessageLabs. For more information on a proactive anti-virus service working around the clock, around the globe, visit: http://www.star.net.uk ________________________________________________________________________

23 years, 1 month

Tape dumping programs for Unix/Linux...

by dquebbeman＠acm.org

> Keep in mind one thing: engineers who spend their lives working on tape > hardware thought it was important enough to be able to signal recovered > errors ... for a reason. Engineers are great- they're like laser beams. They are intense and highly focusable. But they don't illuminate a wide area when focused. OTOH, take the lowly, dim incandescent lightbulb. Not intense. Not very focused. But it lights up the whole room. Ok, now that everyone's got me pegged as the dim bulb in this group... (didn't think I was going to leave that one for someone else, did you?), let me finish my thought... Anyway, my point is that sometimes engineers are so focused that they don't see the big picture. But I'm not disagreeing about the need to know about read errors (or write errors for that reason). Regards, -dq

23 years, 1 month

Tape dumping programs for Unix/Linux...

by dquebbeman＠acm.org

Stan sayeth: > > No. And I see no useful purpose in including that in the format. > > If the read was recovered, you have the data; surely you would > > *not* want to recreate a tape and make a previously marginal > > block, marginal again on a clone? > > > NOOOO! It's *IMPORTANT* to know if there was a question about the > accuracy of the data! That's *WHY* some tape drives even *tell* > you there was a recovered error ... so the user could use that > information! I do that during the first dozen-or-so reads of the tape... > It's like getting a recovered parity error on memory. > Should you know about it? DAMN STRAIGHT YOU SHOULD! heh... for years, any IBM compatible PC would, on detection of a parity error, deliberately crash. Doesn't matter why, I just lots my stuff... > Without recording that information, you also can't answer > important questions like: is the orginal tape in good shape? Sure, *make note of it*, but I don't necessarily view the image file as the only correct place to put that info. But it's not a bad idea, just a bit Brobdignagian... If I was Tim Shoppa and was doing analog reads of tapes so far gone that you've got only one try to get it right, sure. But like I said before, traditional methods shouldn't be used on these tapes. > > > - ability to flag if a particular tape record had a hard error > > > while reading it > > > > No (I can say this even though I'm about to ask): do you mean an > > unrecoverable error, or one that was corrected by the hardware > > (as opposed to being corrected by software)? Either way, if the > > error was corrected, see my response above. > > If it was corrected, then there was no error (other than a > recovered read, already correct recorded via the earlier bit :) > > I meant a real, live, actual error. (E.g., missing oxide) > > When recording the contents of a tape it's **IMPORTANT** to know > that there was an error there. If you simply skip the erorr and > keep reading, you've lost data. > Did you lose original user data? Possibly, and you've definitely > lost data about the tape (i.e., the fact there was an error). > > By recording the fact an error occurred, along with any data > your tape drive/OS *may* have sent you, you preserve the ability > to act wisely in the future. For example, by recording the > fact there was an error at megabyte 100 in a 102 MB file, > the user would have confidence that when that file is eventually > extracted, the first 99 MB of it is in fine shape. Y'all must encounter a lot more marginal tapes than I do. The ones I can't read have gone all the way down to where they will require an analog read. If I can read it digital at all, I'll reread the dang tape until I get ever record error-free. The wet read is most useful in this application. > > > - ability to flag if an End-of-tape marker/indicator was seen > > > while reading the the current record (again, not all > > > hardware/OS's support getting that information) > > > > No, and again, I can't see how this data would be used to recreate > > the tape or would be needed by an emulator. It's kind of like asking > > if a particular hardware emulator also emulates memory parity errors > > so that you can see memory parity errors in the logs. Why?? > > With 9-track tapes, software writing to the tapes generally watches > for an indication that the end-of-tape marker (a short silver > reflective strip) has been seen. At that time, it can prepare > to do a reel-switch. Although some people feel they can backspace > and write reel-switch info prior to the EOT marker on a 9-track > tape, that's technically not safe (and opens up the possibility > of getting what's called (in 1979) "crap in the gap"). Anyway, > the ANSI (?) standard for 9 track tapes specifies a minimum length > of tape be available for writing after the EOT marker ... a length > that should be sufficient (even with modest multiple outstanding > write-ahead requests) to write the reel switch information. I think you're missing my point- I don't believe there are any 9-track drives that split physical records across reels of tape. If I'm wrong, please correct me. > On at least one OS, Burroughs MCP, one could detect that EOT at > read time. Then, if one is doing multiple read-ahead requests, > one can moderate them appropriately. Yes, yes, yes, of course the EOT is detected while reading. But it happens *between* records, not *inside* them. > Ok...the short answer: it's information. You don't throw away > information without a darn good reason. :) Hey, if physical records *can* be split bwteen reels, then you are absolutely right. > > > - overall header at start of file, recording information about the tape > > > > No, although I did consider suggesting some extensions like this. > > One problem I have encountered with some old CDC tape formats > > Sorry...if you want a professional program, not something like > that toy cptape, you *WILL* have this information. > > Been there, worked on that, for over 30 years. Trust me...you > *want* all the information you can get. Actually, all I want is that the system software and applications can use the data from the tape without detecting its coming from some place other than a physical tape. So far that goal has not required the extreme mesaures discussed here. > > Anyway, I encode that kins of descriptive information (what kind > > of computer, encoding, #tracks, etc) in the filename, or in the > > name of the directory containing the file, or in a README. > > If two items of data are separated, what happens to them? > Yep. Should be 'nuff said :) Well, Raymond and I agree that tarballs work well for this, as well as other such methods of encapsulation. > > > I have a program called "tapedisk", which reads an arbitrary tape > > > > This sounds familiar... is it on the web somewhere? > > The MPE V version was/is (can't recall which), and was free. > The MPE/iX version is a product from our company. I was thinking of some Linux thing... I've only a few hours of HP3000 experience. Looked like a nice extension of the 2000 Access system, at first... > > So you really do want to recreate bad tapes as bad tapes... > > > > Why? > > No...I want to know that a problem existed, and where that > problem was. > > Again...this is basic, vital, and indisputable. You *NEED* to > know if there was a problem with the tape, and if you're trying to > extract a particular file you need to know where any problems > are in that file. Otherwise, you'll be lying to the user. > > If you know where within a file an error was found, then you've > got a chance at recovering most of the rest of the data successfully. > If you know an error occurred *somewhere* in a file, but not > where, then you have a large pile of bits which *might* be trash, > and *might* be useful ... but neither you or the user knows. > And, if you don't know where the errors were (and how many there > were), you can't reliably restore the data. That data might > be banking information that your company is being audited on; > it might be data that could clear someone of a crime...you simply > don't know. > > Data is important...that's why we call it data and not junk :) We're not disagreeing about this, we just have a different time-and-place attitude about it. > > This is some what I store as a "header" at the start of the > > > overall output: > > > > ... > > > > Yeah, this info is README fodder... why on earth program that? > > Uh, 'cuz someone had to do it and build a reliable, thorough > program? I'm not arguing that it's of no value, but I'm looking at cost of effort expended vs. return on investment. I used to always believe in building for the worst-case, but these days it's rarely feasible. The people writing the checks don't want to pay for features they don't think they'll use. > > > As you can see...a lot of info, but all necessary to faithfully > > > reproduce the tape later and/or to understand *why* the file might > > > (or can't) be used to completely reproduce the tape. > > > > Uh, again, can't understand why you'd need to recreate bad tapes. > > Again...you're *NOT RECREATING BAD TAPES*. I understand. Recreating tapes from images is not a criterium. > > You might try hooking up with the emulator community and > > ask your questions there. > > This being ClassicCmp, I thought they might be here, too :) One or two of us, at least! > Besides, this isn't an emulator question so much as a data > preservation question. Related issues, to be sure, but not necessarily identical ones. I don't think we're really disagreeing here; you circle the block to the left, I circle to the right. We both make it to where we want to go. Regards, -dq

23 years, 1 month

← Newer
1
...
82
83
84
85
86
87
88
...
95
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

1998

1997

test-drb May 2002