SMS STORGRP question

[Jesse 1 Robinson]

'Forever' we have directed DUMPSRV SVC dumps via ACS routine to STORGRP 'SVCDUMP', which is defined to a small set of volumes called SVCDxx. We had a (major) problem a while back when DB2/CICS wanted to take a humongous dump that exceeded the available capacity of of the SVCDxx volumes. So we *added* group 'OVERFLOW' to the ACS routine expecting this much larger group to accommodate dumps that SVCDUMP could not handle. Much to our chagrin, from that moment forward, *all* SVCDUMPs went directly to OVERFLOW without even trying to find space in group SVCDUMP. We have an RYO mechanism to manage dumps created on volume SVCDxx, so dumps created elsewhere are a problem we can live with on occasion but not regularly.

I know there are various ways to resolve to this problem, but I want to know why SMS is behaving this way and whether there is a purely SMS solution: try SVCDUMP first; if no room, then try OVERFLOW. In that order.

.
.
J.O.Skip Robinson
Southern California Edison Company
Electric Dragon Team Paddler
SHARE MVS Program Co-Manager
323-715-0595 Mobile
626-543-6132 Office <===== NEW
robi...@sce.com<mailto:robi...@sce.com>


----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to list...@listserv.ua.edu with the message: INFO IBM-MAIN

[Feller, Paul]

It has been a little while working directly with SMS, but if your volumes in the OVERFLOW storage group are in an ENABLE status then SMS will treat them the same as the volumes in the SVCDUMP storage group. SMS will look for the best "fit" for the dataset allocation. So if OVEFLOW has more free space and/or less fragmented or is on "faster" DASD then SMS may pick OVERFLOW over SVCDUMP.

Depending on your needs, you might consider a special management class for the dump datasets that will migrate them quicker than your normal other datasets. That may help manage things on a more automatic basis.

Thanks..

Paul Feller
AGT Mainframe Technical Support

[Scott Chapman]

My recollection is that we used to solve this sort of problem (only use these volumes if you absolutely have to) with what we called an "internal spill pool". Basically we added volumes to the storage group that were in status quiesce(new). If something appeared on those volumes we became interested in why. (E.G. it may be time to expand the storage group, or maybe it was an exceptionally large allocation.)

I don't recall the mechanism in SMS for the order that eligible storage groups are selected in, if there is one. I rather believe that all volumes in the eligible storage groups are added to the eligible list and evaluated the same regardless of which SG they're in. But I could be wrong about that.

Scott Chapman

[Lizette Koehler]

So there was a presentation in 2011 at Anaheim by Steve Huber on SMS Volume
selection. I found it by going to an internet browser and entering

HOW DOES IBM SMS CHOSE VOLUMES?

And top of the list was this entry Presentation title

DFSMS Basics: How SMS Volume Selection Works

Then I could search on it and find others.



Here are the points he presented on selection

Conventional Volume Selection

. Used for all non-striped data sets
. Used for all data sets with zero or blank SDR
. Uses a preference sequence to sort volumes in the candidate storage groups
into:
. Primary
. Secondary
. Tertiary
. Rejected



Meet data set separation requirement

. SMS storage group and volume statuses are enabled
. MVS status is online
. IART requirement is met
. Number of volumes in storage group >= volume count
. Accessibility requested can be met
. Availability requested can be met
. Meets the guaranteed space requirement
. Can perform the allocation & stay below high threshold
. For MSR=999, volume is non-cached (MSR= Milli Second Response)
. Data class extended format request can be met

After that, it if nothing meets this, SMS will go through some other iterations
to select a volume. Remember SMS does not think like a human. It sets
priorities of volumes then makes a selection. Which is not what we might have
chosen. ;-D

HTH

Lizette

> -----Original Message-----
> From: IBM Mainframe Discussion List [mailto:IBM-...@LISTSERV.UA.EDU] On
> Behalf Of Jesse 1 Robinson
> Sent: Friday, April 21, 2017 5:43 PM
> To: IBM-...@LISTSERV.UA.EDU
> Subject: SMS STORGRP question
>

[Vernooij, Kees - KLM , ITOPT1]

You should implement TIERING. SMS first fills the first mentioned SG and only if it has not enough space, SMS will go to the second SG.

Kees.

> -----Original Message-----
> From: IBM Mainframe Discussion List [mailto:IBM-...@LISTSERV.UA.EDU] On
> Behalf Of Jesse 1 Robinson
> Sent: 22 April, 2017 2:43
> To: IBM-...@LISTSERV.UA.EDU
> Subject: SMS STORGRP question
>

