for production especially, and for a coherent approach to code validation testing, an error reporting system that provides an end-of-job summary of errors is needed.

existing facility: ut_err (Bill Lockman)

             subroutine ut_err(levl,icode,routine,message)
*
*..Description:  
*    Generate error message and terminate if fatal error
*    C*(*) LEVL: 'W' or 'F' (not case sensitive)
*    I*4   ICODE: error code
*    C*(*) ROUTINE: calling routine
*    C*(*) MESSAGE

New implementation:

.db based specification of text error IDs with associated text explanation, severity

              template errc(errcmax)    ! Error codes
                char name      ! string identifier
                char desc      ! description
                int  sev       ! severity level
              end template

              define errc "evcnt" "Event count" 1
              define errc "div0" "Divide by zero" 4

calling interface:

     bberr_init

              Report an error
     bberr(text_id,routine)
              And to report additional numeric/text info:
     bberr_r(text_id,routine,string, rpar, npar) ! reals
     bberr_i(text_id,routine,string, ipar, npar) ! ints
     bberr_c(text_id,routine,string)             ! char string

     bberr_summary      ! end of job summary

provides parameters to return relevant state info

print control: how many errors to print for each severity level
tallies error count for each type and gives end-of-job report
end of job routine to set exit status of program based on worst severity level encountered
same approach, and relevant parts of the .db file error database, can migrate to C++

Why not a more unt-like approach in which all the information is provided in the call parameters of the package's subroutines? Because this buries into the code info that would be more accessible all in one place in a .db file. Gathering together error codes into one place for easy reference -- but without requiring that they all be in one place for the system to work, to make quick mods easier -- I view as an advantage.

The system accepts error report calls for codes not in the .db file; it logs them as usual but prints a message that they should be added to the .db list.

There was a concern that this scheme implies dbio reruns every time a new error code is introduced. This is not the case; new codes can be introduced easily at runtime (via new dynamic template instantiation capability). eg. runtime.db analog containing

! Runtime definitions of error codes
!         codename   description   severity
make errc "badfit" "Bad fit" 3
make errc "counter" "A counter" 1
make errc "badhits" "Bad hits" 3