Enscribe Programmer's Guide

status := FILE_GETINFO_ ( filenum, error );.
...
END
ELSE GOTO loop;
The first five WRITEs are successful (number^written = 400), but the sixth fails after transferring 48
bytes from the buffer to the disk (number^written = 48).
If insufficient disk space is available to allocate another extent, the error number returned by
FILE_GETINFO_ is 43 (unable to obtain disk space for file extent).
If the condition occurred because the current extent is the last one permitted in the file, then the
error number returned by FILE_GETINFO_ is 45 (file is full). You might be able to recover from an
error 45 by using a SETMODE 92 call to dynamically increase the maximum number of extents.
If extents cannot be allocated because the file label is full, FILE_GETINFO_ returns error 43 (unable
to obtain disk space for file extent). FILE_GETINFO_ does not return error 45 because, technically,
the file is not full.
Note that an error 43 can also occur when allocating extents with a CONTROL 21 procedure
call.
Figure 23 Example Showing Extent-Allocation Error
Write #1
(400
Bytes)
Write #2
(400
Bytes)
Write #3
(400
Bytes)
Write #4
(400
Bytes)
Write #5
(400
Bytes)
Write #6
(48 Bytes)
(Data)
0 400 800 1200 1600 2000
2048
File Extent Zero
Errors and Partitioned Files
Each partition of a file can encounter error conditions independently of the file's other partitions.
This is especially significant for errors 42 through 45, which pertain to disk space allocation. For
errors 42 through 45 you might be able to correct the situation by using FUP to alter the size
characteristics of the partition where the error occurred.
In any case, after each CCL or CCG return, you can obtain the particular error number by calling
the FILE_GETINFO_ procedure, the partition number of the partition in error by calling the
FILE_GETINFOLIST_ procedure, and the volume name of the partition in error by examining the
file's partition parameter array either programmatically or by using FUP.
Failure of the Primary Application Process
A failure of the primary application process is actually a failure of the processor module where
the primary process of a primary/backup process pair is executing. Operations associated with
this type of failure must be retried by the backup application process when it takes over for the
primary process. Refer to the discussion of checkpointing in the Guardian Programmer's Guide
for information about how to recover from this type of error.
160 Errors and Error Recovery