Not a problem, Tony. I never want someone to just blindly accept a
quick fix. It would be great if manufacturer's would commit the kind of
resources you mention when I submit an intermittent/can't
replicate/seems to only be on my system type of problem, but my
experience is with this kind of one-off, small potato client's problem,
I'm lucky if I get a first-tier, new to their helpline, fresh out of
training rookie to even give me a call to verify if I knew what I was
To me, a work-around is far more desirable to try and gather more
information in the error reporting than to leave the situation as is
with nothing to give back to the system owner besides a shoulder shrug.
If the problem changes, this is as good a piece of information as any
that it's most likely not data related and that the problem really does
need the type of resources you mentioned.
As always, Tony, you have very good, valid information that you
generously share with everyone. We all appreciate that of you.
[mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Tony Gravagno
Sent: Friday, July 26, 2013 10:13 AM
Subject: Re: [U2] [UD] BASIC Code Failing
> From: Woodward, Bob
> If this occasional problem is consistently the same lines then just
> validate the insert afterwards...
Dale, don't accept that solution. (Sorry Bob)
Note, we're still not really Sure yet that this is a good definition of
the problem, just a working theory...
Overall, the problem seems to be that some statements can't be trusted
to be executed - not specific statements or functions, but random lines
of code in different systems. The problem might not be something wrong
with the statements themselves but just where they happen to be in the
program. The issues might be fixed with some extra code, or by putting
the few lines in question into an internal subroutine just to move the
bytecode to a different location. But a "solution" like that is random
and subject to just moving the problem to an as yet unknown and perhaps
more critical location.
When you can't trust a line of code to be executed in a linear series of
statements the reliability of everything we do comes into question.
If this is indeed the problem, "fixing" it by writing work around code
isn't good for anyone here.
It's tough to call in Support when the problem is so vaguely defined but
having "sat in the chair" as a QA Manager and Product Manager for a
related product, I can tell you the resolution starts with finding sites
that seem to have this issue, assigning someone to the task of gathering
data and scheduling tests on the target systems, getting engineers to
verify the issue, and establishing a pattern from which a problem can be
I don't know who has to initiate that with Rocket Software but I'd
assume it starts with paying clients filing formal requests with Support
and committing to follow-through toward a resolution. And while
re-compilation might indeed be the correct fix, don't accept a
tier-1 techie solution intended to just get you off the phone!
U2-Users mailing list
U2-Users mailing list