Re: Recover an 3490e tape that was initialized -- MIDRANGE-L

WHEW!  Ummm, I agree with Al, $1000 bucks doesn't sound all that bad to retrieve
the data now.
Gary

"Al Barsa, Jr." <barsa2@ibm.net> on 12/15/99 01:38:06 PM

Please respond to MIDRANGE-L@midrange.com

 To:      MIDRANGE-L@midrange.com                             

 cc:      (bcc: Gary Feinstein/Boca/DRG)                      

 Subject: Re: Recover an 3490e tape that was initialized      

At 07:45 PM 12/14/1999 -0600, you wrote:
> > Well folks, I got the stupids the other day and initialized three 3490e
> > tapes that had back up data we need (badly). Fortunately I did not clear
> > the tapes.   I called IBM support, who then pushed me to consult line, and
> > sure they can recover the tapes for $1,060.00 per tape.
> >
> > Does anyone have a program that will recover the data on a tape like this?

I did this many years ago.  Here's what I did:

1.      I took the tapes to a S/370, and used a tool called "ditto" to
remove the initialized tape headers.

2.      This exposed the underlying files that remained on the tape.  Every
file on the tape was made up of three files, a "header", the "data" and a
"trailer".  (These were my names.  This was before I had any good ties to
Rochester, where I could have probably gleaned some help.)

3.      The "header" clearly identified the name of the file, the "data"
was the data (interspersed with a lot of other garbage) and my conclusion
was that the "trailer" was useless.

4.      The "data" portion was a series of records that were 32760 bytes
long.  Note that this was before the introduction of the USEOPTBLK
parameter in V3R7.  With USEOPTBLK(*YES) specified, the system writes
records that are 262144 bytes long.  The default for USEOPTBLK was changed
from *NO to *YES at either V4R1 or V4R2.  (This would provide significant
complication to my RPG decoding process that I describe in step 7 below.)

5.      Keep in mind that when I did this, it was before compression and
compaction.  These would have significantly impacted the effort.  IBM
documents it's compression algorithm, but I have never seen the compaction
algorithm published.  (This does not indicate that they don't publish it,
or that it's not available.  It is merely an indication of ignorance on my
part.)

6.      Somewhere in the second record, a null record appears.  My
conclusion was that this had to be determined by observation, but I'm sure
that there is a rhyme or reason where it appears.  Immediately thereafter,
data starts to appear.  Each record is proceeded by a "delete byte".  My
recollection is that active records are proceeded by a hex '80', deleted
records are proceeded by a hex 'A0' , and "damaged records" (those damaged
by save/restore, and subsequently re-written, because they span from one
32760 record to another) and proceeded by a hex 'C0'.  (These records
should be discarded.)   DO NOT take my hex codes to the bank, I could
possibly be faulty in my recollection.  All the files that I recovered were
single membered, but I subsequently learned that multi-membered files
started a new record.

7.      I read the 32760 records in an RPG III program.  I first copied
(using CPYF) the 32760 records into a *PF with four fields (A, B, C, D).  I
then build a *LF for each field.  The RPG III program read file A as
primary, and chained for the balance.

This whole incident occurred in 1986 under CPF release 6.0.  A lot has
happened to save/restore since then, much of which I have documented
above.  Also, my memory is just a tad hazy over 13 years.  I stole computer
time on every System/38 I could get my hands on in Manhattan.  From
end-to-end, the entire process took 18 days of evening (otherwise) unused
computer time at night.  I recovered over 3 million records (which was a
lot then).

The company where all of the tapes were initialized had filed for
bankruptcy, and since has gone on to be successful.

I hope this helps.

Al

PS:  Don't initialize your tapes.

PPS:    Pay the money and don't bitch.

+--------------------------------------------------+
| Please do not send private mail to this address. |
| Private mail should go to barsa@ibm.net.         |
+--------------------------------------------------+

Al Barsa, Jr. - Account for Midrange-L
Barsa Consulting, LLC.
400 > 390

Phone:         914-251-1234
Fax:      914-251-9406
http://www.barsaconsulting.com
http://www.taatool.com

+---
| This is the Midrange System Mailing List!
| To submit a new message, send your mail to MIDRANGE-L@midrange.com.
| To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com.
| To unsubscribe from this list send email to MIDRANGE-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com
+---

att1.eml




-----------------------------------------------------------------------
Gary Feinstein
IS Manager
Data Resource Group
1-800-852-0323 x 111