Tony,
I think Bob may have a good troubleshooting technique here. It would be
simple to eliminate causes. Line 107 has a couple of potential problems:
0107: SUPREC = INSERT(SUPREC,2,1,0,POLREC<6>)
I have seen these 3 situations in more than 1 MV implementation/flavor -
1. If POLREC<6> is null, an empty value won't be inserted, throwing
associated values out of sync. Fix by prefixing or suffixing POLREC<6>
with a character that won't be in the data, then converting it out later.
2. INSERT sometimes doesn't like delimited source. Fix by moving
POLREC<6> to a variable and inserting that.
3. If POLREC<6> has multivalues itself, that presents a whole different
problem. Check it first.
All these things can be checked in a little test program in just a few
minutes, and a safer coding technique used.
Charlie
If this occasional problem is consistently the same lines then just
validate the insert afterwards:
0106.1 MV.CNT = DCOUNT(SUPREC<2>,@VM)
0107: SUPREC = INSERT(SUPREC,2,1,0,POLREC<6>)
0107.1 IF SUPREC<2,1> NE POLREC<6> THEN
0107.2 MV.CNT2 = DCOUNT(SUPREC<2>,@VM)
0107.3 IF MV.CNT = MV.CNT2 THEN GOSUB REPORT.ERROR
0107.4 END
With this logic, you're verifying the value and that a new value is, in
fact, being created in the attribute. You may want to tweak the logic a
bit to match your exact specifics, like if POLREC<6> is a non-null
value, but this should give you an idea.
Tiny Bear's Wild Bird Store
Home of "Safety Net Shipping"
http://www.TinyBearWildBirdStore.com
Toll Free: 1-855-TinyBear (855-846-9232)
On 07-26-2013 12:13 PM, Tony Gravagno wrote:
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 diagnosed.
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!
HTH
T
_______________________________________________
U2-Users mailing list
U2-Users@listserver.u2ug.org
http://listserver.u2ug.org/mailman/listinfo/u2-users
_______________________________________________
U2-Users mailing list
U2-Users@listserver.u2ug.org
http://listserver.u2ug.org/mailman/listinfo/u2-users
