Hi Bob,

Good for you that you built a replacement MVS system at your DR location.
I agree with Mark’s comments and absolutely there is backwards
compatibility for 9840x type drives.  Generally this is the case for IBM
Mainframe tape drives and only when the drive format changes is backwards
compatibility not maintained (E.g. 3420 – 3480, 3480/3490 – 3590, RedWood –
 9n40x, Etc.), but then we know this when we commission the new technology.

There’s some information regarding the StorageTek 9840 VolSafe feature
being 9840x drive/media specific, but I guess this doesn’t apply to you:

http://www.imation.com/support/products/data_center_tape.html#06
http://www.storagetek.com/products/product_page2441.html#applications

For sure tape media needs to acclimatise when it moves from one place to
another, as per the above StorageTek link and this suggests that the
Relative humidity (storage up to four weeks) figure is 5% to 80%, which
hopefully was OK for your situation?

The IOS1000I message is pretty generic and the rest of the codes in the
message would be useful:

I would be surprised if this was an FDR/ABR software issue and I suspect
if it’s happening for many tapes then it’s probably a HCD (E.g.
IOCP/MVSCP) configuration issue.  Seemingly VolSafe has implications, as
will replicating the tape I/O path for your scenario, which would seem to
include HCD & HSC/VTCS for defining the 9840C drive in emulation mode.
Stating the obvious, I think your best bet is to engage StorageTek and ask
for their support, but by all means send us an example IOS1000I message,
and I’m sure the IBMMAIN folks will do their best to assist you.

Keep up the good work…

Regards, UK Mikey.

On Sun, 4 Dec 2005 18:54:22 -0500, [EMAIL PROTECTED] <[EMAIL PROTECTED]>
wrote:

>I work for a federal agency that ran like hell from Katrina and her ugly
>sister Rita; we are currently processing out of a Sungard site where we
built
>an entire MVS computer center in 5 weeks.
>
>We have 9840 tapes that were created on STK 9840 A/B tape architecture
(Gen'ed
>as IBM 3590's tape devices) and we are unable to read the data off some of
>these tapes utilizing STK 9840C tape drives.
>
>My question is this?
>Has anyone experienced any problems reading backup tape data  (using
FDRABR)
>that was created on STK 9840A/B tape architecture then try to read the
data
>from STK 9840C tape architecture??
>
>
>The problems we are experiencing are many but I do not understand why if
I am
>attempting to restore a DSN from the same tape and it is mounted on a
>different 9840C drive each time; it may fail 4 times
>getting an IOS000I error message
>then on the 5th time the DSN will restore successfully.
>
>Please understand these tape were created in August 05 and set in New
Orleans
>in STK silos for a few weeks with the air conditioning turned off before
we
>were able to get them.
>
>STK/SUN and IBM have been very helpful in this Regional Disaster: in
addition,
>there are many other companies that have assisted our agency in this
tragedy.
>
>Bob Cosby
>SEB
>504-426-2460
>[EMAIL PROTECTED]

We routinely do this at DR drills without any problems. Using the 9840Cs
gives us extra drives since the A/Bs are limited. As a matter of fact I
just got back from a drill this morning where we did this.  This was
for native drives.   At our data center this had to work because we
converted our back end VSM drives (RTDs) from 9840B to 9840C earlier
this year.   There are still a lot of MVCs that are in 9840B format
that are read on the 9840C drives thoughout the day every day.

If you are working with the vendor then this shouldn't be news to you.
I don't know why you are having problems, but it's not because you're doing
something that isn't supported.

Regards,

Mark
--
Mark Zelden
Sr. Software and Systems Architect - z/OS Team Lead
Zurich North America and Farmers Insurance Group

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Reply via email to