7. Writing Field-developed Applications › 7.3 Writing the Code › 7.3.3 Define Reports (DYfdaEXC, fdaEVA, and DYfdaMBO) › 7.3.3.1 Define Exception Reporting

7.3.3.1 Define Exception Reporting

Exception processing is handled using the following members:

  o sharedprefix.MICS.SOURCE(fdaEVA) is the exception value
    analysis routine, which helps you choose values to code
    in the exception test routine

  o prefix.MICS.CNTL(fdaEVA) is the JCL to execute the
    exception value analysis routine

  o sharedprefix.MICS.SOURCE(DYfdaEXC) is the exception test
    routine

If you plan to use CA MICS exception processing, you must
define the shells for the exceptions in the DYfdaEXC members
in sharedprefix.MICS.SOURCE and
sharedprefix.MICS.HOLD.USER.SOURCE.

The HOLD.USER.SOURCE version of DYfdaEXC should contain:

  /* COMPONENT: fda                            */
  /* EXCEPTION PROCESSOR MODULE                */
  /* GENERATED: mm/dd/yy BY userid             */
  %INCLUDE SOURCE(DYfdaEXC);

where you fill in your FDA's ID, the date, and your user
identification.

The CA MICS.SOURCE version of DYfdaEXC should contain:

  /* COMPONENT: fda                            */
  /* EXCEPTION PROCESSOR MODULE                */
  /* GENERATED: mm/dd/yy BY userid             */

where you fill in your FDA's ID, the date and your user
identification.

There are two styles of exception processor used in CA MICS:

  o the normal processor, like that used by the CA MICS
    Analyzer for TSO (DYTSOEXC), scans newly created file
    cycles looking for thresholds that have been exceeded.

  o an alternative processor, like that used by the CICS
    Analyzer (DYCICEXC), is useful if your FDA does not
    create DETAIL timespan files.  The DYCICEXC module
    illustrates a technique that examines the values of key
    indicators as the detailed data is read.  If the DYCICFMT
    routine notes an exception condition, it writes a record
    to the CICS Incident File (CICCIN).  The CICCIN file is
    read by the DYCICEXC routine to report exceptions.

Code the exception processor logic in
sharedprefix.MICS.SOURCE(DYfdaEXC) so that the same version
of the exception processor code can be used by all database
units in which the FDA is installed.  (You can tailor
exception processors for individual database units later.)

The general form of an exception processor is:

  o One SAS DATA step per file examined in the process.  We
    call this data step an analysis DATA step for ease of
    discussion.

  o One final DATA step to merge exceptions found for this
    FDA with exceptions found in previous processors.

Each analysis DATA step examines observations from one of the
FDA's CA MICS database files or one other source of
exception possibilities.  Each analysis DATA step contains an
intermediate file in the DATA statement, the SET statement
(or INFILE statement with input code), observation selection
logic (if needed), followed by a HIT routine, followed by a
TESTS section.

The HIT routine is the single place where observations are
written to the working exception file, and is linked to by
specific test routines.

The TESTS section contains one or more exception tests.  Each
exception test is in SAS DO group form:  if the exception
condition is present, the exception data elements are set and
the HIT routine is linked.  Code your exception tests in the
format outlined below.

The fdaEVA routine in sharedprefix.MICS.SOURCE helps you
choose values to code in the TESTS section.  The fdaEVA
routine produces a report that shows statistical measures for
the data elements used in DYfdaEXC.  To produce the report,
submit the job in prefix.MICS.CNTL(fdaEVA).

The sharedprefix.MICS.SOURCE(DYfdaEXC) code follows this
format:

/* ********************************************* */
/* EXCEPTION ANALYSIS OF THE CURRENT DATA        */
/* (product and file IDs here)                   */
/* ********************************************* */

DATA ADMfffDT (KEEP=%EXCKEEP(TS=DAYS));
/* ********************************************* */
/* if the timespan of analyzed data had been     */
/* DAYS instead of DETAIL, the intermediate file */
/* name above would be of the form ADMfffDY.     */
/* ********************************************* */

%EXCLEN(TS=DAYS);
%EXCFMT(TS=DAYS);
SET &iiit..iiifff01 END=EOFSW;
     /* iii=info. area, t=X for DETAIL, D for DAYS */
RETAIN MICSVER  '60'
       INFOAREA 'iii'
       TIMESPAN 'DETAIL'     /* or DAYS */
       DBFILE   'iiifff01'
      EXCCOUNT 1;
   IF _N_ = 1  THEN PUT INFOAREA= TIMESPAN= DBFILE= ;
   OBSERVNO = _N_;
   GOTO TESTS;
HIT:
   OUTPUT;
   EXCCODE  = '00000';
   SEVERITY = ' ';
   MGMTAREA = ' ';
   EXCDESC1 = ' ';
   EXCDESC2 = ' ';
   RETURN;
TESTS:

 /* ****************************************************** */
 /* EX NR: 9nnnn                                           */
 /* TITLE: exception condition identification text         */
 /* FILE:  timespan.iiifff01                               */
 /* ****************************************************** */
IF (exception condition)
 THEN DO;
  EXCCODE='9nnnn';
  SEVERITY='C';
  MGMTAREA='PERFORMANCE';
  EXCDESC1='exception condition identification text';
  EXCDESC2='additional condition text, or blank';
  LINK HIT;
END;
 /* ****************************************************** */
 /* EX NR: 9nnnn                                           */
 /* TITLE: exception condition identification text         */
 /* FILE:  timespan.iiifff01                               */
 /* ****************************************************** */
IF (exception condition)
  ...
END;
RUN;

************************************************************;
DATA &ADMD..ADMEXC00 (KEEP=%EXCKEEP(TS=DAYS));
%EXCLEN(TS=DAYS);
%EXCFMT(TS=DAYS);
%EXCLBL;
SET  &ADMD..ADMEXC00 WORK.ADMfffDT ;

* BYPASS ADMEXC OUTPUT IF FILE DEFINITION IS NOT ACTIVE ;
IF &EXCSFD THEN OUTPUT;
RUN;

PROC DATASETS NOLIST NOWARN DDNAME=WORK;
DELETE  ADMfffDT ;
RUN;
QUIT;

The final DATA step interleaves the new exceptions with the
existing master exception file contained in the DAYS timespan
as file ADMEXC00 (aged to ADMEXC01).