1827059 Members
4325 Online
109713 Solutions
New Discussion

tape (reel to reel) dump

 
SOLVED
Go to solution
Carol Balla
Advisor

tape (reel to reel) dump

I am trying to dump a tape to a file and not getting readable file. Tape is 6250/1600 bpi, 86 characters/record, 10 records/block. I'm using
dd if=/dev/rmt/0m of=/restore/proc cbs=86 ibs=860 (and other variations of dd)
output is diagonally when I more proc
What am I missing?
HP-UX 10.20
Thanks
Carol
34 REPLIES 34
A. Clay Stephenson
Acclaimed Contributor

Re: tape (reel to reel) dump

Hi Carol:

Unless you are doing an ASCII/EBCDIC conversion, you don't need or want cbs.

I suspect that all you really need
is:
dd if=/dev/rmt/0m of=/restore/proc bs=860

If you are doing other conversion, please let us know. I not sure what you mean by 'more diagonally' but I think you are saying that you need LF's in the output rather than CR's.

Clay
If it ain't broke, I can fix that.
harry d brown jr
Honored Contributor

Re: tape (reel to reel) dump

if the data isn't too sensitive, could you post a few blocks for us? Could it be that the record size is not 86? Is this tape an ebcdic tape or ascii?
Live Free or Die
Lou Zirko_1
Frequent Advisor

Re: tape (reel to reel) dump

Yes, better responses would be forthcoming if the source of the data was known and how the tape was written.

Based on what you have said so far I try this dd line:

dd if=/dev/rmt/0m of=/restore/proc cbs=86 conv=block

Lou Zirko
Carol Balla
Advisor

Re: tape (reel to reel) dump

attached is the file generated from
dd if=/dev/rmt/0m of=/u6/carol/restore/proc1 bs=860
no other conversion, file is. I am getting record size from documentation that came with tape. The easiest thing to pick out is * is in column 14.
Carol
Frank Slootweg
Honored Contributor

Re: tape (reel to reel) dump

As others have also asked, please give some more details about the data format/code.

What do you mean by "output is diagonally when I more proc"? What does "diagonally" mean? I.e. post a small example of the (wrong) output.

Having said this, I advise to first check the *real* record size:

dd if=/dev/rmt/0m of=/tmp/record bs=64k count=1 ; ll /tmp/record

If the size of /tmp/record is 860 bytes, then the record size is indeed 860 bytes and you should use ibs=860.

Next do:

dd if=/dev/rmt/0m ibs=... count=1

and post the result.

You also may want to experiment with the conv=... options. In any case, start with count=1 and only go beyond that when you can successfully read and display the first record. When that works, use count=2 to see if you have any inter-record issues.
Carol Balla
Advisor

Re: tape (reel to reel) dump

see attached - I have run with count=1 and count=2 as requested by Frank.
Frank Slootweg
Honored Contributor

Re: tape (reel to reel) dump

Concerning your second (11:21 AM) example, please first check the *real* record size as I have indicated in my earlier (10:13 AM) response, because you have done your second example with ibs=86 while your original posting implied and used a record_size/ibs= of 860.

When you post again, please do not use a proportional font. Now we can not see whether the second line has two undesired leading spaces or more/less. If it *has* two undesired leading spaces, then maybe, just maybe, the unblocked (or real?) record size is 88 (not 86).
Carol Balla
Advisor

Re: tape (reel to reel) dump

Frank- I have attached another document (sorry for previous format) in which I have run 4 different ways.
Thanks
Carol
Carlos Fernandez Riera
Honored Contributor

Re: tape (reel to reel) dump

Must must include block

dd if=.. of=.. ibs=860 cbs=860 conv=ascii,block

See man dd

See this too:
http://forums.itrc.hp.com/cm/QuestionAnswer/1,11866,0xbdbe6af52b04d5118fef0090279cd0f9,00.html

unsupported
Frank Slootweg
Honored Contributor

Re: tape (reel to reel) dump

Carlos, I don't think that "ascii" (in "conv=...") is needed/good, because the data is apparently already in ASCII. Using "conv=ascii" on ASCII data will make it unreadable. But, perhaps the "block" (in "conv=...") is a good idea (I already advised earlier to play with the "conv= options).

Carol, I have also seen your third (12:10 PM GMT) example. Apparently there are 6 (12, ...) leading spaces. However I do not know how to get rid of them because the 'line-terminator' (linefeed) seems to be in the records, otherwise more(1) would display just one long line.

Can you do my very first example (dd if=/dev/rmt/0m of=/tmp/record bs=64k count=1 ; ll /tmp/record), which you still have not done, post the output from that command line and *attach* the /tmp/record file? (Make sure that you attach an *exact* *binary* copy of the file. If you have to FTP it before attaching, then make sure the FTP is done in binary mode ("binary" command) and compare the source/target file to have the exact same size.)

Another 'brain-wave': As far as I can tell, the first line (ending with "EXCISION") is 76 (not 86) characters long. There are 6 unwanted
leading spaces on the second line. 76+6 = 82 = 80+2. 80 is a common length for a 'punched-card' record. The remaining 2 characters could be carriage-return and line-feed.

