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
             PM                        taken


             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/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/

[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 pic02263.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/

Reply via email to