6. Database Tailoring and Retrofitting Techniques › 6.3 Retrofitting Guidelines › 6.3.3 Retrofitting Archive Files › 6.3.3.1 Data Element Changes › 6.3.3.1.3 Value Change With Order and Granularity Changes
6.3.3.1.3 Value Change With Order and Granularity Changes
If there is not a one-to-one mapping of the old key data
element value to the new value, the data values must be
corrected, and the file must be re-sorted AND resummarized.
This was shown in the previous section. The template for
such a generalized recovery job becomes:
%MACRO RETFIT(DDI,DDO,III,FFF,TSPAN);
%LOCAL FILEID R_BY R_BREAK ;
%LET FILEID = &III&FFF;
%LET R_BY = %&FFF.SEQ(TS=&TSPAN) ;
%LET R_BREAK= %&FFF.SEQ(TS=&TSPAN,OP=BREAK);
DATA TEMP;
SET &DDI..&FILEID;
(correction logic)
RUN;
PROC SORT DATA=TEMP;
BY &R_BY;
RUN;
DATA &DDO..&FILEID (KEEP=
%&FFF.KEEP(TS=&TSPAN)
);;;;
SET TEMP;
%&FFF.SUM(SUMBY=&R_BY, SUMBREAK=&R_BREAK);
RUN;
%MEND RETFIT;
where parameters are as noted in previous illustrations.
Again, this database retrofit can be done as soon as
permanent corrections to CA MICS logic or user exit code are
done. This ensures that a single form of the key element
value exists at a given time.
Also, it is necessary to treat the history files fully. All
history files that have granularity changes MUST be sorted
(sorting is required) as a prerequisite to resummarization.
The problem with increasing granularity, noted in the
previous section, exists for treating archives. The
retrofitting of key data element values at the DETAIL
timespan for audit archives can be done easily, because no
summarization needs to be done. However, higher levels of
summarization have already taken place. Audit archive data
in DAYS granularity, and WEEKS and MONTHS history archives,
has been summarized to a higher level of granularity than is
desired, and splitting the data back into its component parts
can be difficult.
Contact the CA MICS Product Support Group for more
information on performing this difficult retrofit process.