Therefor it is perhaps wise to try:

dd if=/dev/rmt/0m of=/u6/carol/restore/proc1 ibs=... count=3

Where you slowly, byte for byte, decrease "..." from 86 (your old value) to 76, i.e. 86 -> 85 -> 84 -> ... -> 76.


harry d brown jr
Honored Contributor

Re: tape (reel to reel) dump

How about doing this and showing us the output:

dd if=/dev/rmt/0m ibs=860 count=1 | od -xc

That way we can see a full block with any imbedded control characters.

thanks
Live Free or Die
Carol Balla
Advisor

Re: tape (reel to reel) dump

Frank:
ran dd if=/dev/rmt/0m of=/tmp/record bs=64k count=1
FTP with Binary as requested.

Tried conv= ?? with different options with no improvement.
A. Clay Stephenson
Acclaimed Contributor

Re: tape (reel to reel) dump

Hi Carol,

Unfortunately your attachments don't help much because it is difficult to really know the amount of whitespace in the data. Also if you data really is blocked at 860 bytes/record, you must specify an ibs (or bs); you are using 512 right now (the default) but as soon as we go into the next record everything will be off. Typically if one needs to reblock, it is often does in a pipeline of two dd's. The first simply gets the data and the next does some processing. But right now, we really need two blocks of raw input data in a readable form. The rest should be very easy from that point.

Do this:
dd if=/dev/rmt/0m bs=860 count=2 | od -v -Ad -tc > myfile.out

myfile.out should then be posted and will contain exactly the needed data plus the offsets.

Clay
If it ain't broke, I can fix that.
Carol Balla
Advisor

Re: tape (reel to reel) dump

Harry:
please see attached.
Carol
Frank Slootweg
Honored Contributor

Re: tape (reel to reel) dump

Great suggestion, Harry! Bummer, why didn't I think of that!? :-) Losing my touch? :-(

Carol, if the size of the /tmp/record file (see my responses) is different from 860, then please (also) post Harry's example with ibs=...., where ... is the size of the /tmp/record file.
Carol Balla
Advisor

Re: tape (reel to reel) dump

Clay:
I FTP binary.

Carol
harry d brown jr
Honored Contributor

Re: tape (reel to reel) dump

Carol,

I'm sorry, I wanted you not to specify an output file, and pipe the output to "od -xc":

dd if=/dev/rmt/0m ibs=860 count=1 | od -xc


Live Free or Die
Frank Slootweg
Honored Contributor

Re: tape (reel to reel) dump

Carol, you made an error.

You used:

dd if=/dev/rmt/0m of=/u6/carol/restore/proc1 ibs=860 count=1 | od -xc

But Harry asked for:

dd if=/dev/rmt/0m ibs=860 count=1 | od -xc

Because you included "of=..." the od(1) command did not get any input and hence gave no (usable) output.

I will try to have a look at your 14:13 PM GMT attachment, but for the moment let's concentrate on getting Harry's example right.

Carol Balla
Advisor

Re: tape (reel to reel) dump

Harry & Frank:
Not to be dim but how would you like me to get you information from command
dd if=/dev/rmt/0m ibs=860 count=1 | od -xc

if I don't dump it to a file?
A lot of data scrolled by on my screen.
Carol
harry d brown jr
Honored Contributor

Re: tape (reel to reel) dump

You aren't being dim, how about this:

dd if=/dev/rmt/0m ibs=860 count=1 | od -xc > /tmp/stuff

then attach /tmp/stuff

thanks :-))
Live Free or Die
Carol Balla
Advisor

Re: tape (reel to reel) dump

I hope you wanted binary.
Carlos Fernandez Riera
Honored Contributor

Re: tape (reel to reel) dump

record length is 86.

When you copy form attached file it take two tabs that are not in original file.

dd if=file of=fileo ibs=860 bs=86 cbs=100 conv=block must run.
unsupported
A. Clay Stephenson
Acclaimed Contributor

Re: tape (reel to reel) dump

Hi Carol:

Your dd to od output was perfect. You do indeed have 86 byte records with a blocking factor of 10 for 860 bytes per input block

It appears that you want a LF terminated record. We could do that by converting your data to ebcdic and then back to ASCII but that could introduce translation errors. Fortunately, I already had a very small utility in C which will compile with the bundled C compiler and can add the LF or CR/LF if you like. I'll attach that code, called fpad.c.

Compile it like this:
cc fpad.c -o fpad

If you like, you can execute fpad without arguments and it will display a usage message.

Here's the command to get your LF delimited output:

dd if=/dev/rmt/0m ibs=860 obs=86 | fpad -o 86 -i 86 -t 1 > myfile.dat

The -o 86 tells fpad to create 86 byte output records, the -i 86 tells fpad to expect 86 byte fixed-length input records, the -t 1 tells it to append a LF to each output record to actually create an 87 byte output record.

Clay
If it ain't broke, I can fix that.
harry d brown jr
Honored Contributor
Solution

Re: tape (reel to reel) dump


Carol, try this to convert it:

dd if=/dev/rmt/0m of=/restore/proc conv=unblock ibs=860 obs=86 cbs=86
Live Free or Die