SMS/HSM QUESTION

Discussion:

SMS/HSM QUESTION

(too old to reply)

willie bunter

2018-02-27 14:54:26 UTC

Good Day To All,

I am trouble shooting a problem caused by space abends. I looked at all of the 54 SMS managed volumes

(via ISPF 3.4) and I found 2,930 dsns which are allocated on this specific Storage Group which were created in Dec.2017 and have not been referenced since their creation.
According to the Management class, the dsns are to be deleted after 2 days of non reference. Primary and Secondary Space management are run daily on this Storage Group. Since the threshold requirements are being met, SMS does not process some of these volumes. I was thinking of lowering the threshold in order to get SMS to select most of the volumes when Space management is run.

My question is do I modify the Allocation/migration Threshold or the Alloc/Migr Threshold Track-Managed.

Below is threshold settings:
Allocation/migration Threshold : High 85 (1-100) Low . . 1 (0-99)
Alloc/Migr Threshold Track-Managed: High 85 (1-100) Low . . 1 (0-99)

Thanks in advance for your suggestions.

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

Mike Schwab

2018-02-27 17:28:43 UTC

Permalink

The Track-managed deals with the first 64K cylinders. The other one
deals with the EAV 21 Cylinder managed portion past the first 64K
cylinders.

On Tue, Feb 27, 2018 at 8:55 AM, willie bunter

Post by willie bunter
Good Day To All,
I am trouble shooting a problem caused by space abends. I looked at all of the 54 SMS managed volumes
(via ISPF 3.4) and I found 2,930 dsns which are allocated on this specific Storage Group which were created in Dec.2017 and have not been referenced since their creation.
According to the Management class, the dsns are to be deleted after 2 days of non reference. Primary and Secondary Space management are run daily on this Storage Group. Since the threshold requirements are being met, SMS does not process some of these volumes. I was thinking of lowering the threshold in order to get SMS to select most of the volumes when Space management is run.
My question is do I modify the Allocation/migration Threshold or the Alloc/Migr Threshold Track-Managed.
Allocation/migration Threshold : High 85 (1-100) Low . . 1 (0-99)
Alloc/Migr Threshold Track-Managed: High 85 (1-100) Low . . 1 (0-99)
Thanks in advance for your suggestions.
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,

--
Mike A Schwab, Springfield IL USA
Where do Forest Rangers go to get away from it all?

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

Willie Bunter

2018-03-01 16:17:15 UTC

Permalink

Thanks for the info., however it doesn't answer my question as to which threshold I should modify.

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

Graham Harris

2018-03-02 23:04:04 UTC

Permalink

Primary space management should normally process all volumes in a storage
group. And PSM should normally look to reduce utilisation of a volume down
to the low threshold (caveat - various PATCHes can alter DFHSM standard
behaviour).
Have you checked the messages for space management actions for these
datasets?
It could be that they need to be backed-up before being expired, and
auto-backup may not be running against that SG (as an example of a
condition that could potentially give rise to what you are seeing).
Or another possibility is that they cant be backed up, because, for
example, they may have a null DSORG. If they cant be backed-up, and the
management class says they must be backed up, then DFHSM will not expire
them until they are backed up.

The above may not precisely match what you are experiencing, but it may
perhaps point you in a better direction.

On 1 March 2018 at 16:18, Willie Bunter <

Post by Willie Bunter
Thanks for the info., however it doesn't answer my question as to which
threshold I should modify.
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,

willie bunter

2018-03-05 16:36:36 UTC

Permalink

I verified the MC and DSORGs. No problem found. No patches either which would impede the PSM. I remember reading or being told that once the SM conditions had been met, HSM stops looking at the volume(s).

From: Graham Harris <***@GMAIL.COM>
To: IBM-***@LISTSERV.UA.EDU
Sent: Friday, March 2, 2018 6:05 PM
Subject: Re: SMS/HSM QUESTION

Primary space management should normally process all volumes in a storage
group. And PSM should normally look to reduce utilisation of a volume down
to the low threshold (caveat - various PATCHes can alter DFHSM standard
behaviour).
Have you checked the messages for space management actions for these
datasets?
It could be that they need to be backed-up before being expired, and
auto-backup may not be running against that SG (as an example of a
condition that could potentially give rise to what you are seeing).
Or another possibility is that they cant be backed up, because, for
example, they may have a null DSORG. If they cant be backed-up, and the
management class says they must be backed up, then DFHSM will not expire
them until they are backed up.

