 |
» |
|
|
|
Ask the Wizard Questions
UCX: nfs disk and CONVERT
The Question is:
In a batch job we have a simple convert call: it takes an input file that
is stored on an Alpha disk and puts the output on an NFS-mounted disk that
is on a Unix (HP) computer. The convertion makes that the format of the record
becomes stream_lf. Everything works ok. The output file is stream_lf formatted.
The output file is an input into a Unix application, that we (VMS-users) can
not control. Before the Unix application starts to read the data, the file
is moved to another Unix directory and "disapears" from the NFS-disk.
SOMETIMES THE CONVERTING REPORTS ERRORS. There are 2 kind of the errors:
1. File not found, (or no such file, I don't remember) that points to the output
file.
In this case we can see that the file has really been created on the NFS
disk and even treatment of this file made by the Unix application was done
correctly. I.e. we can ignore this message and the only problem we have
is to make up our minds if we should delete or not delete the input file,
used in CONV call, since the DCL reports the error status.
2. %CONV-F-WRITEERR, error writing DNFS3:[000000]...fil_spec...
-RMS-F-WBE, error on write behind
-SYSTEM-E-NOSUCHFILE, no such file
In this case the file that is created on the NFS-disk is also taken by
the Unix application but the data seems to be corrupted because the Unix
application reports an error in the indata.
It looks like that converting was not completed when the Unix application
or mv (move) started to operate on the file.
We've noticed that error 1 is common when we have small files and error 2 when
the files are big, like 500 blocks.
My guess is that there is no lock mechanism that makes the file unavailble for
the Unix system if it is a file on NFS mounted disk created by the VMS.
The Unix application, loops and searches for the file and as soon it has
found a file, it "steals" the file for OpenVMS, that errs.
Could it be so?
Do you have any solution?
The Answer is:
UCX: nfs disk and CONVERT
In a batch job we have a simple convert call: it takes an input file that
is stored on an Alpha disk and puts the output on an NFS-mounted disk that
is on a Unix (HP) computer. The convertion makes that the format of the record
becomes stream_lf. Everything works ok. The output file is stream_lf formatted.
The output file is an input into a Unix application, that we (VMS-users) can
not control. Before the Unix application starts to read the data, the file
is moved to another Unix directory and "disapears" from the NFS-disk.
SOMETIMES THE CONVERTING REPORTS ERRORS. There are 2 kind of the errors:
1. File not found, (or no such file, I don't remember) that points to the output
file.
In this case we can see that the file has really been created on the NFS
disk and even treatment of this file made by the Unix application was done
correctly. I.e. we can ignore this message and the only problem we have
is to make up our minds if we should delete or not delete the input file,
used in CONV call, since the DCL reports the error status.
2. %CONV-F-WRITEERR, error writing DNFS3:[000000]...fil_spec...
-RMS-F-WBE, error on write behind
-SYSTEM-E-NOSUCHFILE, no such file
In this case the file that is created on the NFS-disk is also taken by
the Unix application but the data seems to be corrupted because the Unix
application reports an error in the indata.
It looks like that converting was not completed when the Unix application
or mv (move) started to operate on the file.
We've noticed that error 1 is common when we have small files and error 2 when
the files are big, like 500 blocks.
My guess is that there is no lock mechanism that makes the file unavailble for
the Unix system if it is a file on NFS mounted disk created by the VMS.
The Unix application, loops and searches for the file and as soon it has
found a file, it "steals" the file for OpenVMS, that errs.
Could it be so?
Do you have any solution?
|
