Storage Class not assigning properly

tigerwing · Posted: Wed Feb 13, 2008 12:59 am

I am running z/OS 1.8 and am having a problem with how dataset allocation is working on one of my LPARs. I have 3 LPARS all sharing the same DFSMS configuration. When I allocate a dataset on LPAR 'B', the dataset is going to an Overflow pool instead of the pool being assigned by DFSMS. When I allocate the same dataset on the other 2 LPARs, it get allocated to the properly assigned pool. This dataset is only a cylinder in size, and the Storage-group it is being assigned to has over a 200,000 tracks free. All of my DASD is shared across all 3 LPAR's.

I don't see any error messages, and I have reloaded the configuration several times with no effect.

I don't know why it is happening only with one LPAR and not the others.

Anyone have any ideas for me to look at??

Dave

expat · Posted: Wed Feb 13, 2008 12:46 pm

Have you checked to see that all storage groups are available to all LPARs, that's a common problem. Sometimes the SG can be split into sub groups for individual LPARs and sometimes the DASD are not made available properly.

Are there any quirks in the ACS routines that are LPAR dependant and would do this.

tigerwing · Posted: Wed Feb 13, 2008 7:16 pm

Thanks for your response.

All volumes and storage groups are available on all the LPARs. This problem only happens sporadically, it is not a constant problem. That's what makes this hard for me to figure out what is going on.

Ninety percent of the time, everything works fine, it's the other 10% that gives me fits.

There is nothing in my ACS routines that are LPAR specific.

Thanks again.

expat · Posted: Wed Feb 13, 2008 7:30 pm

The only recall of a similar problem is when the DASD pool in question was being heavily used, and for a short periods of time the high thresholds on the DASD were reached so any new allocations went to the overflow pool.

Hey, maybe you really do have gremlins in the system

tigerwing · Posted: Wed Feb 13, 2008 7:46 pm

I could understand that better if it happened on the other LPARs as well, but it is happening on only one LPAR, and it isn't the busiest one either.

Thanks for your help.

expat · Posted: Wed Feb 13, 2008 8:15 pm

Good luck tracking it down, and please let us know if you do.

tigerwing · Posted: Fri Feb 15, 2008 2:17 am

I was able to solve my problem. I went into the ISMF panels and selected Storage Classes. I then found a parameter named Multi-Tiered SG. It was blank, so I put a 'Y' in it and run some tests.

All is well now and I have not had one bad dataset allocation yet.

Thanks again to everyone.

dick scherrer · Posted: Fri Feb 15, 2008 2:28 am

Thank you for posting what you found

d