Re: [U2] [UV] File corruption error, but ON ERROR branch not taken
Having talked to IBM (who were as usual amazingly helpful, thankyou Jonathan and Leroy), their conclusion was that when a blink error occurs in a file, the action taken will depend on the type of file corruption that has occured: When a READ is performed and a group is dicovered to have a blink error but the group is otherise OK, the ON ERROR clause will be followed and the error number can be accessed using STATUS() If however the entire group header is wrong, UV sends a warning to stderror but because there is no group header, the record cannot be found so UV decides the record does not exist and takes the ELSE branch -- no further warnings or STATUS() code available. When our files were being corrupted, the corruption overwrote the group header with an error message (trashing the entire group header), hence the ELSE clause was taken. If you wish to follow this problem, the case number is 373556*AUS. IBM had not determined the effort required to correct the problem and could not give me a time frame in which it might be fixed. hope you never come across this, Craig --- u2-users mailing list [EMAIL PROTECTED] To unsubscribe please visit http://listserver.u2ug.org/
Re: [U2] [UV] File corruption error, but ON ERROR branch not taken
But Leroy, the program neither aborts nor takes the ON ERROR branch, it takes the ELSE branch and continues. That might be a problem. I guess you see something in the errlog file, but does anything display on the screen? If so, then perhaps that is a problem. The code is a bit tricky and blink errors are tested a bit deep in it, but it should probably be a non-recoverable fatal error that drops to TCL regardless of the clause used. On the other hand, it is coded such that it takes the ELSE clause, probably not being set as fatal. it has also been that way since blink checking was added to UV, and that has been for quite a few years. I am not sure why this behavior is a problem now. Regards, LeRoy F. Dreyfuss Advanced Technical Services - U2 Technology Analyst IBM U2 Data Management Solutions Tel: 303-672-1254 Fax: 303-294-4832 Mobile: 720-341-4317 External email: [EMAIL PROTECTED] WWW: http://www.ibm.com/software/data/u2/support www.ibm.com/software/data/u2/support - Open, Query, Update, Search - Online! Don't miss out on the IBM DB2 Information Management Technical Conference September 19-24, 2004 - Las Vegas, NV Craig Bennett [EMAIL PROTECTED] auTo Sent by: [EMAIL PROTECTED] [EMAIL PROTECTED] cc stserver.u2ug.org Subject Re: [U2] [UV] File corruption 07/25/2004 08:24 error, but ON ERROR branch not PMtaken Please respond to u2-users I am not sure I would agree that blink errors not taking ON ERROR clauses is a defect. While inconvenient to the user to have a program stop abruptly, the error needs to be dealt with as quickly as possible or the problem will perpetuate. The abort in this case is a deliberate one, i.e. it is intended to occur and not meant to be trapped programmatically. I'll address this internally as well. But Leroy, the program neither aborts nor takes the ON ERROR branch, it takes the ELSE branch and continues. Craig --- u2-users mailing list [EMAIL PROTECTED] To unsubscribe please visit http://listserver.u2ug.org/ [demime 1.01d removed an attachment of type image/gif which had a name of graycol.gif] [demime 1.01d removed an attachment of type image/gif which had a name of pic22473.gif] [demime 1.01d removed an attachment of type image/gif which had a name of ecblank.gif] --- u2-users mailing list [EMAIL PROTECTED] To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] [UV] File corruption error, but ON ERROR branch not taken
Exactly! When I implemented the blink checking logic (wow 10 yrs ago!) it was decided that this WAS a FATAL, stopping the current process in its tracks with that nice blink error message so that it could be fixed immediately. Has the logic changed since 9.6 in uv such that a blink is no longer an immediate FATAL? It sounds that way, since there would never have been a chance to take an ELSE or ON ERROR clause. Just curious to know since I added that functionality. Thanks! At 02:13 AM 7/26/2004, you wrote: Sorry, but I have to disagree. File corruption is not something you should ever ignore, not even for a moment. You have no idea what the problem really is, and to let it go is a bad thing that will only get worse. Since UniVerse doesn't have two-phased commits, there is no way to have UV handle ROLLBACK and ABORT TRANSACTION and have a foreign database understand do the same. You must be code it yourself, which it sounds like you are doing. UV will roll back its own transactions but we cannot roll back transactions within foreign databases without the programmer forcibly doing so through coding. Since the ELSE clause is taken anyway (whether or not is moot for your purposes), you can still do your rollbacks and so forth through your code. As I mentioned in my last post (not on this particular thread), it has been this way since blink checking was introduced, and that has been for a number of years. This is really nothing new. Regards, LeRoy F. Dreyfuss Advanced Technical Services - U2 Technology Analyst IBM U2 Data Management Solutions Tel: 303-672-1254 Fax: 303-294-4832 Mobile: 720-341-4317 External email: [EMAIL PROTECTED] WWW: http://www.ibm.com/software/data/u2/support www.ibm.com/software/data/u2/support - Open, Query, Update, Search - Online! Don't miss out on the IBM DB2 Information Management Technical Conference September 19-24, 2004 - Las Vegas, NV David Jordan [EMAIL PROTECTED] .au To Sent by: [EMAIL PROTECTED] [EMAIL PROTECTED] cc stserver.u2ug.org Subject RE: [U2] [UV] File corruption 07/25/2004 09:16 error, but ON ERROR branch not PMtaken Please respond to u2-users Hi LeRoy Although an immediate abort is probably ideal to prevent further damage to a situation, the ON ERROR clause enables us to identify to operators and support staff the issue that caused a problem as well as deal with transactions with 3rd party database including roll backs, issues with web services and message queques. I had a scenrio, where an upgrade of UniVerse introduced a bug that caused a fatal termination of UniVerse. Not only was this difficult to debug, but the fatal did not release the UniVerse licenses. Trying to resolve the issue remotely was a nightmare. I eventually tracked down that the UniVerse bug caused a file not to be opened when it should have been. The next step then started a transaction on an unassigned file variable and caused a fatal that terminated the session without going through an on-error clause. I think an unassigned file variable could have gone to the on error clause without causing any other damage. (although the application had been tested on the new release, the bug only occurred after the programs were compiled on the new release) Programmaticaly handling fatals, although not always easy, is highly important for mission critical applications like 24x7 banking. Regards David Jordan -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Leroy Dreyfuss Sent: Monday, 26 July 2004 11:53 AM To: [EMAIL PROTECTED] Subject: Re: [U2] [UV] File corruption error, but ON ERROR branch not taken When (if?) we find a solution I'll post the results. IBM have suggested that the initial corruption problem which sent us this way is patched in UV 10.0.17 or later (including 10.1), but they believe that not taking the ON ERROR clause when a blink error is encountered may be a bug. I am not sure I would agree that blink errors not taking ON ERROR clauses is a defect. While inconvenient to the user to have a program stop abruptly, the error needs to be dealt with as quickly as possible or the problem will perpetuate. The abort in this case is a deliberate one, i.e. it is intended to occur and not meant to be trapped programmatically. I'll address this internally as well. Regards, LeRoy F. Dreyfuss Advanced Technical Services - U2 Technology Analyst IBM U2 Data Management Solutions Tel: 303-672-1254 Fax: 303-294-4832 Mobile: 720-341-4317 External email: [EMAIL PROTECTED] WWW: http://www.ibm.com/software/data/u2/support www.ibm.com/software/data/u2
Re: [U2] [UV] File corruption error, but ON ERROR branch not taken
How does the application program determine it is in the ELSE clause due to an error rather than due to record not found? -- Regards, Clif On Jul 25, 2004, at 23:13, Leroy Dreyfuss wrote: Since the ELSE clause is taken anyway (whether or not is moot for your purposes), you can still do your rollbacks and so forth through your code. --- u2-users mailing list [EMAIL PROTECTED] To unsubscribe please visit http://listserver.u2ug.org/
Re: [U2] [UV] File corruption error, but ON ERROR branch not taken
Leroy, But Leroy, the program neither aborts nor takes the ON ERROR branch, it takes the ELSE branch and continues. That might be a problem. I guess you see something in the errlog file, but does anything display on the screen? If so, then perhaps that is a problem. The code is a bit tricky and blink errors are tested a bit deep in it, but it should probably be a non-recoverable fatal error that drops to TCL regardless of the clause used. On the other hand, it is coded such that it takes the ELSE clause, probably not being set as fatal. it has also been that way since blink checking was added to UV, and that has been for quite a few years. I am not sure why this behavior is a problem now. The user sees a message, there is an entry in errlog and then it takes the ELSE branch -- as you say, a problem. I have a case open with techsupport in Australia and hope to supply them with more information today. regards, Craig --- u2-users mailing list [EMAIL PROTECTED] To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] [UV] File corruption error, but ON ERROR branch not taken
Since it was said that the ELSE clause is being taken when a blink error occurs, I am still not sure why this cannot be dealt with as before. Recently it was stated that the need for ON ERROR in this situation was to deal with allowing foreign systems to roll back and what not. In the ELSE clause as with ON ERROR, STATUS() is set to indicate the potential problem. If the error is a write error, then the error number returned comes from SYS.MESSAGE. It does sound like in that circumstance, the issue can still be dealt with. However, as Dave Meeks said, it is intended to fall over and alert the user to the problem. I couldn't find where this anything has changed in this area of our code, nor could I reproduce the condition of it taking the ELSE clause. Regards, LeRoy F. Dreyfuss Advanced Technical Services - U2 Technology Analyst IBM U2 Data Management Solutions Tel: 303-672-1254 Fax: 303-294-4832 Mobile: 720-341-4317 External email: [EMAIL PROTECTED] WWW: http://www.ibm.com/software/data/u2/support www.ibm.com/software/data/u2/support - Open, Query, Update, Search - Online! Don't miss out on the IBM DB2 Information Management Technical Conference September 19-24, 2004 - Las Vegas, NV David Jordan [EMAIL PROTECTED] .au To Sent by: [EMAIL PROTECTED] [EMAIL PROTECTED] cc stserver.u2ug.org Subject RE: [U2] [UV] File corruption 07/26/2004 04:50 error, but ON ERROR branch not PMtaken Please respond to u2-users The problem here is if the abort does not return through the On Error clause, programmers cannot force roll backs on other applications, cannot report errors to operators and support staff or in anyway gracefully stop the application. One of the main reason for the ON ERROR clause was to deal with fatal issues. If this is not possible in the current structure of Uv is there an alternative. As software developers, our applications are compared to products on Oracle, DB2, etc. Does DB2 just abort an application if it hits a corrupted table, or does it return a message for products like MQ series, two phase commits and other proceses to allow a gracefull close to an exit? I would sugggest that this is something worth reviewing in enhancements as it is becoming a major issue in mission critical applications. Regards David Jordan -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Leroy Dreyfuss Sent: Monday, 26 July 2004 4:14 PM To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: RE: [U2] [UV] File corruption error, but ON ERROR branch not taken Sorry, but I have to disagree. File corruption is not something you should ever ignore, not even for a moment. You have no idea what the problem really is, and to let it go is a bad thing that will only get worse. --- u2-users mailing list [EMAIL PROTECTED] To unsubscribe please visit http://listserver.u2ug.org/ [demime 1.01d removed an attachment of type image/gif which had a name of graycol.gif] [demime 1.01d removed an attachment of type image/gif which had a name of pic10949.gif] [demime 1.01d removed an attachment of type image/gif which had a name of ecblank.gif] --- u2-users mailing list [EMAIL PROTECTED] To unsubscribe please visit http://listserver.u2ug.org/
Re: [U2] [UV] File corruption error, but ON ERROR branch not taken
Perhaps it is a problem, perhaps not. Have you corrected the blink error? 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. That takes the pressure of you and allows you to reproduce the BASIC concern in a controlled environment for support. I am not convinced hiding behind ON ERROR when file corruption is detected is the right thing to do. But, someday putting a toggle in uvconfig might make everyone happy. Perhaps someday. Regards, LeRoy F. Dreyfuss Advanced Technical Services - U2 Technology Analyst IBM U2 Data Management Solutions Tel: 303-672-1254 Fax: 303-294-4832 Mobile: 720-341-4317 External email: [EMAIL PROTECTED] WWW: http://www.ibm.com/software/data/u2/support www.ibm.com/software/data/u2/support - Open, Query, Update, Search - Online! Don't miss out on the IBM DB2 Information Management Technical Conference September 19-24, 2004 - Las Vegas, NV Craig Bennett [EMAIL PROTECTED] auTo Sent by: [EMAIL PROTECTED] [EMAIL PROTECTED] cc stserver.u2ug.org Subject Re: [U2] [UV] File corruption 07/26/2004 05:05 error, but ON ERROR branch not PMtaken Please respond to u2-users Leroy, But Leroy, the program neither aborts nor takes the ON ERROR branch, it takes the ELSE branch and continues. That might be a problem. I guess you see something in the errlog file, but does anything display on the screen? If so, then perhaps that is a problem. The code is a bit tricky and blink errors are tested a bit deep in it, but it should probably be a non-recoverable fatal error that drops to TCL regardless of the clause used. On the other hand, it is coded such that it takes the ELSE clause, probably not being set as fatal. it has also been that way since blink checking was added to UV, and that has been for quite a few years. I am not sure why this behavior is a problem now. The user sees a message, there is an entry in errlog and then it takes the ELSE branch -- as you say, a problem. I have a case open with techsupport in Australia and hope to supply them with more information today. regards, Craig --- u2-users mailing list [EMAIL PROTECTED] To unsubscribe please visit http://listserver.u2ug.org/ [demime 1.01d removed an attachment of type image/gif which had a name of graycol.gif] [demime 1.01d removed an attachment of type image/gif which had a name of pic08619.gif] [demime 1.01d removed an attachment of type image/gif which had a name of ecblank.gif] --- u2-users mailing list [EMAIL PROTECTED] To unsubscribe please visit http://listserver.u2ug.org/
Re: [U2] [UV] File corruption error, but ON ERROR branch not taken
I couldn't find where this anything has changed in this area of our code, nor could I reproduce the condition of it taking the ELSE clause. Leroy, I have a corrupted file which reports the following on a READ from the corrupted group: File '/path/FILE': Computed blink of 0x74617C20 does not match expected blink of 0x0! Detected within group starting at address 0x172000! Program *cross*TESTCRPT: Line 10, Internal data error. And then takes the ELSE branch. STATUS is 0. No ABORT, no ON ERROR, no way to tell a group is corrupt. I'm just about to send this to Jonathan Evans in IBM Australia. regards, Craig --- u2-users mailing list [EMAIL PROTECTED] To unsubscribe please visit http://listserver.u2ug.org/
Re: [U2] [UV] File corruption error, but ON ERROR branch not taken
When (if?) we find a solution I'll post the results. IBM have suggested that the initial corruption problem which sent us this way is patched in UV 10.0.17 or later (including 10.1), but they believe that not taking the ON ERROR clause when a blink error is encountered may be a bug. I am not sure I would agree that blink errors not taking ON ERROR clauses is a defect. While inconvenient to the user to have a program stop abruptly, the error needs to be dealt with as quickly as possible or the problem will perpetuate. The abort in this case is a deliberate one, i.e. it is intended to occur and not meant to be trapped programmatically. I'll address this internally as well. Regards, LeRoy F. Dreyfuss Advanced Technical Services - U2 Technology Analyst IBM U2 Data Management Solutions Tel: 303-672-1254 Fax: 303-294-4832 Mobile: 720-341-4317 External email: [EMAIL PROTECTED] WWW: http://www.ibm.com/software/data/u2/support www.ibm.com/software/data/u2/support - Open, Query, Update, Search - Online! Don't miss out on the IBM DB2 Information Management Technical Conference September 19-24, 2004 - Las Vegas, NV Craig Bennett [EMAIL PROTECTED] auTo Sent by: [EMAIL PROTECTED] [EMAIL PROTECTED] cc stserver.u2ug.org Subject Re: [U2] [UV] File corruption 07/25/2004 05:37 error, but ON ERROR branchnot PMtaken Please respond to u2-users The suggestion made by Ray using uvbackup as a check of files is the philosophy we have adopted after experiencing this type of corruption. We run this every Saturday night over all our files and email the result reporting any likely problems. We are still discussing this one with IBM. They suggested that fixtool in UV 10.0.14 or later will find more errors than uvbackup. When (if?) we find a solution I'll post the results. IBM have suggested that the initial corruption problem which sent us this way is patched in UV 10.0.17 or later (including 10.1), but they believe that not taking the ON ERROR clause when a blink error is encountered may be a bug. Craig --- u2-users mailing list [EMAIL PROTECTED] To unsubscribe please visit http://listserver.u2ug.org/ [demime 1.01d removed an attachment of type image/gif which had a name of graycol.gif] [demime 1.01d removed an attachment of type image/gif which had a name of pic31039.gif] [demime 1.01d removed an attachment of type image/gif which had a name of ecblank.gif] --- u2-users mailing list [EMAIL PROTECTED] To unsubscribe please visit http://listserver.u2ug.org/
Re: [U2] [UV] File corruption error, but ON ERROR branch not taken
I am not sure I would agree that blink errors not taking ON ERROR clauses is a defect. While inconvenient to the user to have a program stop abruptly, the error needs to be dealt with as quickly as possible or the problem will perpetuate. The abort in this case is a deliberate one, i.e. it is intended to occur and not meant to be trapped programmatically. I'll address this internally as well. But Leroy, the program neither aborts nor takes the ON ERROR branch, it takes the ELSE branch and continues. Craig --- u2-users mailing list [EMAIL PROTECTED] To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] [UV] File corruption error, but ON ERROR branch not taken
Hi LeRoy Although an immediate abort is probably ideal to prevent further damage to a situation, the ON ERROR clause enables us to identify to operators and support staff the issue that caused a problem as well as deal with transactions with 3rd party database including roll backs, issues with web services and message queques. I had a scenrio, where an upgrade of UniVerse introduced a bug that caused a fatal termination of UniVerse. Not only was this difficult to debug, but the fatal did not release the UniVerse licenses. Trying to resolve the issue remotely was a nightmare. I eventually tracked down that the UniVerse bug caused a file not to be opened when it should have been. The next step then started a transaction on an unassigned file variable and caused a fatal that terminated the session without going through an on-error clause. I think an unassigned file variable could have gone to the on error clause without causing any other damage. (although the application had been tested on the new release, the bug only occurred after the programs were compiled on the new release) Programmaticaly handling fatals, although not always easy, is highly important for mission critical applications like 24x7 banking. Regards David Jordan -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Leroy Dreyfuss Sent: Monday, 26 July 2004 11:53 AM To: [EMAIL PROTECTED] Subject: Re: [U2] [UV] File corruption error, but ON ERROR branch not taken When (if?) we find a solution I'll post the results. IBM have suggested that the initial corruption problem which sent us this way is patched in UV 10.0.17 or later (including 10.1), but they believe that not taking the ON ERROR clause when a blink error is encountered may be a bug. I am not sure I would agree that blink errors not taking ON ERROR clauses is a defect. While inconvenient to the user to have a program stop abruptly, the error needs to be dealt with as quickly as possible or the problem will perpetuate. The abort in this case is a deliberate one, i.e. it is intended to occur and not meant to be trapped programmatically. I'll address this internally as well. Regards, LeRoy F. Dreyfuss Advanced Technical Services - U2 Technology Analyst IBM U2 Data Management Solutions Tel: 303-672-1254 Fax: 303-294-4832 Mobile: 720-341-4317 External email: [EMAIL PROTECTED] WWW: http://www.ibm.com/software/data/u2/support www.ibm.com/software/data/u2/support - Open, Query, Update, Search - Online! Don't miss out on the IBM DB2 Information Management Technical Conference September 19-24, 2004 - Las Vegas, NV --- u2-users mailing list [EMAIL PROTECTED] To unsubscribe please visit http://listserver.u2ug.org/
Memo: Re: [U2] [UV] File corruption error, but ON ERROR branch not taken
Hi Craig, What we do here is to produce a como whenever a program is run from the menu system and then to check the como for common errors such as variable not assigned a value etc. The menu system executes a como on before executing the program. When the program returns back to the menu system, it reads the como record from COMO and searches for error strings. If it finds any, it logs the error and disables that program so that it cant be run again. If the como is clean, then it is deleted. Perhaps you could use a similar system... cheers, asvin. Craig Bennett [EMAIL PROTECTED] on 20 Jul 2004 03:16 Please respond to [EMAIL PROTECTED] Sent by:[EMAIL PROTECTED] To:[EMAIL PROTECTED] cc: bcc: Subject:Re: [U2] [UV] File corruption error, but ON ERROR branch not taken Hi All, we have a site which is experiencing file corruption problems (in one particular file). The clients are trying to find problems in their SAN etc, and have created the errlog item in the UV account so we are logging the Internal Data Error messages when the corruption occurs (UV 10.0.7, AIX 5.1, no details for the SAN). I believe that the client has not applied APAR IY35927 for AIX as previously suggested on the list, despite our hope that this may fix the problem. At some point they will upgrade to UV 10.1, but I don't know when). Leaving aside the problem underling the corruption, we wanted to try and catch this error and halt the sytem until the file has been fixed. We tried testing a copy of the corrupted file: We wrote this program: PROGRAM TESTCRPT OPEN CRPT TO CRPT ELSE STOP READ AREC FROM CRPT,X ON ERROR PRINT ERROR :STATUS() STOP END ELSE PRINT ELSE END END I was expecting the ON ERROR clause to be taken, but when we run the program we see: RUN PGMS TESTCRPT File '/data/TEST/CRPT': Computed blink of 0x74617C20 does not match expected blink of 0x0! Detected within group starting at address 0x172000! Program TESTCRPT: Line 4, Internal data error. ELSE Can anyone tell me why the ON ERROR clause is not taken? Or suggest another way that we can programmaticaly tell that this error has occurred? thanks, Craig --- u2-users mailing list [EMAIL PROTECTED] To unsubscribe please visit http://listserver.u2ug.org/ ** This message originated from the Internet. Its originator may or may not be who they claim to be and the information contained in the message and any attachments may or may not be accurate. ** HSBC Bank plc Registered Office: 8 Canada Square, London E14 5HQ Registered in England - Number 14259 Authorised and Regulated by the Financial Services Authority Member of the HSBC Bank marketing group. We sell life assurance, pensions and collective investment schemes and advise only on our own range of these products. _ This transmission has been issued by a member of the HSBC Group HSBC for the information of the addressee only and should not be reproduced and / or distributed to any other person. Each page attached hereto must be read in conjunction with any disclaimer which forms part of it. Unless otherwise stated, this transmission is neither an offer nor the solicitation of an offer to sell or purchase any investment. Its contents are based on information obtained from sources believed to be reliable but HSBC makes no representation and accepts no responsibility or liability as to its completeness or accuracy. --- u2-users mailing list [EMAIL PROTECTED] To unsubscribe please visit http://listserver.u2ug.org/
Re: [U2] [UV] File corruption error, but ON ERROR branch not taken
Hi All, we have a site which is experiencing file corruption problems (in one particular file). The clients are trying to find problems in their SAN etc, and have created the errlog item in the UV account so we are logging the Internal Data Error messages when the corruption occurs (UV 10.0.7, AIX 5.1, no details for the SAN). I believe that the client has not applied APAR IY35927 for AIX as previously suggested on the list, despite our hope that this may fix the problem. At some point they will upgrade to UV 10.1, but I don't know when). Leaving aside the problem underling the corruption, we wanted to try and catch this error and halt the sytem until the file has been fixed. We tried testing a copy of the corrupted file: We wrote this program: PROGRAM TESTCRPT OPEN CRPT TO CRPT ELSE STOP READ AREC FROM CRPT,X ON ERROR PRINT ERROR :STATUS() STOP END ELSE PRINT ELSE END END I was expecting the ON ERROR clause to be taken, but when we run the program we see: RUN PGMS TESTCRPT File '/data/TEST/CRPT': Computed blink of 0x74617C20 does not match expected blink of 0x0! Detected within group starting at address 0x172000! Program TESTCRPT: Line 4, Internal data error. ELSE Can anyone tell me why the ON ERROR clause is not taken? Or suggest another way that we can programmaticaly tell that this error has occurred? thanks, Craig --- u2-users mailing list [EMAIL PROTECTED] To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] [UV] File corruption error, but ON ERROR branch not taken
Try the On Error with the file open command, the error may be occuring at the file open. Have you played aroubnd with the FILEINFO Command, that may pick up the issue. I have noticed in the path if there is an error with the File Variable that the on error clause does not work in the read statement. Regards David Jordan -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Craig Bennett Sent: Tuesday, 20 July 2004 12:16 PM To: [EMAIL PROTECTED] Subject: Re: [U2] [UV] File corruption error, but ON ERROR branch not taken Hi All, we have a site which is experiencing file corruption problems (in one particular file). The clients are trying to find problems in their SAN etc, and have created the errlog item in the UV account so we are logging the Internal Data Error messages when the corruption occurs (UV 10.0.7, AIX 5.1, no details for the SAN). I believe that the client has not applied APAR IY35927 for AIX as previously suggested on the list, despite our hope that this may fix the problem. At some point they will upgrade to UV 10.1, but I don't know when). Leaving aside the problem underling the corruption, we wanted to try and catch this error and halt the sytem until the file has been fixed. We tried testing a copy of the corrupted file: We wrote this program: PROGRAM TESTCRPT OPEN CRPT TO CRPT ELSE STOP READ AREC FROM CRPT,X ON ERROR PRINT ERROR :STATUS() STOP END ELSE PRINT ELSE END END I was expecting the ON ERROR clause to be taken, but when we run the program we see: RUN PGMS TESTCRPT File '/data/TEST/CRPT': Computed blink of 0x74617C20 does not match expected blink of 0x0! Detected within group starting at address 0x172000! Program TESTCRPT: Line 4, Internal data error. ELSE Can anyone tell me why the ON ERROR clause is not taken? Or suggest another way that we can programmaticaly tell that this error has occurred? thanks, Craig --- u2-users mailing list [EMAIL PROTECTED] To unsubscribe please visit http://listserver.u2ug.org/ --- u2-users mailing list [EMAIL PROTECTED] To unsubscribe please visit http://listserver.u2ug.org/
Re: [U2] [UV] File corruption error, but ON ERROR branch not taken
Try the On Error with the file open command, the error may be occuring at the file open. Have you played aroubnd with the FILEINFO Command, that may pick up the issue. I have noticed in the path if there is an error with the File Variable that the on error clause does not work in the read statement. Thanks for the suggestion David, I tried that, but the corruption is occuring in a specific group the OPEN works fine. Craig --- u2-users mailing list [EMAIL PROTECTED] To unsubscribe please visit http://listserver.u2ug.org/
