Hi Guys

Stupid question here but ....

I have a "simple" piece of code to test the commit statement which has left me somewhat surprised by its functionality.
I'm probably asking too much if at line 6 when the pgm (stops) I delete the file TEMP from another terminal and then allow the code to continue.
I then get (unexpectantly) 

I would have expected the commit line to execute and report the error???
Am I asking too much?

I'm running:

Yes, you're asking too much. Take out the "begin" and "commit" statements and you'll see the same behavior. When you deleted the file, did it say something about the file being open?

I tried to call, but no answer. Here's an excerpt from a document I wrote on OSFI open/read/write/close programming. Maybe this will help?

OSFI programming recommendations:

·      Any program (foreground or phantom) that opens OSFI files should have the following statements executed before opening, reading or writing OSFI files:

o  EXECUTE \\NET-ERRORS (SL\\ CAPTURING JUNK

§  The L options tells the system "log RFSE's, don't stop and prompt the user for intervention, don't drop to debugger".

§  The S option suppresses echoing of the NET-ERRORS state, probably redundant with CAPTURING JUNK clause.

o  EXECUTE \\SET-REMOTE-CLOSE (N\\ CAPTURING JUNK

§  Normally when remote files are opened, the file handle is cached by D3 and never explicitly closed, even by a CLOSE statement. This was done to enhance throughput. Setting remote close on allows explicit closing of remote files so that cached handles for no-longer-available resources do not linger to cause problems, as in a temporary network problem.

·      Any program accessing OSFI files should keep them open for as narrow a window as practically dictated by throughput need. Ideally when a single record is going to be read and then written, the flow should be:

o  Open

o  Read and/or Write

o  Close

within the inner loop, not opened at the top of the program and closed at program termination. Exceptions would be when processing a significant number of records in a short period of time where the preferred flow should be:

o  Open

o  Read and/or Write all records

o  Close

within the inner loop.

·      In programs that open more than one OSFI file, it's a good idea for any OPEN/ELSE logic to close all OSFI files opened in the program to make sure that none get missed. Example:

o  OPEN RMTFLE1 TO FILE1 ELSE GOTO EXIT

o  OPEN RMTFLE2 TO FILE2 ELSE GOTO EXIT

Then at exit:

o  CLOSE FILE1

o  CLOSE FILE2

In the event that the first OPEN was successful and the second OPEN failed, the first file needs to be closed on exit, and it doesn't hurt anything to close a file that was never successfully opened.

·      All WRITEs performed on OSFI files should use the ON ERROR clause to recover from a failed write.

o  Any ELSE clause on a failed OSFI OPEN or ON ERROR clause on a failed OSFI WRITE should handle a graceful close of all OSFI files and exit from the program, and optionally a wait and retry cycle. To the degree that an ELSE clause on a failed read can be certainly attributed to a network error (and not merely a record that genuinely does not exist) should follow the same cleanup and exit path and optional wait and retry cycle.

so those statements
EXECUTE \\NET-ERRORS (SL\\ CAPTURING JUNK
EXECUTE \\SET-REMOTE-CLOSE (N\\ CAPTURING JUNK
should be in every program ? even if they are sub-routines?
or can put only in the main program?