The kept status of the variables in the BY variables list and CLASS variables list must be Yes.

The BY variables list applies to the detail level of the table. The purpose of the BY variables list is to sort the observations in the detail level to match the sort order of the observations incoming during the processing step and to detect observations that have duplicate values in the BY variables.

Under normal circumstances, you do not need to modify the BY variables list, but if you need to modify the list you can. For example, if you add a variable in an exit, you may (or may not) want to add that variable to the BY variables list.

The variables on the list must have a Kept status of Yes. DATETIME must be on the BY variables list.

CLASS variables lists, displayed in the bottom of the Edit Table window, are used to group data so that the same values of all CLASS variables are together for the reduction step. The lists also assure that data are in the proper sort order for reporting on the reduction levels. By default, the CLASS variable lists contain the same variables in the same order as the BY variables list. The CLASS variables list for a reduction level can be different from the BY variables list and can be different from all other CLASS variables lists, but it must contain the DATETIME variable.

If you want character string metrics like MACHINE and JOB to be carried into reduction levels for reporting, add them to the CLASS variables lists immediately to the left of the DATETIME variable. (This presumes that you changed the Kept status of the string variable to Yes earlier. However even if their Kept status is Yes, string variables that are not on the CLASS variables list are dropped from the non-detail levels because there are no statistics for string variables.)

Within your table(s) the metrics that are generally most useful for performance analysis are the ones whose default values for the Kept status are Yes. These are metrics that you logged in the first section of this document.

Note: If you decide on a Kept status of Yes, you can decide later to change it to No, in which case the values are not processed into the detail level from that time forward. Similarly, if you decide on a Kept status of No, you can decide later to change it to Yes, in which case values are processed into the detail level from that time forward.

1. Check the Age Limit at detail level.

   By default, IT Service Vision keeps ten days of data at the detail level, but the age limit in your tables may be different. If you want your reports on detail level to be able to cover a different number of days (for example, 14 days), overwrite the current value with the new value (in this case, 14).

   Note: If you do not want to generate reports on detail-level data in this table but you do want to generate reports on other levels, you can set the value to 0.

   Note: The process step deletes existing data in the detail level that are beyond the age limit for the detail level, but the process step keeps incoming data (and adds it to existing data in the detail level) regardless of the dates in the incoming data. When the age limit at detail level is 0, the process step behaves just as it always does: it deletes existing detail level data whose age is greater than the age limit (thus, in this case, it deletes all of the existing detail level data), and it keeps the incoming data in the detail level (thus, in this case, what were the incoming data are now all the existing data).

   The reduce step ages out data in non-detail levels that are beyond the age limits for those levels and uses the existing data in detail level to update the non-detail levels. If and only if the age limit at detail level is 0, the reduce step also deletes the existing data (which, if age limit is 0, are the data that were incoming data to the process step) in the detail level.

   If the age limit is 0, the existing data in detail level would be cleared anyway (at the time of the next processing step) because the data by now are existing data and over the age limit for detail level. The purpose of this exception is to remove the existing data in detail level many hours sooner. This is quite useful when there is a tremendous volume of detail-level data and the data can be 'thrown away' after the day, week, month, and/or year levels have been updated. Performing this frees extra disk space between production jobs when the data will not be used again.

   There is one caution: if you have a failure (for instance, a power outage) during the reduce step and any age limits at detail level are zero and any age limits at non-detail levels are non-zero, make sure that you re-submit the reduce step before you go on; otherwise, the next day's production job will remove the detail data before the data have an opportunity to be summarized in the non-detail levels.

2. Check the Age Limits at reduction levels.

   By default, the PDB keeps reduction-level data as follows

   Day	45	days
   Week	15	weeks
   Month	18	months
   Year	5	years

   but the age limits in your tables may be different.

   If you want your reports on these levels to be able to cover a different number of days, weeks, months, or years, or if you want to keep fewer data in order to save disk space and shorten processing time, overwrite the current value with a new value.