Issue:
I have a Progress Character Base 9.1E module that has been operational for almost a year. Over that time we have had a few intermittent failures, but Today, out of the blue, this module started continually failing to process files copied from an NFS folder ... all I was able to determine is that the process was failing because it's zero file size test failed.
Unfortunately I was too late to capture any of the files that were deemed zero length while the process was failing. By the time I had added and tested a trap for this issue, the process just start behaving again.
Scenario:
1) copying file from nfs folder to AIX folder using UNIX SILENT with string
"cp -p " + CH-src + CC-space + CH-dst + " 2>/dev/null"
2) then testing for existance of file using SEARCH(CH-dst) <> ?
3) finally testing for file size using FILE-INFO:FILE-NAME = CH-dst
FILE-INFO:FILE-SIZE > 0
I am certain that something external to this program was messing up ... either:
a) the files being copied were really Zero Length (as stated I was too late to capture the files involved in this failure and the IT staff are not convinced, without evidence, that the process on the NFS file server could be generating Zero Length Files)
OR
b) the unix cp command may still have been pending completion when the zero length test was run (which may infer that Progress is possibly not waiting for the UNIX SILENT command to complete)
My questions are:
i) it isn't clear to me whether Progress actually wait for UNIX SILENT to complete before continuing? The Progress notes state Progress makes a separate shell to run the string but doesn't say if it waits for that shell to terminate before continuing with the next line of code.
ii) if i is false then is there any other way to determine either when cp has completed OR is there another command in PROGRESS and or UNIX that would ensure the file has been completely copied before allowing the process to continue?
I could possibly add a subjective timed loop to determine if the file-size changes but was looking for a more robust way to ensure this issue doesn't happen again.
I have a Progress Character Base 9.1E module that has been operational for almost a year. Over that time we have had a few intermittent failures, but Today, out of the blue, this module started continually failing to process files copied from an NFS folder ... all I was able to determine is that the process was failing because it's zero file size test failed.
Unfortunately I was too late to capture any of the files that were deemed zero length while the process was failing. By the time I had added and tested a trap for this issue, the process just start behaving again.
Scenario:
1) copying file from nfs folder to AIX folder using UNIX SILENT with string
"cp -p " + CH-src + CC-space + CH-dst + " 2>/dev/null"
2) then testing for existance of file using SEARCH(CH-dst) <> ?
3) finally testing for file size using FILE-INFO:FILE-NAME = CH-dst
FILE-INFO:FILE-SIZE > 0
I am certain that something external to this program was messing up ... either:
a) the files being copied were really Zero Length (as stated I was too late to capture the files involved in this failure and the IT staff are not convinced, without evidence, that the process on the NFS file server could be generating Zero Length Files)
OR
b) the unix cp command may still have been pending completion when the zero length test was run (which may infer that Progress is possibly not waiting for the UNIX SILENT command to complete)
My questions are:
i) it isn't clear to me whether Progress actually wait for UNIX SILENT to complete before continuing? The Progress notes state Progress makes a separate shell to run the string but doesn't say if it waits for that shell to terminate before continuing with the next line of code.
ii) if i is false then is there any other way to determine either when cp has completed OR is there another command in PROGRESS and or UNIX that would ensure the file has been completely copied before allowing the process to continue?
I could possibly add a subjective timed loop to determine if the file-size changes but was looking for a more robust way to ensure this issue doesn't happen again.