Re: MCH3402 - and Built-In-Function %OPEN

BirgittaHauser wrote:

<<SNIP>>
If Not %Open(MyPrtF);
Open MyPrtF;
EndIf;
Write MyFormat;
I checked it by debugging my service program. The Open-Statement
gets not executed, but the WRITE fails.
Then I tried the following:
Always open the printer file and check %Error and %Status:

Open(E) MyPrtF;
If Not %Error or (%Error and %Status = 1215);
Close(E) MyPrtF;
OpenPrtFProcedure();
Else;
WriteProtocolFile(SDSMsgTxt)
EndIf;
Write MyPrtF;
Now the procedure gets executed, but instead of closing and reopening
the printerfile the ELSE-Branch is executed and I still get MCH3402,
but the write no longer fails. IMHO it seems to be a bug.

BTW now the client complains about the severity 40 error message
of MCH3402 in the joblog and I must remove it. (No idea how to
realize.)
<<SNIP>>

Not to contradict the appropriateness of avoiding the condition ever arising, by proper use of ILE. Merely to offer a circumvention:

The logic in the first case can be modified to monitor for the failure on the write, such that if it is the mch3402, then the file can [safely] assumed to have been closed outside of the service program [by rclrsc].

If Not %Open(MyPrtF); //
Open MyPrtF; //
EndIf;
Write MyFormat; // should fail if reclaim closed the prtf
monitor
call qmhrcvpm // ?? of exception msg to determine if mch3402
If mch3402 then do; // _assume_ origin of rclrsc closed file
call qmhrcvpm; // remove the escape message mch3402 by key
open myprtf;
write myformat;
end;
endmon

I do not understand the failure in the logic of the second case. Are you suggesting the write gets the mch3402 and works? Not likely. There is an added WriteProtocolFile() which is not in the prior logic. Is it that function which gets the Write failure? If so is that a separate procedure which is similarly not yet recoded to handle the same issue where the file was /closed by reclaim resources/; i.e. does not monitor for the failure on the first write after the open within the procedure?

Regards, Chuck