Page 1 of 1

modify existing DSN to multivolume secondary extents

PostPosted: Fri Oct 25, 2019 4:52 am
by powderhound
i have existing non-sms managed file. it cannot allow the system to create extents automatically because it is used by a DB and requires formatting.
It has 2 extents on 1 volume (5300,700 CYLS). I need to add an extent on another volume. Getting a Not Catlgd 2 error IEF287I.

iefbr14
//DD1  DD  DSN=DB.PROD.DATA,DISP=(MOD,CATLG,KEEP),
//            UNIT=3390,SPACE=(CYL,(0,2000)),
//            VOL=(,,,2,SER=(C08,C11))  


when I change DISP=SHR - it avoids the Not Catlgd 2 error, but the catlog entry does not show the extended extents on the new volume C11.

1. should the catalog show the extent, even though it has yet been updated with any real data?
2. is this the proper way to add an existing extent? the first volume of full of data and do not want to delete/recreate it (would take significant time).

This is the catalog entry after trying above updates - SHOWING only the current 2 extents on the 1 volume C08. On other DSN with multiple volumes it shows "C08+" and then will list all the volumes (but these have been populated/formatted).
Data Set Name . . . . : DB.PROD.DATA                          
General Data                           Current Allocation                
 Management class . . : **None**        Allocated cylinders : 6,000      
 Storage class  . . . : **None**        Allocated extents . : 2          
  Volume serial . . . : C08                                          
  Device type . . . . : 3390                                            
 Data class . . . . . : **None**                                        
  Organization  . . . : PS             Current Utilization              
  Record format . . . : F               Used cylinders  . . : 6,000      
  Record length . . . : 10796           Used extents  . . . : 2          
  Block size  . . . . : 10796                                            
  1st extent cylinders: 5300                                            
  Secondary cylinders : 0              Dates                            
  Data set name type  : LARGE           Creation date . . . : 2018/03/12
                                        Referenced date . . : 2019/10/24
                                        Expiration date . . : ***None***


[Edit]Coded for you[/Edit]

Re: modify existing DSN to multivolume secondary extents

PostPosted: Fri Oct 25, 2019 5:53 am
by steve-myers
There are several errors here.
  1. This data set appears to be non-VSAM. Extent information is not shown in the catalog entry for a non-VSAM data set. The only source for extent information for non-VSAM data sets is the VTOC.
  2. No additional space was allocated in the IEFBR14 step because IEFBR14 did not open and write additional data to the data set.
  3. The SPACE data in the IEFBR14 step is not recorded in the VTOC. SPACE parameter data for an existing data set is only valid for the step, and only if your program is writing data to the data set. After the step completes the secondary allocation reverts to the original secondary allocation.
  4. A data set will extend to an additional volume only if the system cannot allocate another secondary extent on the first volume, or the system has allocated the maximum extents allowed for the data set on the first volume.
  5. As far as I know, it is not possible to permanently alter secondary allocation information for a non-VSAM data set. You can alter it for a step, and that's it.
Finally when you post screen data, use code tags, like this-
                            Data Set Information
Command ===>

Data Set Name . . . . : XXXXXX.HLASM.V2L4.CBT.PDS.XMIT

General Data                           Current Allocation
 Management class . . : **None**        Allocated blocks  . : 26
 Storage class  . . . : USER            Allocated extents . : 1
  Volume serial . . . : VVVV13
  Device type . . . . : 3390
 Data class . . . . . : **None**       Current Utilization
  Organization  . . . : PS              Used blocks . . . . : 9
  Record format . . . : FB              Used extents  . . . : 1
  Record length . . . : 80
  Block size  . . . . : 27920
  1st extent blocks . : 26
  Secondary blocks  . : 51
  Data set name type  :                 SMS Compressible  . : NO

  Creation date . . . : 2019/10/22      Referenced date . . : 2019/10/22
  Expiration date . . : ***None***

The extent information in this report was extracted from the VTOC and then massaged to transform track information (as it is stored in the VTOC) to block information or cylinder information depending on the initial allocation.

I deal with multiple volume data sets so infrequently I do not know how ISPF Data Set Information formats them.

Re: modify existing DSN to multivolume secondary extents

PostPosted: Fri Oct 25, 2019 1:30 pm
by willy jensen
requires formatting.

I'm pretty sure that the only way to do this is to start by having a formatter job / task allocate and format the extents. Certainly you cannot add an extent with IEFBR14 as it will create a new dataset, hence the 'not cataloged' message. And as mentioned by mr steve-myers you cannot force the 2nd extent to go the 2nd volume if sufficient space exits on the 1st volume.
So, pre-allocate and format a new dataset, then copy the contents of the old, then rename both. Yes that means that the dataset must be unallocated from DB2 for the duration.

Re: modify existing DSN to multivolume secondary extents

PostPosted: Fri Oct 25, 2019 4:49 pm
by steve-myers
I agree with Mr. Jensen. When I was writing my post I had thought about that issue, but since I know little about DB2, I decided to ignore it.

Re: modify existing DSN to multivolume secondary extents

PostPosted: Fri Oct 25, 2019 8:11 pm
by powderhound
thanks so much guys. I was wondering about those details and your explanations are very clear. Thanks also for the quick response. Appreciate it much. Will monitor this forum and hope to contribute as well. Will be using and format utility to actually extend the non-vsam DSN.

Re: modify existing DSN to multivolume secondary extents

PostPosted: Sat Oct 26, 2019 8:55 pm
by kevinf2349
Just a heads up, but the same thing (formatting) is required for WebsphereMQ datasets too.

No big surprise as it is only DB2 under the covers anyway. :)