7. Writing Field-developed Applications › 7.3 Writing the Code › 7.3.2 Define the Input Format Routine (DYfdaFMT) › 7.3.2.1 Define a non-MSI Input Format Routine (DYfdafmt) › 7.3.2.1.5 Validate Your Code

7.3.2.1.5 Validate Your Code

Two kinds of tests are needed for your DYfdaFMT routine.
First is a syntax and operational test and second is a
content test, which checks the actual content of data on the
database files produced by DYfdaFMT.

The best way to test the syntax and operation of DYfdaFMT is
to install the FDA into a test database unit, preferably one
constructed solely for the purpose of new product
development.  Following are the advantages of this method:

  o The checkpointing routines operate exactly as they do in
    a normal production environment.

  o You have full control over allocation parameters in your
    test unit.

  o Database data sets, including CHECKPT.DATA and the
    DETAIL, DAYS, WEEKS, MONTHS, and YEARS timespans, are
    permanent data sets, enabling you to interrogate the
    FDA's files in depth.

  o The test unit's database files are available to the
    CA MICS online database access tools, including MSAS
    (SAS/DM with CA MICS macros available) and MICF (if your
    site permits it through the Test CA MICS user profile
    parameter).  MICF will know about the field-developed
    application and will be able to generate inquiries into
    the new product's data.

To test your DYfdaFMT routine in a test database unit:

  o Change sharedprefix.MICS.GENLIB(fdaGENIN) from
    GEN GENSHELL to GEN GENFILES.

  o Install the field-developed application in a test
    database unit.

    Use the checklist in section 3.8.2 of the PIOM if you
    have an existing test database unit.  Use the checklist
    in section 3.8.3 of the PIOM if you need to create a test
    database unit.

    Running the first daily may require several iterations.
    You can delete the database data sets at any time before
    the FDA enters a production status and reallocate them
    for the next test using the standard ALLOCATE or RESTORE
    jobs.  Changes to file structures require resubmitting
    the sharedprefix.MICS.CNTL(fdaCGEN) job to take effect.

    In reviewing the output of the DAILY job, verify that:

      o data elements contain reasonable values
      o data elements are summarized correctly
      o exception conditions are identified
      o management objective report is formatted correctly
      o checkpoint data set is valid

    In reviewing the output of the WEEKLY and MONTHLY jobs,
    verify that:

      o data elements contain reasonable values
      o archive files contain valid data
      o management objective report is formatted correctly

    In reviewing the output of the YEARLY job, verify that:

      o the MICSLOG and SAS Log do not contain error messages

    In reviewing the output of the fdaCHECK job:

      o verify that the file keys for your higher timespan
        files are constructed correctly.

      o consider running the job in the fdaCNTS member in
        sharedprefix.MICS.SOURCE.  This job will perform a
        PROC CONTENTS on each cycle of each file in your
        FDA.  Be sure that the MONTHLY job has been run
        before you run the fdaCNTS job.

      o consider running the job in the fdaDATAS member in
        sharedprefix.MICS.SOURCE.  This job will perform a
        PROC DATASETS on each timespan in the unit that
        contains your FDA.  Be sure that the MONTHLY job has
        been run before you run the fdaDATAS job.