IBM Mainframe Forum

Hi,

At our site the DFHSM PDA datasets keep getting swapped and archived to tape every 7 minutes(mostly), which I think is not good considering that the backup and swap may not be good at such short span of time, could cause contention.

Now I have been reading Implementation and customization guide but not able to find out how to calculate the appropriate size of PDA X and Y.

The present size of X and Y are 1661 cylinders.

Needed help on how to calculate an appropriate size and how many hours should be a good enough time to swap. On others sysplex systems it happens once in a day.

My first response would be to ask why you've got active PDA data sets, anyway? PDA data sets record trace data to help debug HSM problems and there's probably not a whole lot of reason to routinely use the PDA data sets -- unless you routinely have HSM troubles that require a trace.

Second, IBM's Technote at http://www-01.ibm.com/support/docview.wss?uid=isg3T1012687 recommends sizing them to hold one to three hours of data before the swap. If you're getting 7 minutes, you need to make them 9 to 26 times as large as they currently are. And since they need to be on the same volume, that may limit how big you can make them even using a 3390 mod 54.

A definition from the manual:
Problem determination aid log data sets
PDA log data sets provide you with trace information about DFSMShsm processing.

The DFHSM task that does the most processing will generate the most trace data. This DFHSM performs backup activity. Also we are doing round the clock recycles of magstar tapes. The trace entries are not problems

The trace entries are not problems

contradicts your earlier statement

the DFHSM PDA datasets keep getting swapped and archived to tape every 7 minutes(mostly), which I think is not good considering that the backup and swap may not be good at such short span of time, could cause contention.

So which is it -- are the swaps every 7 minutes an issue or not? You're getting swaps every 7 minutes BECAUSE of the count of trace entries -- so if the swaps every 7 minutes are a problem, then yes the trace entries are a problem; if the trace entries are not a problem, then you'll need to live with the swaps every 7 minutes (unless you increase the size of the data sets as stated earlier).

ok Makes sense, we have decided to hold on until the recycle of tapes get over. THANKS

We have decided to increase the size of PDAX's and Y's to 32760 cylinders each, I am not seeing anything in the manual about size limitation of PDA datasets, DO I need to create it with DSNTYPE=LARGE dataclass. I think so.

From the DFSMS Using Data Sets manual:

Allocating a Large Format Data Set. Large format data sets are sequential data sets that can grow beyond 65 535 tracks (4369 cylinders) up to 16,777,215 tracks per volume. Large format data sets can be system-managed or not. You can allocate a large format data set using the DSNTYPE=LARGE parameter on the DD statement, dynamic allocation (SVC 99), TSO/E ALLOCATE, or the access method services ALLOCATE command. The SMS data class can also provide the DSNTYPE value of LARGE, if the data set does not have another DSNTYPE specified or a DSORG value other than PS or PSU.

So if you want to allocate a data set with more than 4369 cylinders on a volume, you have no choice but to use DSNTYPE=LARGE. This is an operating system requirement, not an HSM restriction.

Agreed, Let me rephrase is there any other limitation when I am making my PDA to 32760 cylinders, I mean from HSM persepective.

I have created PDO datasets with DSNTYPE=LARGE as a rehearsal at my org and will be renaming it to present name this weekend.

There is no indication of any upper limit in the DFSMShsm Implementation and Customization manual for the PDA log data set size.

However, I still see no reason for your site to be capturing and keeping so much trace information. How many times in the last month / quarter / year has your site used the PDA traces to analyze an HSM problem? How often is your site having HSM issues that require trace analysis? Most sites I'm aware of, quite frankly, don't have that many HSM issues that require trace analysis.

We hardly use it, probably used it once in last 1 year if I recall, You are right, my main concern has been to make the swap less frequent than concentrate on what is it capturing, Let me start to look at what is it actually capturing and is it needed,