R0 Condition Value - $QIO vs $QIOW?

[Mark_Corcoran]

Whilst looking at the cause of a loss of transactions from one node to another (I found the cause, it's specific to the application, and doesn't merit discussion here), I happened to notice an omission in the code that establishes the network connection (DECnet non-transparent task-to-task) from one node to the other.

The Pascal function makes a call to $QIO with an I/O function of IO$_ACCESS, and if the condition value returned by $QIO is SS$_NORMAL, then it returns a value of TRUE.

Any other condition value, and the function does not return a value (rather than FALSE, as it should do).

The HP Pascal Language Reference Manual states that "the return value is the last value that the function specified by assignment.  If the function has not assigned a value to the function identifier during a given call to the function, HP Pascal does not define the function result".

In other words, the value returned by the function will be whatever happens to be at the revelant memory location on the stack, and will be a by-product of whatever functions, procedures, and system services have been called between process creation and the point the errant function is called.

When compiled with /LIST and /MACHINE, the following Macro-32 was generated (function and variable name changed to protect the guilty):

.ENTRY FUNCNAME,^M<R2,R3,R4,R5,R6,R7,R8,R9>
...
...
...
7$ CMPL STATUS,#1     ;In Pascal, this is: IF status = SS$_NORMAL
   BNEQ 9$
   MOVB #1,FUNCNAME   ;When status=$$_NORMAL, we come here
9$ MOVB FUNCNAME,R0   ;When status<>SS$_NORMAL, we come here

Now, adding diagnostic messages or running the .EXE in the debugger will most likely induce the observer effect, changing the contents of the stack, and what you are trying to observe.

So, I modified the function to return TRUE even if $QIO returned something other than SS$_NORMAL, and tried to induce the behaviour by changing the name of the remote node it was trying to connect to the task on, to be one that was not defined in the local volatile DECnet database.

When the function gets a condition value other than SS$_NORMAL, it records the condition value in a log file, but the rebuilt version of the executable didn't record these.

I then rebuilt it again, adding the optional EFN parameter, but setting it to a value of %X7FFFFFFF, and when tested, a condition value of SS$_ILLEFC was recorded in the log file.

In the System Services Reference Manual, a plethora of condition values can reportedly be returned for $QIO.

For $QIOW, it says "The $QIOW service completes synchronously; ... In all other aspects, $QIOW is identical to $QIO.  For more information about $QIOW, refer to the description of $QIO.", and as you might therefore expect, condition values that could be returned are not listed under the $QIOW system service description, but under $QIO.

Would it be fair to say that condition values that can be returned by $QIO are a subset of those than can be returned by $QIOW, and that a (significant) proportion of the listed condition values can't in fact be returned by $QIO because it is asynchronous, so the requested I/O operation may not be complete by the time control returns to $QIO from the relevant driver (in this case, the ACP process) and hence $QIO only knows that it successfully queued the request?

[In which case, presumably even if the operation had completed by the time control was returned to $QIO (and thence to its caller), the way in which $QIO is coded compared to $QIOW, does not allow for the underlying condition status (simply the IOSB status?) to be returned to $QIO?]

In essence, does $QIO perform some basic sanity checking on the parameters passed to it (and which are generic to $QIO), but by definition cannot perform sanity checking on the parameters that it has to pass on to the relevant driver?

So, for $QIO, you might get SS$_NORMAL, SS$_ACCVIO,  SS$_EXQUOTA, SS$_ILLEFC, SS$_INSFMEM, SS$_IVCHAN, SS$_IVIDENT, SS$_NOPRIV, SS$_UNASEFC, and potentially SS$_DEVOFFLINE, but you wouldn't get (m)any of the link-related condition values (SS$_INVLOGIN, SS$_IVDEVNAM, SS$_*LINK*, SS$_NOSUCH* etc.)?

I'm just trying to put a better description in the comment block in the code as to why I ended up using an invalid EFN rather than inducing a connection failure.

Mark

[Ian Miller.]

$QIO can perform device dependent and device independent checks before starting the I/O. For some requests starting the I/O is not needed. The return status shows the results of these checks. I suspect QIO and QIOW can return the same range of condition codes. The result of what happened after the I/O was started is in the IOSB in either case.

[Mark_Corcoran]

>$QIO can perform device dependent and device independent checks before starting the I/O

When you say $QIO Ian, in this context, do you mean $QIO and $QIOW, or just $QIO?

Based on testing experience, it seems that the $QIO can return a status indicating that it either successfully queued a request, or that it failed to queue the request*, but not the ultimate failure reason of a successfully-queued-but-unsuccessfully-completed I/O request.

*Potentially:
As a result of checks that it performs before starting the I/O like whether or not certain parameters (like the event flag number) are valid in general - there are certain things that would be device-dependent and presumably verified by the device driver (otherwise you end up moving the device-dependent checks from the device driver into the $QIO code (or worse, duplicating them)), or

Due to insufficient process/system quota/resources.

Mark