DEC Pascal v5.5-54 (OVMS/VAX v6.2) - default condition handler unexpected/undocumented behaviour?

[Mark_Corcoran]

I've been looking at a problem that was encountered a few days ago, when a program threw a %PAS-F-KEYDUPNOT error.

It takes records from an input file and extracts two components from each record to generate a key for a record that it attempts to create in another file.

In this case, someone had manually edited the input file (appears to be a copy & paste) resulting in an extra character being inserted in each record, shifting the second component along by one position.

As a a result, keys that should have been generated as YYMMDDnnnn, ended up as "YYMMDD nnn", meaning that for every 10 records in nnnn, 9 of them became duplicate keys of the first.

The original programmers didn't write any defensive sanity checking, hence the error being generated (we all know that adding checking takes extra development time, and if you can be "sure" that you can control the inputs, you can (temporarily) put off adding the checking until a later date).

Where the KEYDUPNOT error occurred, a condition handler was established, which caused it (and a subsequent %SYSTEM-W-UNWIND) to be recorded in an application log file, before resignalling the condition with SS$_RESIGNAL

The user who reported the problem runs the program via a menu written as a DCL command procedure, and he made so many attempts at getting it to work that by the time I came to work a few days later and read his email, the log files had been purged by system houskeeping procedures.

When reproducing the problem on the test system, I was surprised to find that %PAS-F-KEYDUPNOT error did not appear in the file to which SYS$OUTPUT had been redirected (the DCL command procedure/menu redirects the output, so that it can search for any errors that the program itself records to SYS$OUTPUT).

I found that if SYS$OUTPUT is redefined /USER, then the Pascal RTL error does not make its way to the redirected SYS$OUTPUT, but if it is redefined /PROCESS then it does get to the redirected SYS$OUTPUT.

The HP Pascal for OpenVMS User Manual (AA-PXSND-TK - admittedly for Pascal v5.8 (VAX)) says that "The default handler calls the system’s message output routine to send the appropriate message to the user. Messages are sent to the SYS$OUTPUT and SYS$ERROR files."

I found that if I redirected SYS$ERROR to a different file, it doesn't contain the run-time error.

So, what the manual says seems to be at odds with what happens (though this is an older version of Pascal, so it may well be different).

Does anyone know if this behaviour (run-time errors only being written to SYS$OUTPUT and only if defined /PROCESS) is still the same in more recent versions of the compiler, or are there some special compiler qualifiers or logical names that alter the behaviour?

I can't readily find anything to explain the behavioural difference (upgrading to more recent version of HP Pascal and/or OpenVMS isn't likely to happen) - it's only out of idle curiosity that I ask...

Regards,

Mark

[Steven Schweda]

   I know almost exactly nothing about Pascal, and my ability to debug
invisible code is very poor, but...

> Where the KEYDUPNOT error occurred, a condition handler was
> established, [...]

   "established" or "triggered"?

> [...] if SYS$OUTPUT is redefined /USER, then the Pascal RTL error does
>not make its way to the redirected SYS$OUTPUT, but if it is redefined
>/PROCESS then it does get to the redirected SYS$OUTPUT.

   This may not be amazing, depending on what the program does.  See,
for example:

      https://community.hpe.com/t5/x/x/td-p/7007036

[Mark_Corcoran]

> "established" or "triggered"?

Poor choice of word placement on my part.  For this:

"Where the KEYDUPNOT error occurred, a condition handler was established, which caused it (and a subsequent %SYSTEM-W-UNWIND) to be recorded in an application log file, before resignalling the condition with SS$_RESIGNAL"

Read this:

"A condition handler was established, which meant that when the KEYDUPNOT error occurred and triggered the condition handler, the condition (of KEYDUPNOT, and a subsequent %SYSTEM-W-UNWIND) were recorded in an application log file, before resignalling the condition with SS$_RESIGNAL"

>my ability to debug invisible code is very poor

I didn't provide the code or even a reproducer, because the Pascal documentation doesn't match the behaviour (or document any limitations regarding redirecting SYS$OUTPUT (but if the documentation was correct, it should still be output to SYS$ERROR)) - I was just really looking for anyone who had knowledge of whether or not there were limitations in the way the Pascal default (run-time) condition handler deals with SYS$OUTPUT, and whether or not the behaviour (or documentation) had changed in later versions.

I have since changed the definition of SYS$OUTPUT to use /PROCESS, but I was curious as to why I should have to do it (I don't believe it to be anything that the code is doing, but I will create a small reproducer that simply defines an array and tries to access element last+1 to trigger the RTL to generate an error, and see whether or not that has the same (IMHO) errant behaviour.

Errant behaviour should be fixed or at least documented.

I have however another compiler issue (another post to follow) that has prevented me from spending time on creating a Pascal reproducer, as I was creating a C reproducer for the other problem.

Mark