(j3.2006) when does an error condition occur in executing EXECUTE_COMMAND_LINE

Michael Ingrassia michaeli
Wed Jan 7 19:01:04 EST 2009

Chapter 6 has various places where the standard says "If <such-and-such> ...
an error condition occurs" when talking about allocations.  NOTE 9.43
shows a case where an error condition will occur with the INQUIRE statement.
For I/O, mostly error conditions are not spelled out, but some can be
inferred: assures us that an error condition occurs if an advancing input/output
statement doesn't position a record file after the last record read or
written.  9.6.4 assures us that an error condition occurs if a WRITE or PRINT for a file that does not exist did not create the file.

But I can't find any language in the standard which defines or suggests or
permits the inference of any error conditions for EXECUTE_COMMAND_LINE.
The standard doesn't promise much beyond that a command will be executed
synchronously or asynchronously, and since its promises are so weak almost no
error conditions can be inferred from the standard.  

1) Maybe it's an error condition if a command can't be executed.

If so, wouldn't we need more precise language like

[13.7.57p3]  WAIT (optional) .... If WAIT is present with the
	value false, and the processor supports asynchronous execution of the
	command, then if no error condition occurs 
	the command is executed asynchronously; 
	otherwise it is executed synchronously unless an
	error condition occurs. 

2) Or maybe there just plain aren't ever any error conditions.
	Even if you can't execute a command at all, that's still an everyday
	occurence which will presumably be observable via EXITSTAT, and a
	processor could declare that everything went as specified, so no
	error condition.	

Is this acceptable?   Or couldn't we get closer to what would make more sense by
adding language like

(PROPOSED EDIT 2) [13.7.57p3]
If the command is executed synchronously but the processor does not return an
exit status, then an error condition occurs.   If the command is executed
synchronously and returns a processor-dependent exit status that does not
correspond to normal termination, then an error condition occurs.

For that matter, it's amusing to think that a command that is run asynchronously
might run into problems after the processor has advanced past the call to
EXECUTE_COMMAND_LINE.  Obviously CMDSTAT can't be retroactively assigned a
positive value.  Maybe we should replace

 "If an error condition occurs" 

in [13.7.57:p3 the description of CMDSTAT and CMDMSG] with

 "If an error condition occurs while executing a command synchronously,
  or has already been detected while executing a command asynchronously,"

	--Michael I.

More information about the J3 mailing list