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

[CRPence <CRPbottle@xxxxxxxxx>]

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