The above may not precisely match what you are experiencing, but it may
perhaps point you in a better direction.

On 1 March 2018 at 16:18, Willie Bunter <

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

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

Mike Schwab

2018-03-05 18:24:48 UTC

Permalink

Set one volume to Quiesce,New and migrate the volume. Whatever is
left try to manually migrate and note error. Return to spare if you
don't need the space, or Enable to return to active use. Proceed with
next volume. Or just reduce high threshold so it will process all
volumes, return after cleanup.

On Mon, Mar 5, 2018 at 10:37 AM, willie bunter

I verified the MC and DSORGs. No problem found. No patches either which would impede the PSM. I remember reading or being told that once the SM conditions had been met, HSM stops looking at the volume(s).
Sent: Friday, March 2, 2018 6:05 PM
Subject: Re: SMS/HSM QUESTION
Primary space management should normally process all volumes in a storage
group. And PSM should normally look to reduce utilisation of a volume down
to the low threshold (caveat - various PATCHes can alter DFHSM standard
behaviour).
Have you checked the messages for space management actions for these
datasets?
It could be that they need to be backed-up before being expired, and
auto-backup may not be running against that SG (as an example of a
condition that could potentially give rise to what you are seeing).
Or another possibility is that they cant be backed up, because, for
example, they may have a null DSORG. If they cant be backed-up, and the
management class says they must be backed up, then DFHSM will not expire
them until they are backed up.
The above may not precisely match what you are experiencing, but it may
perhaps point you in a better direction.
On 1 March 2018 at 16:18, Willie Bunter <

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,

Graham Harris

2018-03-05 20:49:58 UTC

Permalink

PSM should expire eligible datasets, regardless of volume residency levels.

Have a look at the bottom few paragraphs here, specifically:

"Pass 1 of automatic primary space management
<https://www.ibm.com/support/knowledgecenter/SSLTBW_2.2.0/com.ibm.zos.v2r2.arcf000/pass1a.htm?view=kc#pass1a>
(non-data-movement function in primary space management) and extent
reduction are performed for all volumes in storage groups defined with AM=Y
and AM=I (SG1, SG2, and SG3). Pass 2 of automatic primary space management
<https://www.ibm.com/support/knowledgecenter/SSLTBW_2.2.0/com.ibm.zos.v2r2.arcf000/pass2a.htm?view=kc#pass2a>
(migration) is performed only for those volumes that are above the low
threshold after pass 1 and extent reduction have completed."

https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.2.0/com.ibm.zos.v2r2.arcf000/stgbmgd.htm

Have a look at the HSM log messages being produced for the datasets which
you expect to be expired. They should indicate why they are not being
expired.

Post by Mike Schwab
Set one volume to Quiesce,New and migrate the volume. Whatever is
left try to manually migrate and note error. Return to spare if you
don't need the space, or Enable to return to active use. Proceed with
next volume. Or just reduce high threshold so it will process all
volumes, return after cleanup.
On Mon, Mar 5, 2018 at 10:37 AM, willie bunter

I verified the MC and DSORGs. No problem found. No patches either

which would impede the PSM. I remember reading or being told that once the
SM conditions had been met, HSM stops looking at the volume(s).

Sent: Friday, March 2, 2018 6:05 PM
Subject: Re: SMS/HSM QUESTION
Primary space management should normally process all volumes in a storage
group. And PSM should normally look to reduce utilisation of a volume

down

to the low threshold (caveat - various PATCHes can alter DFHSM standard
behaviour).
Have you checked the messages for space management actions for these
datasets?
It could be that they need to be backed-up before being expired, and
auto-backup may not be running against that SG (as an example of a
condition that could potentially give rise to what you are seeing).
Or another possibility is that they cant be backed up, because, for
example, they may have a null DSORG. If they cant be backed-up, and the
management class says they must be backed up, then DFHSM will not expire
them until they are backed up.
The above may not precisely match what you are experiencing, but it may
perhaps point you in a better direction.
On 1 March 2018 at 16:18, Willie Bunter <

--
Mike A Schwab, Springfield IL USA
Where do Forest Rangers go to get away from it all?
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,

Max Smith

2018-03-06 15:46:45 UTC

Permalink

You might also review this Technote that explains various reasons and things to look at to see what might be going on.

http://www-01.ibm.com/support/docview.wss?uid=isg3T1023379

Max Smith
IBM DFSMS HSM Development

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