In 894315.74051...@web54604.mail.re2.yahoo.com, on 01/09/2010
at 12:49 PM, Ed Gould ps2...@yahoo.com said:
Either that or they are afraid that other clients will find out and it
will cause a mass migration.
Well, if I found out that a vendor had sued for dropping him, I would
never risk
From: Elardus Engelbrecht elardus.engelbre...@sita.co.za
To: IBM-MAIN@bama.ua.edu
Sent: Fri, January 8, 2010 6:49:52 AM
Subject: Re: Heads Up: Possible Data Loss for Temporary Data Sets starting 2010
Ed Gould wrote:
The salesman called me and very nastily said we
Imagine if Amadeus had gone down on the 1st rather than Sunday ;-)
Wouldn't *that* have drawn some heat.
Shane ...
The BoQ one was the first I saw. That quacks like a Y2K-type problem
despite a claim to the contrary.
Ed Gould wrote:
The salesman called me and very nastily said we will sue. I said go ahead
and here is our lawyers name phone number.
They want to *sue* just because you dropped their product?
These vendors are desperately crazy!
I have no idea if the vendor is around anymore and I could
Maybe sue-icidal. :-)
Cheers, Martin
Martin Packer
Performance Consultant, IBM
+44-7802-245-584
email: martin_pac...@uk.ibm.com
Twitter / Facebook IDs: MartinPacker
Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number
741598.
Elardus Engelbrecht wrote:
[snip]
Now, if I could get at least some common basic *service* from vendors to
start with, but that is another gory topic for other rainy day...
Why not now? It's Friday. So you can't get common basic *service* from
any of your vendors? Then why not raise
Steve Comstock wrote:
Why not now? It's Friday. So you can't get common basic *service* from
any of your vendors? Then why not raise issues to management, spell out the
problems, change vendors? Are all your vendors reluctant to provide service?
What exactly is wrong? Can it be fixed? Are there
During the early 90's I was with two diffiferent software companies. I
saw the same leap year problem at both. It was widely reported at other
companies.
What was amazing was that the problem recurred in 92, 94 and 96 because of
1) bad zaps 2) zaps that were sourced wrong or not at all 3)
Elardus Engelbrecht wrote:
Steve Comstock wrote:
Why not now? It's Friday. So you can't get common basic *service* from
any of your vendors? Then why not raise issues to management, spell out the
problems, change vendors? Are all your vendors reluctant to provide service?
What exactly is
Steve Comstock wrote:
So, maybe, it's not as bad as you first intimated, eh? I don't see a
consistent, current problem of not getting common basic *service*
from your current vendors out of the discussion above.
Thanks for reminding me, I forgot to add this *current* and *consistent*
service
During the early 90's I was with two diffiferent software companies. I
saw the same leap year problem at both. It was widely reported at other
companies.
What was amazing was that the problem recurred in 92, 94 and 96 because
of
1) bad zaps 2) zaps that were sourced wrong or not at all 3) new
On Fri, 8 Jan 2010 09:38:28 -0500, Kirk Talman wrote:
During the early 90's I was with two diffiferent software companies. I
saw the same leap year problem at both. It was widely reported at other
companies.
What was amazing was that the problem recurred in 92, 94 and 96 because of
...
No,
The error was only dividing the last digit of the year by 4 to determine
if it was a leap year. I.e. 92 is divisible by 4 but 2 is not.
Paul Gilmartin wrote:
On Fri, 8 Jan 2010 09:38:28 -0500, Kirk Talman wrote:
During the early 90's I was with two diffiferent software companies.
No,
The error was only dividing the last digit of the year by 4 to determine
if it was a leap year. I.e. 92 is divisible by 4 but 2 is not.
There must be plenty of ways of going wrong.
However, the ones I recall were taking a two or four digit BCD year number,
and testing if it was divisible
A friend pointed out the following document which points out a data loss
scenario for sites which have chosen an interesting serialization
architecture for their systems.
http://www-01.ibm.com/support/docview.wss?uid=isg3T1012005
This document describes situations where it is possible to have
@bama.ua.edu
Subject: Heads Up: Possible Data Loss for Temporary Data Sets starting
2010
A friend pointed out the following document which points out a data loss
scenario for sites which have chosen an interesting serialization
architecture for their systems.
http://www-01.ibm.com/support/docview.wss?uid
A variant of what some people have been calling Y2.01K?
I have seen reports of systems that think that this year is 2016 instead of
2010. There was some speculation (mostly uninformed) that this might be due
to confusion between binary and BCD year numbers (or year offsets).
That reminds me
From: Jousma, David david.jou...@53.com
To: IBM-MAIN@bama.ua.edu
Sent: Thu, January 7, 2010 2:14:01 PM
Subject: Re: Heads Up: Possible Data Loss for Temporary Data Sets starting 2010
Similar problem if you have TSS based security. No data loss, but many
jobs
On Thu, 2010-01-07 at 17:55 -0600, Andy Wood wrote:
A variant of what some people have been calling Y2.01K?
I have seen reports of systems that think that this year is 2016 instead of
2010.
Like this you mean ???.
A variant of what some people have been calling Y2.01K?
I have seen reports of systems that think that this year is 2016 instead of
2010.
Like this you mean ???.
http://www.theaustralian.com.au/australian-it/eftpos-glitch-not-y2k-
bug/story-e6frgakx-1225816534313
Haven't found an English
. . .
A variant of what some people have been calling Y2.01K?
I have seen reports of systems that think that this year is 2016 instead of
2010.
Like this you mean ???.
http://www.theaustralian.com.au/australian-it/eftpos-glitch-not-y2k-
bug/story-e6frgakx-1225816534313
The BoQ one was the
21 matches
Mail list logo
