On Monday, October 5, 2020 at 8:25, Chuck Guzis via cctech wrote:
> So increasing the mask for block length wouldn't seem to be a problem,
> assuming that SIMH could support it.
SIMH could be written to support it (I'm the maintainer-by-default of the
tape handling portion of SIMH). I don't
On Mon, Oct 5, 2020 at 9:25 AM Chuck Guzis via cctech
wrote:
> On 10/4/20 10:51 PM, J. David Bryan via cctech wrote:
> > On Sunday, October 4, 2020 at 16:00, Chuck Guzis via cctalk wrote:
> >
> >> A 16MB tape block is impossibly large in any case.
> >
> > The HP 3000 mag tape diagnostic attempts
On 10/5/20 2:06 PM, Warner Losh wrote:
> The other way to handle it, should we not be able to steal bits which
> should be plan A, is to have a metadata type that says 'append this to
> the prior record' which would remove the limit entirely.
There's a good idea! Instead of putting headers on
On 10/4/20 10:51 PM, J. David Bryan via cctech wrote:
> On Sunday, October 4, 2020 at 16:00, Chuck Guzis via cctalk wrote:
>
>> A 16MB tape block is impossibly large in any case.
>
> The HP 3000 mag tape diagnostic attempts to write a single record from BOT
> to EOT, which unfortunately fails
> On Oct 5, 2020, at 11:50 AM, Jon Elson via cctalk
> wrote:
>
> On 10/04/2020 11:30 PM, Chuck Guzis via cctalk wrote:
>> The problem arose if the program either failed to keep up (e.g. competing
>> programs demanding the CPU) or if an ECS transfer occurred. Where I got
>> involved was
On 10/04/2020 11:30 PM, Chuck Guzis via cctalk wrote:
The problem arose if the program either failed to keep up
(e.g. competing programs demanding the CPU) or if an ECS
transfer occurred. Where I got involved was with a 4-CPU
configuration sharing 4MW of ECS, using the ECS for swap
space. ECS
> On Oct 5, 2020, at 12:30 AM, Chuck Guzis via cctalk
> wrote:
>
> On 10/4/20 8:58 PM, jim stephens via cctalk wrote:
>
>> I had not seen your earlier no tape gap mentions.
>
> The old CDC 6000 SCOPE 1LT driver. Since SCOPE user programs use
> circular buffering, The PP overlay 1LT simply
On Sunday, October 4, 2020 at 16:00, Chuck Guzis via cctalk wrote:
> A 16MB tape block is impossibly large in any case.
The HP 3000 mag tape diagnostic attempts to write a single record from BOT
to EOT, which unfortunately fails under simulation due to the 16 MB
limitation. In hindsight, it
On 10/4/20 8:58 PM, jim stephens via cctalk wrote:
> I had not seen your earlier no tape gap mentions.
The old CDC 6000 SCOPE 1LT driver. Since SCOPE user programs use
circular buffering, The PP overlay 1LT simply emptied the CM buffer and
wrote it, 12-bit word by 12-bit word to the drive
On 10/4/2020 8:47 PM, Chuck Guzis via cctalk wrote:
On 10/4/20 8:12 PM, jim stephens via cctalk wrote:
On 10/4/2020 4:00 PM, Chuck Guzis via cctalk wrote:
On 10/4/20 1:50 PM, J. David Bryan via cctalk wrote:
I don't believe that you're missing anything. When I process these
files, I
On 10/4/20 8:12 PM, jim stephens via cctalk wrote:
>
>
> On 10/4/2020 4:00 PM, Chuck Guzis via cctalk wrote:
>> On 10/4/20 1:50 PM, J. David Bryan via cctalk wrote:
>>>
>> I don't believe that you're missing anything. When I process these
>> files, I mask off the lower 24 bits as the block
I'm surprised that they have not turned up since they are useful for wells when
trying to enhance output.
seismic data recovery from tape has been going on for a long time
On 10/4/2020 4:00 PM, Chuck Guzis via cctalk wrote:
On 10/4/20 1:50 PM, J. David Bryan via cctalk wrote:
I don't believe that you're missing anything. When I process these
files, I mask off the lower 24 bits as the block length. A 16MB tape
block is impossibly large in any case.
On 10/4/20 1:50 PM, J. David Bryan via cctalk wrote:
> On Friday, October 2, 2020 at 13:51, Al Kossow via cctech wrote:
>
>> Those would already be broken with Bob's use of large negative numbers
>> for physical end of tape and 'bad block is here' (you don't get to know
>> how big that bad block
On Friday, October 2, 2020 at 13:51, Al Kossow via cctech wrote:
> Those would already be broken with Bob's use of large negative numbers
> for physical end of tape and 'bad block is here' (you don't get to know
> how big that bad block was, so that is hell with tapes with
> variable-length
On Sat, 2020-10-03 at 08:33 -0700, Chuck Guzis via cctalk wrote:
>
> In particular, consider a government project where several hundred
> millions of 1970s dollars were spent by the government, yet almost
> nothing other than a few papers survives. Those involved with
> intimate
> knowledge are
On 10/3/20 3:20 AM, Al Kossow via cctalk wrote:
> On 10/2/20 7:38 PM, Chuck Guzis via cctalk wrote:
>> In fact, is there any standard for floppy disk metadata container files?
>>
>
> Digtial archivists seem to be using
> LoC BagIt, which essentially is a zip file of a directory
>
>
On 10/3/20 3:20 AM, Al Kossow via cctalk wrote:
On 10/2/20 7:38 PM, Chuck Guzis via cctalk wrote:
In fact, is there any standard for floppy disk metadata container files?
Digtial archivists seem to be using
LoC BagIt, which essentially is a zip file of a directory
On 10/2/20 7:38 PM, Chuck Guzis via cctalk wrote:
In fact, is there any standard for floppy disk metadata container files?
Digtial archivists seem to be using
LoC BagIt, which essentially is a zip file of a directory
https://en.wikipedia.org/wiki/BagIt
I'd have to check with our digital
On Fri, Oct 2, 2020, 8:38 PM Chuck Guzis via cctech
wrote:
> In fact, is there any standard for floppy disk metadata container files?
>
> I'm not aware of any.
>
Teledisk?
>
In fact, is there any standard for floppy disk metadata container files?
I'm not aware of any.
--Chuck
> On 10/2/20 1:42 PM, Eric Smith via cctalk wrote:
>
> >/Of course, that scheme breaks programs that use tape images but don't
> >/>/expect enormous or "negative" record lengths. /
> Those would already be broken with Bob's use of large negative numbers for
> physical end of
> tape and 'bad
On Fri, Oct 2, 2020, 9:37 PM Chuck Guzis wrote:
> On 10/2/20 8:08 PM, Warner Losh wrote:
> >
> >
> > On Fri, Oct 2, 2020, 8:38 PM Chuck Guzis via cctech
> > mailto:cct...@classiccmp.org>> wrote:
> >
> > In fact, is there any standard for floppy disk metadata container
> files?
> >
> >
On 10/2/20 8:08 PM, Warner Losh wrote:
>
>
> On Fri, Oct 2, 2020, 8:38 PM Chuck Guzis via cctech
> mailto:cct...@classiccmp.org>> wrote:
>
> In fact, is there any standard for floppy disk metadata container files?
>
> I'm not aware of any.
>
>
> Teledisk?
>
Heh, but no--there's no
On 10/2/20 1:42 PM, Eric Smith wrote:
> On Fri, Oct 2, 2020 at 1:27 PM Chuck Guzis via cctalk
> mailto:cctalk@classiccmp.org>> wrote:
>
> Actually, they're neither. I append the metadata after the EOI marker
> on mine. Doesn't seem to bother the emulators.
>
>
> Some programs (but
On 10/2/20 1:42 PM, Eric Smith via cctalk wrote:
Of course, that scheme breaks programs that use tape images but don't
expect enormous or "negative" record lengths.
Those would already be broken with Bob's use of large negative numbers for
physical end of
tape and 'bad block is here' (you
On Fri, Oct 2, 2020 at 1:27 PM Chuck Guzis via cctalk
wrote:
> Actually, they're neither. I append the metadata after the EOI marker
> on mine. Doesn't seem to bother the emulators.
>
Some programs (but probably very few) that use various so-called .tap files
assume that they can seek to the
On 10/2/20 12:26 PM, Chuck Guzis via cctalk wrote:
This is basically the problem with all of the container file formats
that I've seen. They seem to think that the data alone is sufficient to
describe an object. Quite often, a simple paper label is more
informative than a bunch of bits
the
On 10/2/20 11:51 AM, Paul Koning wrote:
>
>
>> On Oct 2, 2020, at 1:46 PM, Chuck Guzis via cctalk
>> wrote:
>>
>> On 10/1/20 11:40 PM, Warner Losh via cctalk wrote:
>>> On Fri, Oct 2, 2020, 12:05 AM Tom Hunter via cctalk
>>> wrote:
>>>
I have never figured out why Bob Supnik defined the
> On Oct 2, 2020, at 1:46 PM, Chuck Guzis via cctalk
> wrote:
>
> On 10/1/20 11:40 PM, Warner Losh via cctalk wrote:
>> On Fri, Oct 2, 2020, 12:05 AM Tom Hunter via cctalk
>> wrote:
>>
>>> I have never figured out why Bob Supnik defined the magnetic tape
>>> containers (TAP files) with the
On 10/1/20 11:40 PM, Warner Losh via cctalk wrote:
> On Fri, Oct 2, 2020, 12:05 AM Tom Hunter via cctalk
> wrote:
>
>> I have never figured out why Bob Supnik defined the magnetic tape
>> containers (TAP files) with the one byte padding for odd length records.
>> This seems very odd (pun
On 10/1/20 11:40 PM, Warner Losh wrote:
>
>
> On Fri, Oct 2, 2020, 12:05 AM Tom Hunter via cctalk
> mailto:cctalk@classiccmp.org>> wrote:
>
> I have never figured out why Bob Supnik defined the magnetic tape
> containers (TAP files) with the one byte padding for odd length
> records.
>
On Fri, Oct 2, 2020, 12:05 AM Tom Hunter via cctalk
wrote:
> I have never figured out why Bob Supnik defined the magnetic tape
> containers (TAP files) with the one byte padding for odd length records.
> This seems very odd (pun intended). :-)
> Even on a machine which couldn't write 32 bit
I have never figured out why Bob Supnik defined the magnetic tape
containers (TAP files) with the one byte padding for odd length records.
This seems very odd (pun intended). :-)
Even on a machine which couldn't write 32 bit numbers (the record lenght)
on odd boundaries you could write the 32
Al Kossow wrote:
>> I'm kind of maintaining that.
> where?
Here:
https://github.com/brouhaha/tapeutils
> and since your fscking around inside of it, have you added the
> Bordynuik extensions in the ToTS tape images?
No, but I certainly will if yout tell me what it is.
On 9/18/20 8:44 AM, Al Kossow via cctalk wrote:
On 9/18/20 8:17 AM, Lars Brinkhoff wrote:
I'm kind of maintaining that.
where?
Are you feeding the changes back to Eric or have you come up with your
own no one knows about it except you version?
the issues will be in the tap library from
On 9/18/20 8:17 AM, Lars Brinkhoff wrote:
I'm kind of maintaining that.
where?
Are you feeding the changes back to Eric or have you come up with your
own no one knows about it except you version?
the issues will be in the tap library from John Wilson
Al Kossow wrote:
>> I usually use tapeutils:
>> https://github.com/brouhaha/tapeutils
>
> I should bug Eric about this, but the .tap files that library creates
> doesn't have the Supnik SIMH extensions
In case Eric doesn't have time to make updates, bug me instead.
I'm kind of maintaining that.
On 9/18/20 5:21 AM, Patrick Finnegan via cctalk wrote:
I usually use tapeutils:
https://github.com/brouhaha/tapeutils
I should bug Eric about this, but the .tap files that library creates doesn't
have the Supnik SIMH extensions
I use it for all of the SCSI recoveries that I do on Linux
I usually use tapeutils:
https://github.com/brouhaha/tapeutils
Pat
On Fri, Sep 18, 2020 at 1:40 AM shad via cctalk
wrote:
> dear all,
> thanks for the useful informations!
> So now a question comes to mind...
> what is the best utility for Linux to be used to read and archive tapes?
>
>
dear all,
thanks for the useful informations!
So now a question comes to mind...
what is the best utility for Linux to be used to read and archive tapes?
Thanks
Andrea
> On 17/09/2020 07:38, Dave Wade G4UGM via cctalk wrote:
> >/The docs for SIMH .TAP files are here:-
> >/>//>/http://simh.trailing-edge.com/docs/simh_magtape.pdf />//>/be careful
> >as there are also non-SIMH .tap formats />//>/In the IBM Mainframe emulation
> >world there is also .AWS, an IBM
> Acoustically, the best tapes were the short-record "stranger" tapes.
> All sorts of interesting noise. I could tell from across the room when
> someone was running the tape section of the Navy audit tests for COBOL
> just by the sounds.
>
MALET was also pretty good, reading and writing a bunch
> On Sep 17, 2020, at 2:11 PM, Chuck Guzis via cctalk
> wrote:
>
> On 9/17/20 8:56 AM, Jon Elson via cctalk wrote:
>
>> This is not necessarily true. Many systems can handle "VBS" (Variable
>> Block Sequential) tape files.
>> But, yes, fixed block size is more common.
>
> "Hybrid" files
On 9/17/20 8:56 AM, Jon Elson via cctalk wrote:
> This is not necessarily true. Many systems can handle "VBS" (Variable
> Block Sequential) tape files.
> But, yes, fixed block size is more common.
"Hybrid" files are quite common, where all blocks are the same size, but
for the last one. Or, in
On 09/17/2020 12:29 AM, shad via cctalk wrote:
Hello,
I have a question about 9 track tapes and block sizes.
What I know is that tape is subdivided in files by means of marks, and each
file is subdivided in blocks of equal size.
This is not necessarily true. Many systems can handle &quo
On 9/17/20 6:19 AM, Paul Koning via cctalk wrote:
> CDC also supports "long blocks" in which the I/O for a single block is done
> in pieces, so blocks can be read or written that are longer than what you
> would think is the limit from the device limits. I'm not sure how long the
> longest
> On Sep 17, 2020, at 1:29 AM, shad via cctalk
> wrote:
>
> Hello,
> I have a question about 9 track tapes and block sizes.
> What I know is that tape is subdivided in files by means of marks, and each
> file is subdivided in blocks of equal size.
As others have
On 17/09/2020 07:38, Dave Wade G4UGM via cctalk wrote:
> The docs for SIMH .TAP files are here:-
>
> http://simh.trailing-edge.com/docs/simh_magtape.pdf
>
> be careful as there are also non-SIMH .tap formats
>
> In the IBM Mainframe emulation world there is also .AWS, an IBM format
> introduced
shad via cctalk wrote:
> Hello,
> I have a question about 9 track tapes and block sizes.
> What I know is that tape is subdivided in files by means of marks, and each
> file is subdivided in blocks of equal size.
> Programs like tar use a specific block size to create files on
Dave Wade wrote:
> The docs for SIMH .TAP files are here:-
>
> http://simh.trailing-edge.com/docs/simh_magtape.pdf
>
> be careful as there are also non-SIMH .tap formats
Haha, yes very much so. For the fun of it, people like to mix and match
these options:
- Records padded to even length or
> -Original Message-
> From: cctalk On Behalf Of Dennis Boone via
> cctalk
> Sent: 17 September 2020 06:53
> To: cctalk@classiccmp.org
> Subject: Re: 9 track tapes and block sizes
>
> > What I know is that tape is subdivided in files by means of marks, >
On 9/16/20 10:29 PM, shad via cctalk wrote:
> Hello,
> I have a question about 9 track tapes and block sizes.
> What I know is that tape is subdivided in files by means of marks, and each
> file is subdivided in blocks of equal size.
> Programs like tar use a specific block
> What I know is that tape is subdivided in files by means of marks,
> and each file is subdivided in blocks of equal size.
Er, no. The blocks aren't necessarily of equal size. Unix people who
are used to tar often seem to have this mindset, but the general case is
that records can be of
Hello,
I have a question about 9 track tapes and block sizes.
What I know is that tape is subdivided in files by means of marks, and each
file is subdivided in blocks of equal size.
Programs like tar use a specific block size to create files on tape.
However files can have different block sizes
55 matches
Mail list logo
