I *think* this is historical. It used to be that ON ERROR didn't exist (I don't think ELSE existed initially!). So I guess that ELSE was added to deal with failed writes but not with "file isn't there" type problems, then ON ERROR was added to deal with those.
I think originally, when even ELSE didn't exist, *any* problem with a WRITE would cause your program to bomb. But that was in the days before networks were the norm, and absent hardware failure any failure in a WRITE was almost certain to be a programming error of some sort. Cheers, Wol -----Original Message----- From: Perry Taylor [mailto:[EMAIL PROTECTED] Sent: 23 May 2007 21:08 To: u2-users@listserver.u2ug.org Subject: RE: [U2] [BB] U2 Enhancement Request - WRITE Be wary of ON ERROR. There are a few conditions under which ON ERROR is not taken where I really think it should and some anomalous return values from STATUS(). Here is an example from a support case I submitted to IBM some time ago ... ---------------------------------------------------- WRITE ITEM ON F.VAR, ITEM.ID ON ERROR CRT 'ERROR': END THEN CRT 'THEN': END ELSE CRT 'ELSE': END CRT ', STATUS()=': STATUS() When I run this on a uniVerse hashed file for which I do not have write permissions I get… Program "PTEST2": Line 23, WRITE attempt on read-only file. ELSE, STATUS()=-2 1) Why do I get the message 'Program "PTEST2": Line 23, WRITE Attempt on read-only file.' when I am using the ON ERROR clause. 2) Shouldn't the ON ERROR clause have been taken rather than ELSE? 3) Why does STATUS() return -2, which according to the documentation is "The record was unlocked before the WRITE operation."? 4) Looking at all the possible return codes from STATUS() after a WRITE it does not appear that there is a way to determine that the cause for failure is a permissions denial. Is this not possible to detect? ---------------------------------------------------- The answers I got ... 1) (In a nut shell) No way to suppress this. 2)ON ERROR is only branched to on a fatal error which, in your test case (no permission), is not considered fatal - and as such the testing of status() is invalid. Fatal errors are file not opened, file handle is null, a part file for a distributed file is not found. 3) Unknown 4) No there is not. Have to write your own permissions-checking routine There are similar issues with OPENSEQ relating to permissions issues. FYI. Perry Taylor ZirMed, Inc. 626 West Main St , 6th Floor ● Louisville, KY 40202 www.zirmed.com -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Nick Cipollina Sent: Wednesday, May 23, 2007 2:48 PM To: u2-users@listserver.u2ug.org Subject: RE: [U2] [BB] U2 Enhancement Request - WRITE Like anyone could ever know that! Thanks, Nick Cipollina -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Karen Bessel Sent: Wednesday, May 23, 2007 1:11 PM To: u2-users@listserver.u2ug.org Subject: RE: [U2] [BB] U2 Enhancement Request - WRITE Use the write ON ERROR clause to display info about the error using STATUS, FILEINFO, etc. Any time that I've ever encountered an abort in a BASIC program due to a write error, it's given me the source code line #. I can then look at the source code to see what file was being written to and start my investigation there. -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Susan Joslyn Sent: Wednesday, May 23, 2007 12:33 PM To: u2-users@listserver.u2ug.org Subject: [U2] [BB] U2 Enhancement Request - WRITE When a BASIC program in either U2 flavor attempts a write to a file that cannot be written to the program bombs completely out to TCL and no information is given about the file, nor about the specifics (is it the owner, the group, the RWX permissions?). There are system commands in both flavors that can be used to query a file's write-ability before attempting the WRITE. Before I go try to find every write in the system and put that check into place, I'm wondering why can't the write itself do this? Ideally not bomb out of the program, but even if that is hard to correct, reporting the NAME OF THE FILE that couldn't be written to would save many hours of system scouring! Susan Joslyn ------- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/ ------- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/ ------- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/ CONFIDENTIALITY NOTICE: This e-mail message, including any attachments, is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. ZirMed, Inc. has strict policies regarding the content of e-mail communications, specifically Protected Health Information, any communications containing such material will be returned to the originating party with such advisement noted. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. ------- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/ ------- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
