OK, I found where this error is being output in the code.

XPP is writing out changes to the job.dld (DLD) file for the division.

Right before closing the DLD file, there is a write() of the full (new) file contents.

If the OS returned an error on the call to write(), the error message would have been "error writing file job.dld" and if that happened it would be probable that the job.dld file would be no longer valid (i.e. corrupted).

Instead, the error happened when the code did a close() of the file.

XPP does also check (most of the time) for an error on just doing a close() of a file and will report if the OS returns an error on such a call.

The reason for this has to do with potential "buffering" of the data being written out.

In some cases (and there are too many factors to try to list them), a call to write() may return success but the data may still be buffered (by the OS) until some later time when it actually gets written out to disk. XPP is not buffering these division files itself, but the OS may be doing so. It may not be until the close() of the file is done that data actually gets written out, and that may be one reason that the OS would return an error on a close().

So if the division was being accessed across a network, or even if local but there were disk problems, then potentially the DLD file could be corrupt - and possibly other files since this was a fatal error causing the xyview to exit w/o doing anything else.

Typically the DPD (job.dpd) file is written out first, then the DLD, and then the job.track file. Since the error happened on the DLD file, that hopefully means that the DPD file is okay.

Unfortunately, there's no way to tell just by the error happening whether there is anything that got corrupted. Accessing the division again will probably indicate whether there appears to be any corruption or not. If you do have problems accessing the division again, I would open up a support call before doing anything else with it. There are a number of possible actions depending on what file(s) have been corrupted.

OK, I found where this error is being output in the code.

XPP is writing out changes to the job.dld (DLD) file for the division.

Right before closing the DLD file, there is a write() of the full (new) file contents.

If the OS returned an error on the call to write(), the error message would have been "error writing file job.dld" and if that happened it would be probable that the job.dld file would be no longer valid (i.e. corrupted).

Instead, the error happened when the code did a close() of the file.

XPP does also check (most of the time) for an error on just doing a close() of a file and will report if the OS returns an error on such a call.

The reason for this has to do with potential "buffering" of the data being written out.

In some cases (and there are too many factors to try to list them), a call to write() may return success but the data may still be buffered (by the OS) until some later time when it actually gets written out to disk. XPP is not buffering these division files itself, but the OS may be doing so. It may not be until the close() of the file is done that data actually gets written out, and that may be one reason that the OS would return an error on a close().

So if the division was being accessed across a network, or even if local but there were disk problems, then potentially the DLD file could be corrupt - and possibly other files since this was a fatal error causing the xyview to exit w/o doing anything else.

Typically the DPD (job.dpd) file is written out first, then the DLD, and then the job.track file. Since the error happened on the DLD file, that hopefully means that the DPD file is okay.

Unfortunately, there's no way to tell just by the error happening whether there is anything that got corrupted. Accessing the division again will probably indicate whether there appears to be any corruption or not. If you do have problems accessing the division again, I would open up a support call before doing anything else with it. There are a number of possible actions depending on what file(s) have been corrupted.