Design: 09.01.02.02/P01

This is an abstract, language-independent design. Grim details may be found in the corresponding source code. You may return to the documentation for the module containing this program design, or to the entire hierarchical table of topics covered by the PVT.
PROGRAM 1: Error 52 handled by system

CHARACTERISTICS: ynny

OPERATOR SCRIPT:
This program uses the system default error handler.  The usual
means of invoking PVT programs links in a user-defined error handler.
Be sure to use the special mechanism provided (normally the "phfe" or
"phce" command) for invoking programs without the user-defined error
handler, since it overrides the system handler.

The general idea of this test is that errors are generated and the
resulting error messages from the system default error handler are
displayed so that you can verify their contents.

The program needs to display the contents of the error file one message at
a time.  If the system has a consistent message header (as specified to
INITPH), this is done automatically.  If not, you are prompted to say
whether the entire message has been displayed, since one message may occupy
several records.  The program will keep displaying successive records
until the entire message is visible.

Once the entire error message is displayed, you must enter the function
that  generated the corresponding error as reported in the message.  You
may identify the function either by its full generic name ("polyline 3"),
or by its unique number as specified in Fortran and C bindings (these are
the same). E.g. instead of typing "polyline 3", you can enter "8".  If the
message does not identify the function, enter a negative number to signify
this.

The error message may  or may not specify the numeric code of the error.
If so, simply enter the code as prompted.  If not, enter "n".  The program
will then display the standard wording for the error (there may be several
possible wordings, since a given condition may sometimes generate one of
several errors).  If the actual message is accurate with respect to the
standard wording (has the same meaning), enter "y", otherwise "n".

DESIGN:

Throughout this program, every time an error is signalled, the system-defined
error handler should call <error logging> to write in error message on
the error file.

Also, throughout this program, this is what is meant by
   "operator verifies error nmessage":
display next error message in error file to operator
OPQA/according to the error message, which function generated the error?
if (operator response = expected function) then
   OPQA/if error message identifies error code, enter it, else "n"
   if (operator response = "n") then
      display standard error wording(s) to operator
      OPQA/does error meaage match standard wording?
      pass/fail depending on (operator response = yes)
   else
      pass/fail depending on (operator response = expected code)
   endif
else
   fail
   informative message on missing/incorrect function
endif

Use <inquire list of available workstation types> to determine
  mxtype = maximum workstation type

<open workstation> using type = mxtype+1: signals error

TEST: #SR 2
      "If <open workstation> signals an error because the workstation
       type is not recognized by the implementation, it should not
       cause any other effect."
pass/fail depending on (system state = PHIGS-open and
                        workstation state = closed)

*** *** ***  Results of system-defined error handling  *** *** ***

TEST: #SR 2
      "If <open workstation> is called and the workstation type is not
       recognized by the implementation, it should write an accurate,
       self-identifying error message on the error file."
pass/fail depending on (operator verifies error message)

END PROGRAM 1