Linking problem in 7.10G
Deskin, Bob
Bob.Deskin@Cognos.COM
Fri, 4 Sep 1998 09:14:16 -0400
Thanks for the kind words Arthur.
Bob
> ----------
> From: arthur kogan[SMTP:akogan@westpac.com.au]
> Sent: Friday, September 04, 1998 12:18 AM
> To: alex ling
> Cc: Bob.Deskin@Cognos.COM; powerh-l@lists.swau.edu
> Subject: Re: Linking problem in 7.10G
>
> Hi Alex,
>
> You wrote "I reached my own finding yesterday which was then pasted on to
> you last night.".
>
> I thought we arrived at the explanation for this problem together. How
> about some credit for your old co-worker? I would also like to see the
> picture of Bob with your finding "pasted" on to him!!!
>
> JUST JOKING!!!
>
> But on the serious note, you also wrote "Suggestion - C/S Asia Pacific
> needs more than just 1.5 staff!!"
>
> I think to be fair, it should be acknowledged that although currently
> there are only 1.5 staff in Cognos Customer Support Asia Pacific
> supporting Powerhouse, this has been generally sufficient under normal
> workload over my last year of working there (to march 1998). There were 2
> of us at that time and we were able to use some (actually quite a lot) of
> our time on support of BI products. I think this is a testimony to the
> quality and stability of Powerhouse. Also (and without naming names) there
> are a number of other very experienced staff in Cognos Asia Pacific (who
> are normally used in other areas of the business) that management can call
> on in times of need. This is quite apart from the ability of calls to be
> passed on directly to C/S in Canada, who have quite a large team. As you
> know (having worked there), the staffing levels are demand driven and
> staff can be moved temporarily to accommodate this, or new staff hired if
> the trend persists. Having worked in Cognos customer support I can say
> that although some days were busier than others, we were never worked to
> stress levels, and according to customer surveys have always been able to
> provide top level of support. I know from experience that Cognos has
> attached great importance to its customer support function and uses its
> quality as competitive advantage against its competitors. Since leaving
> Cognos in March I have had a couple of occasions to call on customer
> support and have to say that I am very happy with the response I got. I
> also think this list is of great benefit to end users, having people like
> Bob Deskin on it.
>
> Just my thoughts...
>
> Arthur Kogan
> Westpac Financial Services
> Sydney, Australia
>
>
>
> alex ling wrote:
>
> ---"Deskin, Bob" <Bob.Deskin@Cognos.COM> wrote:
> >
> > I just heard from Allison about the linking problem in 7.10G and I
>
> thought
> > everyone would be interested. The bug # is 245681 and has to do
> with
> getting
> > a data conversion error linking an InterBase long binary to an
> InterBase
> > short binary. Turns out that the error existed at least as far
> back as
> > 7.10E4 (and probably further back) but it was ignored rather than
> being
> > reported. During the development of the QTP Tracer (which is
> Allison's baby
> > and accomplishment - everyone say thank you to Allison), the code
> was
> > changed to report the error so it could be traced. Now the
> clincher.
> The
> > error only occurs when a value that is too large for the short
> binary is
> > used. In other words, this is a valid error message. This bug is
> being
> > rejected.
> >
>
> Yeah, I reported this problem to C/S sydney on 14 Aug and was
> informed
> that Ottawa (two, YES two staff) confirmed that it was a suspected
> bug
> since it was working perfectly in 710E4 (Bob, 710E4 is our current
> production version and it is not a problem on this version). Despite
>
> my cry for help and finally having to resort to hotsite status
> pursuit, no detailed investigation into this problem was being
> conducted by Cognos and no sound technical explaination was given on
>
> the nature of the problem that would help us and give us the
> confidence. I reached my own finding yesterday which was then pasted
>
> on to you last night.
>
> Bug 245681 - Linking a LONG to a SHORT causing Data Conversion
> Error.
> The problem will occur when -
>
> linking X (LONG) to Y (SHORT).
> where X is greater than 32767 (ie, 2^15 -1) since SHORT in
> Interbase
> is 2-byte signed in PH.
>
> The error did not occur in 710E4, 710F1.
> It surfaced in 710F2, 710F4, 710G (710F3 not tested).
>
> I should not have to do all these work on my own in the dark. You
> guys
> have the C-code behind PH.
>
> Rejected? What about the issue of upward compatibility for released
> software???
>
> Bob, answer to your first reply on this subject. It was the ordeal
> of
> being kept in the dark working on the problem on your own, along
> with
> the list of known bugs and who know what else that prevented our
> management from giving the green light to upgarde to 710G. Also
> because of OCC deadline for us to be Y2K compliant by end Oct 1998,
> we
> need Plan B which requires a known working version for us. We cannot
>
> rely on that 710G1 will be a working version for us after having
> relied on 710G. We are currently on 710E4.
>
> Suggestion - C/S Asia Pacific needs more than just 1.5 staff!!
>
> Regards,
> A Ling.
>
> _________________________________________________________
> DO YOU YAHOO!?
> Get your free @yahoo.com address at http://mail.yahoo.com
>
> = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = =
> = = = =
> Subscribe: "subscribe powerh-l" in message body to
> majordomo@lists.swau.edu
> Unsubscribe: "unsubscribe powerh-l" in message to
> majordomo@lists.swau.edu
> powerh-l@lists.swau.edu is gatewayed one-way to
> bit.listserv.powerh-l
> This list is closed, thus to post to the list, you must be a
> subscriber.
>
>
>
= = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = =
Subscribe: "subscribe powerh-l" in message body to majordomo@lists.swau.edu
Unsubscribe: "unsubscribe powerh-l" in message to majordomo@lists.swau.edu
powerh-l@lists.swau.edu is gatewayed one-way to bit.listserv.powerh-l
This list is closed, thus to post to the list, you must be a subscriber.