NOPRINCIO, Unable to dddd principal device: DDDD at LLLL due to: SSSS
Run Time Fatal: This indicates that GT.M attempted to, but could not, READ from, or WRITE to (direction indicated by dddd), the PRINCIPAL device, and therefore attempted to issue an appropriate error, for example, an IOEOF, TERMHANGUP, or TERMWRITE at location LLLL, with a status of SSSS. However, if the error handling does not prevent any and all subsequent READs and WRITEs to the no longer available PRINCIPAL device, the next subsequent I/O error shuts down the process immediately to prevent mysteriously lost output, or, worse, an indefinite loop. The NOPRINCIO message appears in the operator log
Action: The NOPRINCIO error message is FATAL which does not drive device or trap handlers and terminates the process. This termination does not allow any application level orderly shutdown and, depending on the application, may lead to out-of-design application state. Therefore FIS recommends appropriate application level error handling that recognizes the preceding error and performs an orderly shutdown without issuing any additional READ or WRITE to the principal device. The most common causes for the principal device to cease to exist involve terminal sessions or socket connections (including those from processes started by inetd/xinetd). When the remote client terminates the connection, the underlying PRINCIPAL device becomes inaccessible making any subsequent attempt to READ from, or WRITE to, it hopeless. In the case of terminals, a user closing the window of a session without cleanly exiting from the GT.M process sets up the case that can drive this error. GT.M does not issue NOPRINCIO errors from Direct Mode, because it is a developer tool, or at the completion a HEREDOC in a shell script. However, this means a HEREDOC must use ZHALT to return a specific status to the shell, and that a $ETRAP that bounces a process into Direct Mode terminates without evidence.
