Having problems with message search?
Yes, SRDF was used. DMX-2000 to DMX-3. Prior to this (about 5 years ago) the data lived on an Hitachi array. My current thinking is that somewhere along the way, the VTOCs (296 out of 748 migrated volumes) got some bits set that the (emulated) 3990 CUs of the DMX-2000 didn't care about but that cause heartburn to the (emulated) 2107 CUs in the DMX-3.
I got info back from EMC indicating that certain levels of Enginuity (EMC's 'storage operating environment' i.e. firmware) can mis-report the alternate cylinders. The problem is fixed, as you suggested, with ICKDSF REFVTOC.
I've run DSF against the offending volumes and they now run cleanly -- with both versions of DISKMAP.
Good call (and good recall), Ron.
Arden
On Thu, May 21, 2009 at 11:26 AM, Ron Hawkins <ronhawkins1@...> wrote:
Arden,Did you migrate the volumes using SDMF, TDMF, SRDF or something similar? This sounds like an old problem that occurs when copying from standard volumes formats to RAMAC format volumes.If I recall correctly it's fixed by running a REFVTOC.Ron
From: Arden Tohill <Arden.Tohill@...>
To: cbt-tape@yahoogroups.com
Sent: Tuesday, 19 May, 2009 8:07:16 AM
Subject: [cbt-tape] DISKMAP - File 792
Hi,
Background:
We just converted from EMC DMX2000 (3990 cu) to DMX-3 (2107 cu). The version of DISKMAP (CBTTAPE 471 file 260 2/22/05) is now showing (in the TRACK ALLOCATION MAP)
INVALID EXTENT on the last extent
and
xxx TRACKS MISSING OR ASSIGNED TO ALTERNATES
I want to try file 792 to see if the updates take care of this.
Question:
Since we are not yet zOS 1.10, I cannot assemble the program and have to use the thoughtfully- supplied load module ... BUT ... how do I copy the recfm=FB load module to a recfm=U load library?
Thanks,
Arden
Need a Holiday? Win a $10,000 Holiday of your choice. Enter now..
Offline 
Send Email