Error Messages Produced By the Compiler

When Phase 1 of the HAL/S compiler (the syntax checking phase) detects an error condition, a diagnostic message describing the error is placed in the primary (formatted) source program listing at the point where it was detected. These error messages take the following form:

*****c ERROR #n OF SEVERITY s.*****

*****text of error message

After all error messages other than the first one in a given compilation, the following line is also printed:

*****LAST ERROR WAS DETECTED AT STATEMENT m*****

The letter c here represents a mnemonic error name uniquely identifying this message; n indicates the number of errors which have so far been identified in the compilation; s is a severity code; and m is the HAL/S statement number of the most recent previous

statement that received an error message.

The compiler can recognize any one of a large number of error conditions, and responds by searching through the built-in ERROR library to find the correct message. Each error (and each message) has a unique mnemonic designation or name used by the compiler to search the ERROR library. The designation may be somewhat helpful to the

programmer because it describes in symbolic form the type of error encountered. The error name consists of one or two letters, followed by a one or two digit number. The first letter designates a “major error class” (e.g., errors related to assignment statements, subscripting errors, etc.), while the second letter, if present, indicates a sub-class further describing the error. The number specified simply indicates members of a class -

subclass group.

The severity indication s in the error message shows the effect of the error on the compilation process. The possible severities and their effects are as follows:

No template is generated if a severity 1 (or greater) error occurs in Phase 1. No SDF is generated if a severity 1 (or greater) error occurs before Phase 3.

A complete list of error groups and subgroups, as well as each of the actual error names and messages possible and their severities, can be found in Appendix B, along with more detailed explanations of many of the messages and suggestions as to how the errors may be fixed.

In many cases when the compiler encounters an error condition, it makes some arbitrary s = 0 - warning; compilation proceeds normally, execution still possible.

= 1 - error; compilation proceeds, execution prevented.

= 2 - severe error; syntax check (Phase 1) continues, code generation (Phase 2) prevented.

> 2 - abortive error; compilation halts immediately.

HAL/S-FC User’s Manual USA003090 32.0/17.0

4-10 November 2005

but reasonable assumptions as to what actually was meant by the statement in which it found an error. Such assumptions allow syntax checking to continue so that other errors may be discovered. They may also, however, cause the compiler to find “spurious”

errors later on in the program, as a result of the compiler having made the wrong

assumption. Thus, if an identifier is discovered which has not previously been declared, under most conditions the compiler, after emitting a “DU1 UNDECLARED IDENTIFIER”

message, treats it as a scalar. If however, the identifier had actually been meant by the programmer to represent a BOOLEAN, for instance, and if a later statement attempted to assign the value “TRUE” to it, another error message would result from the compiler’s incorrect assumption. Error conditions which are especially likely to have this effect are flagged with the message “ERROR RECOVERY MAY CAUSE SUBSEQUENT

SPURIOUS ERRORS”; when debugging, programmers should remain alert to such a possibility in order not to waste time in a futile attempt to discover the source of a spurious error.

Near the end of the Phase 1 source listing and table printout, a summary of detected errors will be printed, in the following form:

x ERRORS WERE DETECTED. THE MAXIMUM SEVERITY WAS y. THE LAST ERROR WAS DETECTED AT STATEMENT z.

*****SUMMARY OF ERRORS DETECTED IN PHASE I*****

ERROR# 1 of SEVERITY s1 AT STATEMENT e1 ERROR# 2 of SEVERITY s2 AT STATEMENT e2 etc.

Phase 2 of the HAL/S compiler (the code generation phase) may also produce some error messages. These messages have the form:

<text of message>

***c ERROR n of SEVERITY s DURING CONVERSION OF HAL STATEMENT x***

where x is the HAL/S compiler-assigned statement number to which the error refers.

The mnemonic error names for Phase 2 errors are very similar to those for Phase 1 errors, except that the number is always three digits instead of one or two. They too are listed and explained in Appendix B. For the most part, Phase 2 errors will only occur if Phase 1 errors were detected, and indeed the result of these same errors being

reencountered as code generation proceeds. Resolving the problems which led to the various Phase 1 errors, therefore, will often cause Phase 2 errors to disappear.

In addition to printing out the Phase 2 error messages, the compiler also produces a disposition message indicating the total effect of all Phase 2 errors on the compilation.

If there are attempts to downgrade an error and the downgrade was successful, then the error message will still be printed, along with a message of the form:

****** THE FOLLOWING ERROR WAS DOWNGRADED FROM A SEVERITY ONE ERROR TO A SEVERITY ZERO ERROR ******

<text of message>

The severity will be changed to zero to allow compilation to continue. However, if an attempt is made to downgrade an error that does not have a severity of one, then a severity two error message will be produced. If downgrades are attempted then a downgrade summary is produced in Phase 2, unless compilation is to be halted, then the summary will be printed from the latest phase.

The form of the Downgrade summary is:

************ DOWNGRADE SUMMARY *************

***ERROR NUMBER c AT STATEMENT NUMBER n***

***WAS DOWNGRADED FROM A SEVERITY ONE ERROR TO A SEVERITY ZERO ERROR MESSAGE***

The letter c here represents a mnemonic error name uniquely identifying this message; n indicates the statement number that this error occurred in.

If the downgrade was not successful the following messages will appear in the downgrade summary:

*********** DOWNGRADE SUMMARY *****************

***ATTEMPTED DOWNGRADES THAT WERE NOT DOWNGRADED****

**ERROR NUMBER c FOR STATEMENT NUMBER n WAS NOT DOWNGRADED, REMOVE DOWNGRADE DIRECTIVE AND RECOMPILE***

If a downgrade is unsuccessful due to it not being needed, then compilation will return a failure code but the object code and SDF will still be generated.

For further information concerning downgrading error messages, see Section 5.2 concerning compiler directives.

HAL/S-FC User’s Manual USA003090 32.0/17.0

4-12 November 2005

This page is intentionally left blank.