7. Writing Field-developed Applications › 7.2 Deciding What the Application Must Do › 7.2.3 Files and Elements Needed
7.2.3 Files and Elements Needed
The nature of the data source and the structure of its
records weigh heavily in the design of CA MICS files for the
FDA and its information areas.
Remember that CA MICS products are divided into information
areas, and information areas contain files, which are groups
of related data elements. In addition, the file data can be
maintained online or offline.
A detailed file definition specifies the processes used to
construct the file. At its conclusion, you should know which
data elements in the input data records are used to build the
CA MICS file observations and what validity checks need to be
performed.
In deciding how many files to create in an information area,
consider the structure of the input data source, its
availability, and your intended use of the data.
The grouping of files and information areas is easier to
understand by example. The UNP input data source had three
record subtypes, as shown in this structure diagram:
+----------------+
| record header |
| (fixed format) |
+----------------+
| measurement | There are 3 types of measurement sections:
| section | - NCP resource measurement
| (format varies | - network component measurement
| with record | - monitor exception measurement
| type) |
+----------------+
The implementation of the UNP product in this example uses
one information area with three files. Each file corresponds
to one of the subtypes of NPA input data:
Component:----------- NPA Network Activity
Information area:- NPA Network Activity
File:---------- NCP Activity
File:---------- Network Component Activity
File:---------- NPA Monitor Exceptions
However, several alternative arrangements are possible. If
there is a thorough monitoring of all network components
through NPA and network anomalies are explained through some
manual mechanism suitable for input as an automated incident
tracking tool, this file arrangement might be more suitable:
Component:----------- NPA Network Activity
Information area:- NCP Processor Activity
File:---------- NCP Activity
Information area:- Network Incidents
File:---------- NPA Monitor Exceptions
File:---------- Operational Incidents
Information area:- NPA Network Component Activity
File:---------- Line/Link Component Activity
File:---------- PU/Cluster Activity
File:---------- LU/Terminal Activity
The processing needed to create files, once you have decided
how many files you need, is done in two stages:
o First, the content of the input data source has to be
translated into the files that are kept on the CA MICS
database.
o Second, CA MICS database files can reside in the online
database alone, or on both the online and offline
databases.
Addressing the first issue, decide if each data source record
produces an observation in your FDA's files. For example,
the UNP product has one information area and three files,
where one record subtype corresponds to a single file. Does
each input observation of the NPA data create an output
observation on the CA MICS database (output) file?
The NPA record subtypes produce data at different levels of
summarization. That is, NPA produces records that represent
the detailed activity for some particular resource over an
interval of time. NPA also produces up to four levels of
summarization for the SAME resource.
For example, NPA monitors an NCP resource every minute and
writes the following records on its SMF log:
NCP record, 1 min. of detailed activity
NCP record, 1 min. of detailed activity
NCP record, 1 min. of detailed activity
NCP record, 1 min. of detailed activity
NCP record, 4 min. of summarized activity
NCP record, 1 min. of detailed activity
NCP record, 1 min. of detailed activity
NCP record, 1 min. of detailed activity
NCP record, 1 min. of detailed activity
NCP record, 4 min. of summarized activity
NCP record, 8 min. of summarized activity
The summarized records are not needed to calculate an
accurate picture of activity measured by NPA. In this case,
the summarized input records should be dropped.
Use these steps to design file processing:
1. Define the structure of the output files, including the
information areas and files within each information area.
Assign names to each, using these guidelines:
o A three-character information area identifier must be
assigned to each information area. The identifier
must be unique among all information areas in CA MICS.
We strongly recommend that the first character be
either a U or Z because CA MICS has reserved those
letters for field-developed applications. The
information area cannot be MSI or MTI.
If your FDA has one information area, consider using
the product identifier as the information area
identifier. For example, UNPUNP would identify a
user-written application for network performance data
(UNP) that has an information area for network
performance.
o A three-character file identifier must be assigned to
each file. The identifier must be unique among all
files in CA MICS. We strongly recommend that the first
character be either a U or Z because CA MICS has
reserved those letters for field-developed
applications. File identifiers cannot match product
or information area identifiers. The file name cannot
be MSI or MTI.
2. Identify and document the input records or SAS data sets
you will use. Identify input records to be discard and
outline an algorithm for ignoring them.
3. Map input data to output file data elements by defining
which input record types apply to creating the output
file data elements.
The map you produce may yield a design document
appropriate to your site's standards. Examples of such
documents are flow charts, IPO/HIPO diagrams, and Chapin
charts.
4. Define which files will be maintained in the online and
offline databases. Consider the following in determining
each file's eligibility for archiving:
o If the information in the file describes some detailed
activity that represents resource consumption or a
potential security problem that could be attributed to
an identified user, consider maintaining audit archive
offline files.
o If the file exists in the WEEKS timespan in the online
database and the data in the file would be useful for
long term (trend) analysis, consider maintaining
weekly history offline files. The data in weekly
history archives is summarized by smaller time
intervals, so its analysis yields more detailed
results than monthly history archives.
o If the file exists in the MONTHS timespan in the
online database and the data in the file would be
useful for long term (trend) analysis, consider
maintaining monthly history archives. The data in
monthly history archives is summarized by larger time
intervals, so its analysis provides longer term
information than that provided by weekly history
archives.
5. Define data element content.
Document the data elements in your files using the format
used for the CA MICS Data Dictionary.
While you do not need to key this documentation into
machine readable form (the first pass of the MCG will
create skeleton members in the sharedprefix.MICS.INC.TEXT
library for all data elements in all files in the
component), the information you need to record includes:
o the element's identifier and descriptive name
o information about the element's content
o the data element's coding description, including how
it is accumulated, what format it takes, and what unit
of measure is used (for example, a maximum time value
whose measure is a SAS time value)
o references to related data elements, if any
o information on how the element's value is derived,
such as its input source record and field or the
calculation used to derive the value at the lowest
supported timespan
o information about the element's valid values, which
could be a specific list (such as department names) or
a list of anticipated norms (such as a percentage that
ranges from zero to one hundred)
o usage notes that describe why the element is created,
how it should be used, or how it should NOT be used
