Writing multiple volume sequence data set

gcicchet · Senior Member Joined: 28 Jul 2006 Posts: 663

Hi,

I'm curious to know what the file looks like after running REPRO1 step only
ie. how many volumes does the dataset span across.

Also 300,300 tracks does not guarantee a total of 4800 tracks

see http://ibmmainframes.com/viewtopic.php?t=26006&highlight=gerry+extents

Gerry

Mainopr · New User Joined: 05 Feb 2007 Posts: 11 Location: HK

Hi gcicchet,

After each step the usage information will be look like that :

gcicchet · Senior Member Joined: 28 Jul 2006 Posts: 663

Hi,

can you try changing from 300,300 to 300,299 , again I'm interested to know if the space allocated on the 2nd and 3rd volumes is the secondary space or the primary.

Also can you do a LISTC next to the dataset after REPRO1 step.

What happens if you just specify UNIT=(SYSDA,3) and no VOL parameter ?

Gerry

expat · Posted: Thu Aug 14, 2008 4:47 pm Post subject:

I think that your results would be different if you tried to repro only the COUNT(8000) in the first step.

The first step allocates your dataset, 300 tracks on 3 volumes. And then writes to the dataset.

The subsequent steps overwrite the existing data but are adding more data with each test step. When the first extent on the first volume is used up the system knows that a second extent exists on another volume, so will use that without extending on the first volume.

The same holds true for the second volume, an extent of free space exists within the pre allocated file so gets used. Now we are on the last volume of the sequence, and any extra extents will be allocated on that volume and that volume alone.

So if you ask me, not the very best way to go about performing space allocation.

gcicchet · Senior Member Joined: 28 Jul 2006 Posts: 663

Hi,

I just managed to test this unusual space set up, the first step allocates 300 tracks on the first volume only, the catalog lists all 3 volumes.

The dataset does not exist on vol 2 and 3.

Next step extends the dataset to 2nd volume but using the secondary space value.

Next step extends the dataset to 3rd volume again using the secondary space value.

The 4th step continues using the 3rd volume until in runs out of extents.

Now if DISP=MOD was used it continues writing to VOL 1 until it reaches 16 extents and then it continues with VOL2 until it reaches 16 extents and then onto VOL3.

The primary space is only ever used on the first volume.

Gerry

expat · Posted: Thu Aug 14, 2008 5:21 pm Post subject:

Gerry,

Are you using NON SMS managed DASD, or SMS managed ?

gcicchet · Senior Member Joined: 28 Jul 2006 Posts: 663

Hi Expat,

I made sure I used non sms managed volumes. when I tested against SMS managed volumes the catalog only showed 1 volume.

Gerry

expat · Posted: Thu Aug 14, 2008 5:31 pm Post subject:

OK OK, only asking

The problem is with the way that the file has been set up, and/or used. It is pre allocated for the second and subsequent steps, and as stated in my post above, will not extend on the first and second volumes.

Methinks that your use of DISP=MOD would be the best solution, except that I'm never happy using DISP=MOD. Probably stems from my early years when hardware and media were not so damned reliable.

gcicchet · Senior Member Joined: 28 Jul 2006 Posts: 663

Hi Expat,

I agree with you with DISP=MOD, the minute it runs out of space the file is useless, some of the data has already been appended.

A pain in the SAS

Gerry

expat · Posted: Thu Aug 14, 2008 6:10 pm Post subject:

Mainopr · New User Joined: 05 Feb 2007 Posts: 11 Location: HK

Hi all,

Thanks for all of your messages.

I finally found that it should be caused by a FEOV macro. I am going to use storage pool instead of delicated volumes to sovle the problem.