********************************************************
For information, services and offers, please visit our web site: http://www.klm.com. This e-mail and any attachment may contain confidential and privileged material intended for the addressee only. If you are not the addressee, you are notified that no part of the e-mail or any attachment may be disclosed, copied or distributed, and that any other action related to this e-mail or attachment is strictly prohibited, and may be unlawful. If you have received this e-mail by error, please notify the sender immediately by return e-mail, and delete this message.

Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its employees shall not be liable for the incorrect or incomplete transmission of this e-mail or any attachments, nor responsible for any delay in receipt.
Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch Airlines) is registered in Amstelveen, The Netherlands, with registered number 33014286
********************************************************

[Cafiero, Tobias M.]

Hello,
Why not use Spill volumes. Create a STOrGRPP called SGSPILL put it under your Dump volumes enable it to spill and problem solved.


Tobias Cafiero
Data Resource Management
Core Systems Technology
Lead System Architect
DTCC  New York
Office: 212-855-1117
E-mail: tcaf...@dtcc.com
Web: www.dtcc.com <http://www.dtcc.com/

DTCC DISCLAIMER: This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error, please notify us immediately and delete the email and any attachments from your system. The recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email.

[Schroeder, Wayne]

Hey Jesse,
I have the same setup but I have my OVERFLOW volumes set as QUINEW so they are only used if the original SG can't hold all of the data. Hope this helps.

Wayne Schroeder
Mainframe Storage Administrator

T 254.399.5070
M 254.644.8534
E Wschr...@txfb-ins.com

7420 Fish Pond Rd.
Waco, TX 76710

-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-...@LISTSERV.UA.EDU] On Behalf Of Jesse 1 Robinson
Sent: Friday, April 21, 2017 7:43 PM
To: IBM-...@LISTSERV.UA.EDU
Subject: SMS STORGRP question

[http://www.txfb-ins.com/TFBICImages/email.jpg]
J.D. Power Disclaimer<https://www.txfb-ins.com/terms-conditions#disclaimer>


CONFIDENTIALITY STATEMENT: The foregoing message (including attachments) is covered by the Electronic Communication Privacy Act, 18 U.S.C. sections 2510-2521, and is CONFIDENTIAL. If you believe that it has been sent to you in error, do not read it. If you are not the intended recipient, you are hereby notified that any retention, dissemination, distribution, or copying of this communication is strictly prohibited. Please reply to the sender that you have received the message in error, then delete it. Thank you.

[Greg Shirey]

Defining a storage group as OVERFLOW provides most of that function by default. I believe the difference is that QUINEW volumes are used as a "last resort" whereas OVERFLOW volumes are used when the high threshold will be exceeded.

From "defining storage group attributes" in the Knowledge Center:

If all volumes in a non-overflow storage group are so full that the current allocation request will push them over high threshold, while volumes in the overflow storage group are not so full, then the new data set will be allocated on a volume in the overflow storage group. The assumption is that all other attributes of the non-overflow storage group and overflow storage group and the volumes in those storage groups are the same....
Volumes residing in overflow storage groups are preferred over quiesced volumes and storage groups. If you quiesce an overflow storage group or volume then the quiesced volumes are preferred over quiesced overflow volumes.


Regards,
Greg Shirey
Ben E. Keith Company

From: IBM Mainframe Discussion List [mailto:IBM-...@LISTSERV.UA.EDU] On Behalf Of Schroeder, Wayne
Sent: Tuesday, April 25, 2017 9:33 AM
To: IBM-...@LISTSERV.UA.EDU
Subject: Re: SMS STORGRP question

Hey Jesse,
I have the same setup but I have my OVERFLOW volumes set as QUINEW so they are only used if the original SG can't hold all of the data. Hope this helps.

Wayne Schroeder
Mainframe Storage Administrator

[Jesse 1 Robinson]

(Replying to a later post for update.) Many thanks to all who participated in this thread. We finally got SVCDUMPs working as we desired. As we explored various suggestions, we realized that we already had the necessary elements in place. Our one (fatal) flaw was the migration threshold for the SVCDUMP group. In an ancient attempt to maximize available space, that limit had been set to 1%. Hence the SVCDUMP group was never again selected for allocation once we added OVERFLOW. We didn't even need a low threshold in the first place because the RYO SVCDUMP management application itself issues HMIGRATE after digesting a particular dump. Solution was simply to raise the threshold to 85%. Except in cases of recurring SVC dumps or an abnormally large dump, the intended volumes will almost always have room. And in those exceptional cases, OVRFLOW is what we want.

Once again IBM-MAIN has come to the rescue.

.
.
J.O.Skip Robinson
Southern California Edison Company
Electric Dragon Team Paddler
SHARE MVS Program Co-Manager
323-715-0595 Mobile

626-543-6132 Office ⇐=== NEW
robi...@sce.com