Perhaps it is a problem, perhaps not. Have you corrected the blink error?We are hoping that upgrading UV and patching AIX will make the corruption problem go away (it has happened four times in 12 months so it may take a while for us to feel sure).
If you are finding you have blink issues on a somewhat frequent basis,
perhaps the focus is not in the right place? I might be trying to ascertain
why my files are becoming damaged and worry about how BASIC deals with it
after the corruption is taken care of.
The file is fixed in production, but my copy of the file on our test machine is not. The fall through of the error occurs on UV 10.0.7 (production) and 10.1.2 (our test box) so we know that upgrading UV won't allow us to catch a READ to a file corrupted in this way in the future.That takes the pressure of you and allows you to reproduce the BASIC concern in a controlled environment for support.
If IBM decide it has to ABORT, thats fine, but it shouldn't continue on without something we can trap -- user might talk to us, a phantom certainly won't. I had a suggestion to run COMO on every process and parse the output afterwards; this might work but hardly seems like a better solution than correctly working ON ERROR/ABORT.
> I am not convinced hiding behind ON ERROR when file corruption is detected
is the right thing to do.
But Leroy, I don't want to hide behind the ON ERROR, I want to:
Clean up the process affected correctly. Set a flag in our security routines to stop any other processing (in any other process) from happending until the problem is fixed and email tech support to get on to the machine straight away.
After that I will happily abort and log the user out.
regards,
Craig ------- u2-users mailing list [EMAIL PROTECTED] To unsubscribe please visit http://listserver.u2ug.org/
