× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.


  • Subject: Re: Recover an 3490e tape that was initialized
  • From: "Al Barsa, Jr." <barsa2@xxxxxxx>
  • Date: Wed, 15 Dec 1999 10:38:06 -0800

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
+---

As an Amazon Associate we earn from qualifying purchases.

This thread ...

Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.