Writing multiple volume sequence data set

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

I have writing to a QSAM data set that allocated with three volumes(DASDs). However, the data set seems cannot be extented on the first 2 volumes even there is enough space.

The JCL is simplifed as follow :

Anuj Dhawan · Posted: Wed Aug 13, 2008 10:29 am

Hi,

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

Hi Anuj D.,

Thank you for your message.

As I know a QSAM data set should be able to extent on same DASD for 16 times before it try another volume.

However, when I use ISPF(Dslist) to see the data set, it shows that the data set have used 3 volumes with the first 2 volumes using only 1 extent and 3 extents at last volume.

DSNAME VOL Tracks %Used EXT Device
TEST.OUT DISK01 300 100 1 3390
TEST.OUT DISK02 300 100 1 3390
TEST.OUT DISK03 900 81 3 3390

And there is no error message.

Thanks.

Robert Sample · Posted: Wed Aug 13, 2008 2:55 pm

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

Hi Robert Sample,

I had checked those DASDs have enough space for the file to further extent.

Thanks.

expat · Posted: Wed Aug 13, 2008 3:12 pm

How is the fragmentation - just because enough space exists on a volume it does not mean that it can be used.

Anuj Dhawan · Posted: Wed Aug 13, 2008 3:17 pm

Hi,

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

Hi all,

In fact, those are empty DASDs. And they have large enough CONTIG space for further extent.

Thanks all.

Robert Sample · Posted: Wed Aug 13, 2008 5:54 pm

It looks to me like the system is doing exactly what you told it to do. You told the system to allocate the dataset on 3 disk packs. It did so. Once the dataset has been allocated on 3 disk packs, whether or not the first and second disk packs use one extent or not is irrelevant -- datasets only extend at the end. From your comments, it appears that you want to allocate the dataset on DISK01, fill 16 extents, allocate on DISK02, fill 16 extents, then allocate on DISK03. This is not going to happen the way you've defined the dataset.

You're better off using SMS-managed disks for what you want to accomplish. If you cannot, you could try allocating on DISK01 as a single-volume dataset and when adding records override the VOL=SER parameter.

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

Hi Robert Sample,

Thanks a lot for your message.

I am intent to ensure that there is total 14400 tracks for the dataset. If the data set cannot be extented on the first two volumes, it will only have a max. of 5400 tracks to store data, which may casue B37 in my case.

For some reasons, I have to define the dataset with TRK,(300,300) instead of TRK,(4800,0) at once with multi-volumes.

Robert Sample · Posted: Thu Aug 14, 2008 8:08 am

While I understand what you're saying, it's not making a whole lot of sense. Even though extents aren't as costly as they used to be, they're still not free -- it'll take longer to go through the extents than reading a contiguous file. And you're only needing 960 cylinders, which is less than one-third of a 3390-3; not a huge file by any means these days.

I am not familiar enough with allocation processing to be able to fully answer your question, but under the restrictions you've listed (which I would first try very hard to get modified by your storage administrators), I would allocate to DISK01 only. Then use IDCAMS ADDVOL command to add DISK02 and DISK03; I don't know that extents would still come at the end of the dataset in this case.

If I really absolutely had to do it the way you describe, I'd allocate to DISK01, run a SAS job to write enough records to fill 16 extents, then the next step would use IDCAMS ADDVOL to add DISK02 to the dataset, then run a SAS job to write enough records to fill the 16 extents on DISK02, then repeat the ADDVOL and SAS job with DISK03. This six-step job is the only way I know for sure to accomplish what you're wanting under the restrictions you've given.

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

Hi Robert Sample,

Many thanks to you. Maybe my example has misleading you.

The (production) dataset that I going to deal with has size varying from day to day but not more than 13,000 cyls. Due to the limitation that each volume can held up to 65535 tracks.Thus, I have define it on three 3390-9 DASDs at once initially.

P.S. Sadly our shop is not familiar with large dataset DSNTYPE=LARGE, hence I am not allowed to use it

.

dick scherrer · Posted: Thu Aug 14, 2008 8:56 am

Hello,

Once built, how will this "file" be used?

What has established the requirement that it be built in only this way?

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

Hi dick scherrer,

This file is used to store daily transaction on a monthly base for history enquiry. The data will be migirated to tape before it is cleaned up every month. It is estimated that the max size will be 13,000 Cyls.

In my shop, we mainly use 3390-9 DASDs. Besides, it is suggested that not to set the primary size too large to avoid fragmentation since those volumes maybe shared with other datasets. Thus, the dataset is defined on multi-volumes with a secondary size > 0.

Thanks.

expat · Posted: Thu Aug 14, 2008 11:42 am

Given the situation, I would talk to the storage people and suggest that you allocate 5,000 cylinders on each volumes.

If SMS is not installed then the release of free space and unused extents should not be a problem.

As long as you explain your problem to the storage people they will be aware of the dataset and will not take action against it, and will also be aware of how to treat it when SMS is installed. Once it is, I would suggest SDS (Sequential Data Striping) which allows you to allocate the file over a number of volumes in one hit i.e. SPACE=(CYL,(15000))

gcicchet · Posted: Thu Aug 14, 2008 12:38 pm

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 · Posted: Thu Aug 14, 2008 4:37 pm

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

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 · Posted: Thu Aug 14, 2008 5:18 pm

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

Gerry,

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

gcicchet · Posted: Thu Aug 14, 2008 5:24 pm

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

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 · Posted: Thu Aug 14, 2008 5:55 pm

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