The history is that SMS had to choose between RAMAC or non-RAMAC devices when it built the EDL based on the AVAILABILITY value in the STORCLAS. Everything went to RAMAC, or nothing did. EMC and HDS solved this by setting a volume emulation that would respond to the RDC as a RAMAC, In HDS this was a 3390-3R, as opposed to 3390-3.
Later in the life of DFSMS 1.3 they allowed the field in STORCLAS set to blank to act as a noop, and boih type of volumes were treated equally in the EDL. It was actually an EMC box set to RAMAC emulation that I first saw this happening on. One 5500 in a farm of a more than a 100 HDS 7980 and 7690, and a clutch of Amdahl 6100 was getting almost every allocation until space caused the secondary device list to cut in. Can you say IO skew? It was a nasty problem to track down.
My guess is your problem starte with the original migration from HDS to EMC if they used SDMF. They were probably 3390-3R on the HDS. I've seen the same problem with HDS HODM.
Glad it's resolved.
Ron
From: Arden Tohill <Arden.Tohill@...> To: cbt-tape@yahoogroups.com Sent: Thursday, 21 May, 2009 3:11:12 PM Subject: Re: [cbt-tape] DISKMAP - File 792
Hi Ron,
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.
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.
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..
Need a Holiday? Win a $10,000 Holiday of your choice. Enter now..
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 ...
XMIT? Do it to a new PDS and once working from there copy / link between PDSs. ... -- Mike A Schwab, Springfield IL USA Where do Forest Rangers go to get away...
Hi Mike, Sounded like a good idea. First I allocated SYSA.LINKLIB2 as PO, recfm=U 0 x 27664 I used: XMIT (myid.mynode) DSNAME('myid.CBT477.FILE792.PDS')...
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...
Hi Ron, 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 ...
Arden, The history is that SMS had to choose between RAMAC or non-RAMAC devices when it built the EDL based on the AVAILABILITY value in the STORCLAS....
Having problems with message search?
Offline 
Send Email