DFHSM BCDS is going larger
af dc
I've DFHSMS V1.8 and our BCDS has:
ALLOCATION
SPACE-TYPE------CYLINDER HI-A-RBA------3207168000
SPACE-PRI-----------4350 HI-U-RBA------1673625600
SPACE-SEC--------------0
so it's reaching the max extents per volume.
In a near, very near future, I'll have to allocate a larger BCDS, can you
pls give me an help, from your experience, what is the "best way to grow"??
alocate a new one with EA ??
Many thx, Antonio Cecilio.
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to list...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
O'Brien, David W. [C] , NIH/CIT
1. How often do you re-org the BCDS?
2. What are your freespace parameters for the BCDS?
Thank You,
Dave O'Brien
NIH Contractor
________________________________________
From: af dc [acb...@GMAIL.COM]
Sent: Friday, December 18, 2009 11:28 AM
To: IBM-...@bama.ua.edu
Subject: DFHSM BCDS is going larger
af dc
here are the answers:
1. I did a reog on it last sunday, 13th Dec, it becames with 52%, today it
has:
ARC0148I BCDS TOTAL SPACE=3132000 K-BYTES, CURRENTLY 868
ARC0148I (CONT.) ABOUT 68% FULL, WARNING THRESHOLD=80%, TOTAL
ARC0148I (CONT.) FREESPACE=52%, EA=NO, CANDIDATE VOLUMES=0
2. about freespace:
STATISTICS
REC-TOTAL--------4498462 SPLITS-CI------------239
REC-DELETED---------8225 SPLITS-CA--------------0
REC-INSERTED--------9009 FREESPACE-%CI---------10
REC-UPDATED--------12843 FREESPACE-%CA---------10
REC-RETRIEVED---61529041 FREESPC-------1698484224
Many thx, A.Cecilio
O'Brien, David W. [C] , NIH/CIT
From your past experience, how soon will you hit the warning threshold of 80%?
My experience tells me that your rate of increase will slow as VSAM allocates space where it is needed through CI and CA splits. You'll find the insert pattern is not uniform.
I run with freespace(0,0) and although I may notice rapid growth in the week or so after the reorg, the rate slows dramatically after that. See how long it takes to reach 80% and if the rate of increase has slowed enough bump the warning threshold to 90%. Of course your situation may require a larger CDS using EA.
Check the Implementation and Customization manual for the following section:
Using VSAM Extended Addressability Capabilities
Thank You,
Dave O'Brien
NIH Contractor
________________________________________
From: af dc [acb...@GMAIL.COM]
Sent: Friday, December 18, 2009 11:48 AM
To: IBM-...@bama.ua.edu
Subject: Re: DFHSM BCDS is going larger
Lizette Koehler
From the DFSMS Introduction Manual SC26-7397-02
Using DFSMShsm Control Data Sets DFSMShsm control data sets (CDS) are system-type data sets that DFSMShsm uses to keep track of all DFSMShsm-owned data. They consist of migration, backup, and offline control data sets. The control data sets are an inventory of low activity and inactive data that was stored by DFSMShsm and used to manage its environment.
DFSMShsm logs its transactions and maintains multiple backup versions of its CDSs for recovery purposes as specified by the user.
DFSMShsm can use VSAM KSDS extended addressability (EA) capabilities that use any of the following serialization techniques for accessing its CDSs:
v Record-level sharing (RLS) access mode
v CDSQ serialization
v CDSR serialization
VSAM EA capabilities allow each migration control data set (MCDS), backup control data set (BCDS), and offline control data set (OCDS) cluster to exceed the 4 GB size. The MCDS and BCDS can span up to four unique KSDS clusters. The OCDS is limited to a single cluster. The same serialization technique must be used to access all CDSs
af dc
so, I can create a new BCDS with EA giving more space in the allocation
right ??
Can I have MCDS and OCDS without beeing EA ? There's no obligation of all
cdss being EA ??
Many thx once more, A.Cecilio
O'Brien, David W. [C] , NIH/CIT
Thank You,
Dave O'Brien
NIH Contractor
________________________________________
From: af dc [acb...@GMAIL.COM]
Sent: Sunday, December 20, 2009 1:50 PM
Lizette Koehler
Try and determine how fast you are growing. In my shop, I have a single NON EA MCDS/BCDS/OCDS which lasts almost 18 months before a reorg. We set our warning at 97% because we know that it will take a couple of weeks even at that level to become full. So we have time to schedule a reorg.
If you are really hurting on size, I would go with the multiple xCDS data sets first (not the OCDS).
It will provide the relief you need. Then, if you have a test DFHSM environment, I would practise the use of the EA.
Lizette
>
>As I read the manual that is correct, however I have no personal experience with HSM CDSs using EA.
>
>Thank You,
>Dave O'Brien
>NIH Contractor
>
>
af dc
thx once more for your sugestions, here is a not so good upd:
- My bcds today:
ARC0148I BCDS TOTAL SPACE=3132000 K-BYTES, CURRENTLY 188
ARC0148I (CONT.) ABOUT 87% FULL, WARNING THRESHOLD=80%, TOTAL
ARC0148I (CONT.) FREESPACE=44%, EA=NO, CANDIDATE VOLUMES=0
STATISTICS
REC-TOTAL--------4611413 SPLITS-CI----------20950
REC-DELETED-------232332 SPLITS-CA-----------1512
REC-INSERTED------346063 FREESPACE-%CI---------10
REC-UPDATED-------613409 FREESPACE-%CA---------10
REC-RETRIEVED--273730657 FREESPC-------1439428608
ALLOCATION
SPACE-TYPE------CYLINDER HI-A-RBA------3207168000
SPACE-PRI-----------4350 HI-U-RBA------2788392960
SPACE-SEC--------------0
VOLUME
VOLSER------------CPS096 PHYREC-SIZE--------12288
DEVTYPE------X'3010200F' PHYRECS/TRK------------4
VOLFLAG------------PRIME TRACKS/CA-------------15
EXTENTS:
LOW-CCHH-----X'002E0000' LOW-RBA----------------0
HIGH-CCHH----X'0270000E' HIGH-RBA-------426885119
LOW-CCHH-----X'18660000' LOW-RBA--------426885120
HIGH-CCHH----X'2720000E' HIGH-RBA------3207167999
So, I must schedule an DFHSM intervention soon, and decide if I'll alocate
bcds with EA or use multicluster cds (I have Z/OS V1.8 and I don't know how
to implement these func. I must read the manuals).
Remember that I did the BCDS reorg on December 13th, and it becomes with 52%
of free space. So after 15 days it grew 35%. I'ts very strange, we never had
to reorg or augment the cds so often,
So, any hints are welcome.
Many thx once more, A.Cecilio.
On Mon, Dec 21, 2009 at 12:15 AM, Lizette Koehler
<star...@mindspring.com>wrote:
Lizette Koehler
At this point, you may wish to open an ETR to IBM to identify why your files
are growing so quickly. I would not think it should grow that fast unless
there is a lot of backup functions running.
How many volumes/datasets do you do HSM backup for? It maybe that 4320
Cylinders is insufficient for your DFHSM Backups.
We do not do many. We have daily full volume dumps for our critical
system/application files. We typically use DFHSM backups for TSO and Roscoe
pools. Not much else.
I am not sure if there is a rule of thumb as to what makes good candidate
volumes for backup. Maybe others might have a suggestion.
Lizette
----------------------------------------------------------------------
O'Brien, David W. [C] , NIH/CIT
Next step, run HSM.SAMPLE.TOOL(SPLITCDS) which will enable you to analyze the proper split point for your BCDS.
Then read Multicluster Control Data Set Conversion in the DFSMShsm Implementation and Customization Guide. Instructions seem pretty clear.
Thank You,
Dave O'Brien
NIH Contractor
________________________________________
From: af dc [acb...@GMAIL.COM]
O'Brien, David W. [C] , NIH/CIT
One other question - When was the last time you ran Expirebv? I'm just wondering if you have extraneous rescords in your BCDS.
Thank You,
Dave O'Brien
NIH Contractor
________________________________________
From: Lizette Koehler [star...@MINDSPRING.COM]
Sent: Monday, December 28, 2009 7:16 AM
To: IBM-...@bama.ua.edu
Subject: Re: DFHSM BCDS is going larger
Antonio,
Brian Fraser
If thats not the problem, then I'd also be looking at the management classes
of your SMS datasets being backed up to ensure that you are not keeping too
many backup versions and/or keeping them too long.
Also worth looking at is how many old backups of non-sms datasets are being
kept. HSM has no way of knowing how long to keep these old backups.(probably
not a cause of sudden growth, but could be a contributing factor to overall
size)
af dc
I did another BCDS cds reorg last sunday, now it has:
STATISTICS
REC-TOTAL--------4650469 SPLITS-CI--------------0
REC-DELETED------------0 SPLITS-CA--------------0
REC-INSERTED-----------0 FREESPACE-%CI----------0
REC-UPDATED------------0 FREESPACE-%CA----------0
REC-RETRIEVED---16310129 FREESPC-------2024644608
ALLOCATION
SPACE-TYPE------CYLINDER HI-A-RBA------3428352000
SPACE-PRI-----------4650 HI-U-RBA------1403781120
SPACE-SEC--------------0
ARC0148I BCDS TOTAL SPACE=3348000 K-BYTES, CURRENTLY 422
ARC0148I (CONT.) ABOUT 67% FULL, WARNING THRESHOLD=80%, TOTAL
ARC0148I (CONT.) FREESPACE=59%, EA=NO, CANDIDATE VOLUMES=0
Besides of runing every day, EXPIREBV job:
HSEND WAIT EXPIREBV EXECUTE SYSOUT(J)
I checked backup log and saw this:
DFSMSHSM BACKUP LOG, TIME 19:03:20, DATE 10/01/03
ARC0680I EXPIRE BACKUP VERSIONS STARTING AT 19:03:21 ON 2010/01/03, SYSTEM
SYB1
ARC0184I ERROR WHEN READING THE DFSMSHSM CONTROL DATA SET C RECORD FOR
PDFHSM.BACK.T392220.SYS3.DV.J1295, RC=0004
ARC0734I ACTION=EXBACKV FRVOL=****** TOVOL=****** TRACKS= *** RC=
4, REASON= 0, AGE=2993,
DSN=PDFHSM.BACK.T392220.SYS3.DV.J1295
ARC0184I ERROR WHEN READING THE DFSMSHSM CONTROL DATA SET C RECORD FOR
PDFHSM.BACK.U122420.SYS3.DV.J1295, RC=0004
ARC0734I ACTION=EXBACKV FRVOL=****** TOVOL=****** TRACKS= *** RC=
4, REASON= 0, AGE=2993,
DSN=PDFHSM.BACK.U122420.SYS3.DV.J1295
ARC0734I ACTION=EXBACKV FRVOL=****** TOVOL=****** TRACKS= *** RC=
28, REASON= 0, AGE=2509,
DSN=SYS3.DV.PROJCL.BACKUP.DBRM
ARC0734I ACTION=EXBACKV FRVOL=****** TOVOL=****** TRACKS= *** RC=
28, REASON= 0, AGE= 0,
DSN=SYS3.DV.PROJCL.BACKUP.DBRM
however, I now did a HSEND WAIT EXPIREBV DISPLAY SYSOUT(J) and it's
generating a lot of records. At this time, job is still running and the
backup log has 28.761 lines.
Is it possible that the EXPIREBV EXECUTE is not working at all after giving
above errors ??
Any h'int is welcome
Many thx once more, A.Cecilio.
O'Brien, David W. [C] , NIH/CIT
B.Isyour log set up to issue all msgs. or only error msgs.? see HSM.Parmlib ARCCMDxx
SETSYS-
ACTLOGTYPE(DASD) -
ACTLOGMSG(FULL)
I hold issue a Hold Expirebv immediately
Re-run Listcat for BCDS to see if any records have been deleted.
Check ACTLOGMSG value.
Release Expirebv and run Expirebv display to see what remains to be deleted and whether those backups ought to be deleted.
Lizette, Your thoughts?
Thank You,
Dave O'Brien
NIH Contractor
________________________________________
From: af dc [acb...@GMAIL.COM]
Sent: Monday, January 04, 2010 12:20 PM
Lizette Koehler
deleted in over 3 years. Which probably explains the size of the BCDS
dataset. I think the AGE=2993 may be the point when EXPIREBV may have had
problems.
When I had a similar issue, I got very conservative and worked with IBM to
resolve these issues so I would not break the BCDS. But when I did get a
good listing, the EXPIREBV ran for many hours. But it eventually cleaned up
the mess.
I would recommend he contact IBM and open an ETR to get assistance with
correcting the BCDS, as it may have "broken" records.
Then I would suggest that a review of the SMS classes to ensure that
EXPIREBV gets rid of the correct backups.
I agree that this looks like a task is needed to do this cleanup. And
involving IBM to correct the BCDS a valid direction to take.
Lizette
>>> David O'Brien Wrote
A. Expirebv has two modes: Display and Execute. If this is the first time
you've run the command, I would strongly urge you to run Display first and
make sure that the backups being deleted are the ones you want deleted in
accordance with your SMS Management class policies.
B.Isyour log set up to issue all msgs. or only error msgs.? see HSM.Parmlib
ARCCMDxx
SETSYS-
ACTLOGTYPE(DASD) -
ACTLOGMSG(FULL)
I hold issue a Hold Expirebv immediately
Re-run Listcat for BCDS to see if any records have been deleted.
Check ACTLOGMSG value.
Release Expirebv and run Expirebv display to see what remains to be deleted
and whether those backups ought to be deleted.
>>> A.Cecilio wrote:
----------------------------------------------------------------------
Walter Marguccio
> Subject: Re: DFHSM BCDS is going larger
> however, I now did a HSEND WAIT EXPIREBV DISPLAY SYSOUT(J) and it's
> generating a lot of records. At this time, job is still running and the
> backup log has 28.761 lines.
you could selectively expire your backup versions adding STARTKEY and ENDKEY to
the EXPIREBV command:
EXPIREBV DISPLAY|EXECUTE STARTKEY(ABC) ENDKEY(DEF) SYSOUT(H)
Expiring a smaller number of datasets would reduce dramatically the elapsed time
of EXPIREBV.
> Is it possible that the EXPIREBV EXECUTE is not working at all after giving
> above errors ??
I don't think so, but I would ask IBM.
Walter Marguccio
z/OS Systems Programmer
BELENUS LOB Informatic GmbH
Munich - Germany