Heads Up: Possible Data Loss for Temporary Data Sets starting 2010
Brian Peterson
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 in-use
temporary data sets deleted by DFHSM during normal space management
operations. The environments exposed to this are those that for example may
have tried to exclude certain SYS1 data sets from serialization for various
[editorial] perverse [/editorial] reasons.
Normal customers, with normal serialization environments, are not exposed.
If you have an unusual or complex serialization environment, where, for
example, you are trying to exclude SYS1 data sets from serialization, you
are potentially exposed to the issue described by the link. This is
because, last year, temporary data sets were named SYS09365 as their HLQ,
but today are SYS10007 for example. If one were to have a mask of SYS1* to
exclude data sets like SYS1.LINKLIB from serialization, then last year the
serialization would still apply to temporary data sets, but this year would
not protect temporary data sets from deletion.
Of course, the linked document describes the issue in much greater detail,
along with suggested solutions/workarounds. The linked document does not
say what I WILL say - that it is my belief that unusual or complex
serialization environments are generally ill-advised.
Brian
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to list...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
Jousma, David
jobs abending due to no access. CA provided both a PTF, and a sample
PERMIT statement to get around the problem.
_________________________________________________________________
Dave Jousma
Assistant Vice President, Mainframe Services
david....@53.com
1830 East Paris, Grand Rapids, MI 49546 MD RSCB1G
p 616.653.8429
f 616.653.8497
http://www-01.ibm.com/support/docview.wss?uid=isg3T1012005
Brian
This e-mail transmission contains information that is confidential and may be privileged. It is intended only for the addressee(s) named above. If you receive this e-mail in error, please do not read, copy or disseminate it in any manner. If you are not the intended recipient, any disclosure, copying, distribution or use of the contents of this information is prohibited. Please reply to the message immediately by informing the sender that the message was misdirected. After replying, please erase it from your computer system. Your assistance in correcting this error is appreciated.
Andy Wood
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 of a problem I saw in 1990, in several programs, where leap
year logic went wrong due to testing the year number for divisibility by four as
if it was a binary number, when it was, in fact, BCD. The one thing that the
failing programs had in common was that they were all written in the 1980s.
1980 happened to be a leap year, and the faulty logic got the right answer all
the way up to 1989 (Y1.99K, if you like).
That same faulty logic would again get the right answer from 2000 to 2009, so
what I wonder now is whether 2010 might bring deja vu all over again, for
some programs written after 2000.
Ed Gould
From: "Jousma, David" <David....@53.COM>
To: IBM-...@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 abending due to no access. CA provided both a PTF, and a sample
PERMIT statement to get around the problem.
David:
We had a similar situation but different, this went back 15 years ago. We had vendor X creating permanent data sets but with temporary names.
eg sys95xxxxxxx.xxxxxx etc. For all intense purposes anybody would have thought (and we did) thought these were really temporary datasets.
We would find them all over the place ie pre SMS and just not on public volumes, you name it we found them there.
I had to run through SMF to figure out who was creating them and ordinarily the jobname would be in those type os data sets but there was a bogus jobname in there. After looking through SMF we thought we had found the culprit but before calling the vendor up I want to make sure. I ended up running a GTF trace on SVC 99 and seeing who was really doing it. I did this as a caution as I wanted to be able to say without argument that the vendor was creating these data sets. I opened up an incident with the vendor and the next day I got a call back asking what the issue was. I gave them a detailed description and offered to send them the proof. The guy at the other end categorically denied the product did such a thing.
I packaged up the printouts and sent it off about a week later I got a phone call and it was hostile to say the least. It got down to if you ever repeat this in public we will sue. I went to my boss and he shrugged it off and told me to look around for another package. It wasn't easy but I did find one and when the product came up for renewal we dropped it. The salesman called me and very nastily said we will sue. I said go ahead and here is our lawyers name & phone number.
I have no idea if the vendor is around anymore and I could care less. The vendors lying and threatening was all posture and trying to make us the customer back down. Needless to say we stayed away from that vendors software from then on.
Ed
Shane
> 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
Shane ...
Barbara Nitz
>> 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 language link, but the EMV chip on new cards is
apparently responsible for a quarter of all German card holders being unable
to 'identify themselves' to banking terminals. Since January 1st, 2010. It is
being blamed on a 'third party programming error' in the chip.
Barbara Nitz
Andy Wood
>> 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 first I saw. That quacks like a Y2K-type problem despite
a claim to the contrary. Then I saw the one involving German bank cards, but
there are some others like one for SMS messages on Windows Mobile - I think
that was where I saw some talk about possible BCD confusion. At this time, if
you simply Google "Y2.01K" you will get a lot of hits.
I haven't seen any suggestion that any mainframe software is involved, but it
certainly jogged my memory of Y1.99K problems that I encountered.
Shane Ginnane
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.
----------------------------------------------------------------------
Bernd Oppolzer
It seems as if the BCD representation of the year 2010 is unterstood
by the card logic as 2016, and so the card is treated as not valid any
more,
but this is only a wild guess.
The repair steps discussed are the following, as far as I read it:
1. patch the ATM machines to not use the chip but the mag stripe
2. try to patch the ATM machines so that they in turn patch the
software on the chip (can this work? what about security issues?)
3. last resort: change the cards
This is in part speculation on my part, because I have only access
to german newspapers and web sites. I have no insights in the
banking IT sector.
Kind regards
Bernd
Barbara Nitz schrieb:
Sebastian
http://catless.ncl.ac.uk/Risks/25.89.html#subj1
Reports on the radio suggest putting sticky tape over the chip so that
the magnetic stripe gets read instead but to do this only in shops and
not ATMs as this will 'eat' your card.
Seb
Elardus Engelbrecht
>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 care less.
Good that you survived them. These unnamed vendors are probably bored or
clueless... :-D
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...
Groete / Greetings
Elardus Engelbrecht
Martin Packer
Cheers, Martin
Martin Packer
Performance Consultant, IBM
email: martin...@uk.ibm.com
Twitter / Facebook IDs: MartinPacker
Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number
741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
Donald Johnson
having a dense period today, but could someone give me an example of how
logic could see 2010 as 2016?
Thanks!
Don
On Fri, Jan 8, 2010 at 5:00 AM, Bernd Oppolzer
<bernd.o...@t-online.de>wrote:
> This is true. 30 million cards have the chip with the logic error on it.
> It seems as if the BCD representation of the year 2010 is unterstood
> by the card logic as 2016, and so the card is treated as not valid any
> more,
> but this is only a wild guess.
>
----------------------------------------------------------------------
Chuck Arney
> just
> having a dense period today, but could someone give me an example of
how
> logic could see 2010 as 2016?
I don't know anything about the actual problem from the description but
my guess is it takes the "YY" value as hex instead of decimal. Years
0-9 would work fine until it gets to 10 instead of 0A causing a jump
from 2009 to 2016.
Chuck Arney
illustro Systems International, LLC
http://www.illustro.com
Internet-enable your applications with z/Ware V2
Voice: 214-800-8900 X#5562
--
This e-mail is private and may be confidential and is for the intended
recipient only. If misdirected, please notify us by telephone and
confirm that it has been deleted from your system and any copies
destroyed. If you are not the intended recipient you are strictly
prohibited from using, printing, copying, distributing or disseminating
this e-mail or any information contained in it.
We use reasonable measures to virus scan all E-mails leaving illustro
but no warranty is given that this E-mail and any attachments are virus
free. You should ensure you have adequate measures in place for your own
virus checking.
> -----Original Message-----
> From: IBM Mainframe Discussion List [mailto:IBM-...@bama.ua.edu] On
> Behalf Of Donald Johnson
> Sent: Friday, January 08, 2010 7:15 AM
> To: IBM-...@bama.ua.edu
> Subject: Re: y2k10 problem with credit cards in Germany
>
> I'm not sure I follow how the BCD coding could cause this...maybe I am
> just
> having a dense period today, but could someone give me an example of
how
> logic could see 2010 as 2016?
>
> Thanks!
> Don
>
----------------------------------------------------------------------
Donald Johnson
remember in doing the Y2K conversion, we changed all years from YY to CCYY,
and made sure the logic dealt with the whole year and not just the last 2. I
guess not everyone did it the same way.
Thanks, Chuck!
Don
John P. Baker
(formerly EC-card) and German cash machines. The problem was caused by a
certain type of chip used in production of the cards which contained a
software error in the processing of the year 2010. The problem is being
fixed by reconfiguring ATMs and point of sale terminals to work around this
software error in the cards.
John P. Baker
-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-...@bama.ua.edu] On Behalf
Of Bernd Oppolzer
Sent: Friday, January 08, 2010 5:01 AM
To: IBM-...@bama.ua.edu
Subject: y2k10 problem with credit cards in Germany
This is true. 30 million cards have the chip with the logic error on it.
It seems as if the BCD representation of the year 2010 is unterstood
by the card logic as 2016, and so the card is treated as not valid any
more,
but this is only a wild guess.
The repair steps discussed are the following, as far as I read it:
1. patch the ATM machines to not use the chip but the mag stripe
2. try to patch the ATM machines so that they in turn patch the
software on the chip (can this work? what about security issues?)
3. last resort: change the cards
This is in part speculation on my part, because I have only access
to german newspapers and web sites. I have no insights in the
banking IT sector.
Kind regards
Bernd
----------------------------------------------------------------------
john gilmore
http://www.zeit.de/wirtschaft/2010-01/ec-karten-entschaedigung
John Gilmore Ashland, MA 01721-1817 USA
_________________________________________________________________
Hotmail: Trusted email with powerful SPAM protection.
http://clk.atdmt.com/GBL/go/196390707/direct/01/
Bernd Oppolzer
and when comparing, you ignore the first two digits completely
and compare only the last two digits (which is valid until 99).
But the ill-fated programmer thougth the byte contained the
last two digits of the year in binary, but in fact it was BCD
(which is the same from 00 to 09, but 10 is different from 0a).
Kind regards
Bernd
Donald Johnson schrieb:
Steve Comstock
[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 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 issues of
fraud, kickbacks, nepotism? All of these can be addressed if the issue
is important enough.
--
Kind regards,
-Steve Comstock
The Trainer's Friend, Inc.
303-393-8716
http://www.trainersfriend.com
z/OS Application development made easier
* Our classes include
+ How things work
+ Programming examples with realistic applications
+ Starter / skeleton code
+ Complete working programs
+ Useful utilities and subroutines
+ Tips and techniques
==> Ask about being added to our opt-in list: <==
==> * Early announcement of new courses <==
==> * Early announcement of new techincal papers <==
==> * Early announcement of new promotions <==
Bernd Oppolzer
terminals have been
reconfigured, only most of. And this can be done, AFAIK, only inside
Germany, but
due to legal issues, not in other european countries, and german people,
passing their
holidays there at the moment (skiing for example), cannot pay their
bills using their cards.
So the replacement of many or all of the cards is still in the
discussion, but: this would
lead to costs of 250 to 300 million euros. Even if it will not be
necessary in the end,
this has without doubt a serious impact on the banking business in
Germany (sorry,
if my english sounds kind of silly sometimes - I hope you understand
what I am trying
to say).
Kind regards
Bernd
John P. Baker schrieb:
> The ZKA have announced that the problem has been resolved with all Girocards
> (formerly EC-card) and German cash machines. The problem was caused by a
> certain type of chip used in production of the cards which contained a
> software error in the processing of the year 2010. The problem is being
> fixed by reconfiguring ATMs and point of sale terminals to work around this
> software error in the cards.
>
> John P. Baker
>
>
----------------------------------------------------------------------
Elardus Engelbrecht
>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 issues of fraud, kickbacks,
nepotism? All of these can be addressed if the issue is important enough.
Good question:
(All vendors will remain nameless. No offline queries please.)
1. One of the vendors decided not to continue to have a reseller in our
country. Too expensive for them. When we said we will drop their product
because we need absolutely 24 hours service from them (WE must deliver 24
hours service to our customers), they just shrugged their shoulders.
So we dropped them ice-cold upon end of contract. That was many moons
ago.
2. Some vendors are somewhat expensive. They want priced fixed on Dollars
which resulted in too expensive for us in Rand. I don't blame them, it is just
their overseas HQ who can't see our exchange rate dillema... Also it was many
moons ago.
3. One training company (now out of service ;-D ), just couldn't always
provide full training schedules and fees when we requested it for our planning.
I'm not aware of any cheats, frauds, kickback, nepotism, etc. Today, all our
vendors are behaving professionally and friendly without any problems at all.
It is just one of my personal pet peeves... ;-D
Now let us hear from YOUR pet peeves about vendors... ;-D
Groete / Greetings
Elardus Engelbrecht
----------------------------------------------------------------------
Kirk Talman
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 code with
the same old errors. It got to the point, it was funny if tragic.
There are no new bugs. The old ones live forever with new clothes and/or
bodies.
IBM Mainframe Discussion List <IBM-...@bama.ua.edu> wrote on 01/07/2010
06:55:06 PM:
> 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 of a problem I saw in 1990, in several programs, where
leap
> year logic went wrong due to testing the year number for
> divisibility by four as
> if it was a binary number, when it was, in fact, BCD. The one thing that
the
> failing programs had in common was that they were all written in the
1980s.
> 1980 happened to be a leap year, and the faulty logic got the right
> answer all
> the way up to 1989 (Y1.99K, if you like).
>
> That same faulty logic would again get the right answer from 2000
to2009, so
> what I wonder now is whether 2010 might bring deja vu all over again,
for
> some programs written after 2000.
-----------------------------------------
The information contained in this communication (including any
attachments hereto) is confidential and is intended solely for the
personal and confidential use of the individual or entity to whom
it is addressed. If the reader of this message is not the intended
recipient or an agent responsible for delivering it to the intended
recipient, you are hereby notified that you have received this
communication in error and that any review, dissemination, copying,
or unauthorized use of this information, or the taking of any
action in reliance on the contents of this information is strictly
prohibited. If you have received this communication in error,
please notify us immediately by e-mail, and delete the original
message. Thank you
McKown, John
> From: IBM Mainframe Discussion List
> Sent: Friday, January 08, 2010 7:15 AM
> To: IBM-...@bama.ua.edu
>
> I'm not sure I follow how the BCD coding could cause
> this...maybe I am just
> having a dense period today, but could someone give me an
> example of how
> logic could see 2010 as 2016?
>
> Thanks!
> Don
pure binary date of 2009 is 0x07d9, bcd is 0x2009. Pure binary of 2010 is 0x7da, bcd is 0x2010. Now, if the card only stored the last 2 digits of the year, 2009 is 0x09 in both binary and bcd. 2010 is 0x0a in binary and 0x10 in BCD. So if the encoding is in BCD, but the instructions in the code are binary, then 0x10 is 16. 00-09 map to the same bit values regardless, so 2000-2009 worked fine.
--
John McKown
Systems Engineer IV
IT
Administrative Services Group
HealthMarkets(r)
9151 Boulevard 26 * N. Richland Hills * TX 76010
(817) 255-3225 phone * (817)-961-6183 cell
john....@healthmarkets.com * www.HealthMarkets.com
Confidentiality Notice: This e-mail message may contain confidential or proprietary information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. HealthMarkets(r) is the brand name for products underwritten and issued by the insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance Company(r), Mid-West National Life Insurance Company of TennesseeSM and The MEGA Life and Health Insurance Company.SM
Steve Comstock
> 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 issues of fraud, kickbacks,
> nepotism? All of these can be addressed if the issue is important enough.
>
> Good question:
>
> (All vendors will remain nameless. No offline queries please.)
>
> 1. One of the vendors decided not to continue to have a reseller in our
> country. Too expensive for them. When we said we will drop their product
> because we need absolutely 24 hours service from them (WE must deliver 24
> hours service to our customers), they just shrugged their shoulders.
>
> So we dropped them ice-cold upon end of contract. That was many moons
> ago.
So, no problems from them today.
>
> 2. Some vendors are somewhat expensive. They want priced fixed on Dollars
> which resulted in too expensive for us in Rand. I don't blame them, it is just
> their overseas HQ who can't see our exchange rate dillema... Also it was many
> moons ago.
So, no problems from them today.
Pricing is always an issue. Today everyone seems to be focused
solely on price, ignoring issues such as quality, flexibility,
appropriateness, best fit, and so on.
>
> 3. One training company (now out of service ;-D ), just couldn't always
> provide full training schedules and fees when we requested it for our planning.
Ah, but you have alternatives. Ahem.
We've been doing training since 1975, one of the longest running
training vendors in the mainframe business in the world. We're
happy to teach just about anywhere in the world. We've taught in
Ireland, Kuwait, Denmark, Singapore, Sweden, Canada, Belgium,
the Netherlands and Finland. We've done related work in Japan
and England. I've even been to South Africa once (actually
talking with folks in IBM and the old ASI affiliate back then).
>
> I'm not aware of any cheats, frauds, kickback, nepotism, etc. Today, all our
> vendors are behaving professionally and friendly without any problems at all.
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.
>
> It is just one of my personal pet peeves... ;-D
>
> Now let us hear from YOUR pet peeves about vendors... ;-D
>
> Groete / Greetings
> Elardus Engelbrecht
--
Kind regards,
-Steve Comstock
The Trainer's Friend, Inc.
303-393-8716
http://www.trainersfriend.com
z/OS Application development made easier
* Our classes include
+ How things work
+ Programming examples with realistic applications
+ Starter / skeleton code
+ Complete working programs
+ Useful utilities and subroutines
+ Tips and techniques
==> Ask about being added to our opt-in list: <==
==> * Early announcement of new courses <==
==> * Early announcement of new techincal papers <==
==> * Early announcement of new promotions <==
----------------------------------------------------------------------
Chase, John
> From: IBM Mainframe Discussion List On Behalf Of Donald Johnson
>
> I'm not sure I follow how the BCD coding could cause this...maybe I am
just
> having a dense period today, but could someone give me an example of
how
> logic could see 2010 as 2016?
If the year value without century was stored as "unsigned packed
decimal" (i.e., without the sign nibble), it could be represented in a
single byte. If a subsequent "reader" of that byte "assumes" it is a
hex value, conversion to decimal of x'10' results in a value of 16
(x'016C' as packed decimal).
Example:
YPACK DC P'10' <== x'010C'
YBYTE DC X'00' <== X'00'
...
Label ICM Ra,B'0011',YPACK
SRL Ra,4 remove sign nibble
STC Ra,YBYTE YBYTE <- X'10'
Why would someone want to do that? Well, if there are a billion
records, a billion bytes of storage need not be allocated or used.
Saves nearly a whole dime at today's prices (depending on platform, of
course). :-)
-jc-
Paul Gilmartin
>The ZKA have announced that the problem has been resolved with all Girocards
>(formerly EC-card) and German cash machines. The problem was caused by a
>certain type of chip used in production of the cards which contained a
>software error in the processing of the year 2010. The problem is being
>fixed by reconfiguring ATMs and point of sale terminals to work around this
>software error in the cards.
>
"Work around". So if the chip says "2016", the ATM will assume it means
"2010". What happens 6 years from now? Aren't workarounds fun?
-- gil
John P. Baker
Personally, I think that any "work around" is absurd.
Somebody really screwed up, and a lot of people are being inconvenienced.
What I am afraid of is exactly the kind of scenario you suggested.
A sloppy work-around that results in another problem several years down the
road.
John P. Baker
-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-...@bama.ua.edu] On Behalf
Of Paul Gilmartin
Sent: Friday, January 08, 2010 10:49 AM
To: IBM-...@bama.ua.edu
Subject: Re: y2k10 problem with credit cards in Germany
Ray Pearce
reading the mag-strip rather than using the chip. I guess this is just a
quick fix while they bite the bullet and re-issue 30 million cards.
Ray
> -----Original Message-----
> From: IBM Mainframe Discussion List
> [mailto:IBM-...@bama.ua.edu] On Behalf Of Paul Gilmartin
> Sent: 08 January 2010 15:49
> To: IBM-...@bama.ua.edu
> Subject: Re: y2k10 problem with credit cards in Germany
>
> -
> --------------------------------------------------------------
> ----------
> This email has been scanned for all known viruses by the
> MessageLabs Email Security Service and the Macro 4 internal
> virus protection system.
> .
> --------------------------------------------------------------
> ----------
>
- ------------------------------------------------------------------------
This email has been scanned for all known viruses by the MessageLabs Email
Security Service and the Macro 4 internal virus protection system.
. ------------------------------------------------------------------------
Anne & Lynn Wheeler
> It would appear that the "workaround" is to get the ATM's to revert to
> reading the mag-strip rather than using the chip. I guess this is just a
> quick fix while they bite the bullet and re-issue 30 million cards.
i got a tour of large card personalization operation ... that had big
banner that on some date they managed to turn out 500,000+ cards in 24hr
period (this was purely magstipe, chip personalization takes more
processing). that should give some order of magnitude on elapsed time it
would take to personalize 30million chipcards.
--
40+yrs virtualization experience (since Jan68), online at home since Mar1970
Elardus Engelbrecht
>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 problem we're currently experiencing. I wanted to add that, but got
distracted by other more urgent work... ( I must do my work, you see... ;-D )
To be fair to that vendor, things are now going fine these days fortunately,
but we're monitoring this.
That vendor wrote some custom application on one of our database systems.
Unfortunately it was somewhat buggy resulting into outage and
incompatibilities. We have some trouble to communicate to them via e-mails
and to get them to fix their software. There are other problems too, but I will
not discuss them here.
Eventually it boils down to skills shortage and lack of commitment on their part.
Most of the times I'm very happy to work with vendors, because we (and
other datacentres) are the reason for their existance.
Groete / Greetings
Elardus Engelbrecht
----------------------------------------------------------------------
Bernd Oppolzer
John P. Baker schrieb:
Norbert Friemel
>the work around is: don't use the chip - use the magnetic stripe instead !
>
The "sticky tape patch" ;-)
http://www.h-online.com/security/news/item/EC-card-disaster-French-manufacturer-Gemalto-takes-responsibility-897991.html
Norbert Friemel
Tony Harminc
> It would appear that the "workaround" is to get the ATM's to revert to
> reading the mag-strip rather than using the chip. I guess this is just a
> quick fix while they bite the bullet and re-issue 30 million cards.
You can bet those Russian phishing networks are gearing up to exploit
this as we speak. What an unexpected windfall for them; they doubtless
have zillions of PINs they collected over the years from various
phishing scams, skimmers, etc. that they haven't been able to use in
Europe because of the chip cards. They have to use them in North
America or other countries where magstripe is still in common use, but
where transactions on European cards are very much rarer, and so more
likely to be flagged as out of line. Now for a while at least they can
use fake German cards in Germany.
Tony H.
Paul Gilmartin
>the work around is: don't use the chip - use the magnetic stripe instead !
>
Why is the chip there? Does it do nothing but add cost?
-- gil
Anne & Lynn Wheeler
car...@ILLUSTRO.COM (Chuck Arney) writes:
> I don't know anything about the actual problem from the description but
> my guess is it takes the "YY" value as hex instead of decimal. Years
> 0-9 would work fine until it gets to 10 instead of 0A causing a jump
> from 2009 to 2016.
similar ... but different ... in a decade-old y2k post
http://www.garlic.com/~lynn/99.html#24 BA Solves Y2K (Was: Re: Chinese Solve Y2K)
i included a much earlier post (from somebody working in Houston
... also mentioned PARs problem and shuttle problem)
http://www.garlic.com/~lynn/99.html#email841207
from 1984 in an internal discussion group (on the corporate internal
network) about the looming y2k problems. Above '84 post includes
description of 1970 problem when some calculations rolled over 1969 to
196A.
misc. past posts mentioning internal network (larger than the
arpanet/internet from just about the beginning until late '85
or possibly earlay '86).
a few other references to the 84 post:
http://www.garlic.com/~lynn/2000.html#94 Those who do not learn from history...
http://www.garlic.com/~lynn/2003p.html#21 Sun researchers: Computers do bad math ;)
http://www.garlic.com/~lynn/2006r.html#16 Was FORTRAN buggy?
http://www.garlic.com/~lynn/2006u.html#14 Year-end computer bug could ground Shuttle
http://www.garlic.com/~lynn/2006u.html#35 Friday fun - Discovery on the pad and the software's not done
http://www.garlic.com/~lynn/2009.html#16 Date arithmetic and Zune bug
http://www.garlic.com/~lynn/2009f.html#60 Cobol hits 50 and keeps counting
http://www.garlic.com/~lynn/2009i.html#27 My Vintage Dream PC
http://www.garlic.com/~lynn/2009n.html#53 Long parms...again
Donald Johnson
feel better that we took the plunge in a former life to change all YY
calculations to CCYY back for Y2K. More storage, yes, but the cost over the
past 10 years was probably still less than what this faux pas is costing
today!
Don
On Fri, Jan 8, 2010 at 9:44 AM, McKown, John
<John....@healthmarkets.com>wrote:
> john....@healthmarkets.com * www.HealthMarkets.com<http://www.healthmarkets.com/>
Robert A. Rosenberg
problem with credit cards in Germany:
>On Fri, 8 Jan 2010 08:32:45 -0500, John P. Baker wrote:
>
>>The ZKA have announced that the problem has been resolved with all Girocards
>>(formerly EC-card) and German cash machines. The problem was caused by a
>>certain type of chip used in production of the cards which contained a
>>software error in the processing of the year 2010. The problem is being
>>fixed by reconfiguring ATMs and point of sale terminals to work around this
>>software error in the cards.
>>
>"Work around". So if the chip says "2016", the ATM will assume it means
>"2010". What happens 6 years from now? Aren't workarounds fun?
Not an issue. The cards have a life of 2-4 years. Thus a card with a
real expiration date of 2016 will not get issued until at least 2012.
Thus any card that CURRENTLY reports as 2016 is really saying 2010.
Code the workaround to assume that 2016=2010 during 2010 and 2011 and
drop the fix as of 2012.
I may have what date is being reported incorrect but in any case
there will not be a time window where both versions of 2016 can be
valid so you can turn off the 2016=2010 fix before 2016=2016 becomes
valid.
This is basically the same windowed sanity check as was used for
2-digit years during the Y2K correction crisis (ie: 00-29 = 20xx
while 30-99 = 19xx).
Charles Mills
not cards out there today with expiration dates of 2010 through 2013 (or at
least 2012). By the same logic error, will not 2011 get interpreted as 2017,
and so forth?
But isn't the problem being described backwards? Is the external symptom
expired cards not being recognized as expired, or is it valid cards being
treated as though expired? Assuming the latter, the problem would seem to be
not that an expiration date is being misinterpreted but rather that today's
date is being misinterpreted. The card "knows" it expires in 2010 but
"thinks" today's date is 8 January 2016. If so, you can't "fix" the machines
(other than to provide the mag stripe workaround), you have to "fix" the
cards by reprogramming or reissuing them. There's no "window" solution
possible; the only solution is fixing the chips. Am I wrong?
Charles
-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-...@bama.ua.edu] On Behalf
Of Robert A. Rosenberg
Sent: Friday, January 08, 2010 10:30 AM
To: IBM-...@bama.ua.edu
Subject: Re: y2k10 problem with credit cards in Germany
At 09:48 -0600 on 01/08/2010, Paul Gilmartin wrote about Re: y2k10
problem with credit cards in Germany:
>On Fri, 8 Jan 2010 08:32:45 -0500, John P. Baker wrote:
>
>>The ZKA have announced that the problem has been resolved with all
Girocards
>>(formerly EC-card) and German cash machines. The problem was caused by a
>>certain type of chip used in production of the cards which contained a
>>software error in the processing of the year 2010. The problem is being
>>fixed by reconfiguring ATMs and point of sale terminals to work around
this
>>software error in the cards.
>>
>"Work around". So if the chip says "2016", the ATM will assume it means
>"2010". What happens 6 years from now? Aren't workarounds fun?
Not an issue. The cards have a life of 2-4 years. Thus a card with a
real expiration date of 2016 will not get issued until at least 2012.
Thus any card that CURRENTLY reports as 2016 is really saying 2010.
Code the workaround to assume that 2016=2010 during 2010 and 2011 and
drop the fix as of 2012.
----------------------------------------------------------------------
Gibney, Dave
be a problem. And so on.
On the other hand, there may well be other information the chip
reports to the ATM that can be used to tell the difference between a
good new chip and a bad old chip.
Paul Gilmartin
>
>But isn't the problem being described backwards? Is the external symptom
>expired cards not being recognized as expired, or is it valid cards being
>treated as though expired? Assuming the latter, the problem would seem to be
>not that an expiration date is being misinterpreted but rather that today's
>date is being misinterpreted. The card "knows" it expires in 2010 but
>"thinks" today's date is 8 January 2016. If so, you can't "fix" the machines
>(other than to provide the mag stripe workaround), you have to "fix" the
>cards by reprogramming or reissuing them. There's no "window" solution
>possible; the only solution is fixing the chips. Am I wrong?
>
a battery to run it. So, the ATM supplies the date, x'2010'
to the card which misinterprets it as 2016 and reports itself
as expired.
-- gil
McKown, John
> From: IBM Mainframe Discussion List
> [mailto:IBM-...@bama.ua.edu] On Behalf Of Paul Gilmartin
> Sent: Friday, January 08, 2010 2:34 PM
> To: IBM-...@bama.ua.edu
> Subject: Re: y2k10 problem with credit cards in Germany
>
> >
> >But isn't the problem being described backwards? Is the
> external symptom
> >expired cards not being recognized as expired, or is it
> valid cards being
> >treated as though expired? Assuming the latter, the problem
> would seem to be
> >not that an expiration date is being misinterpreted but
> rather that today's
> >date is being misinterpreted. The card "knows" it expires in 2010 but
> >"thinks" today's date is 8 January 2016. If so, you can't
> "fix" the machines
> >(other than to provide the mag stripe workaround), you have
> to "fix" the
> >cards by reprogramming or reissuing them. There's no
> "window" solution
> >possible; the only solution is fixing the chips. Am I wrong?
> >
> It's unlikely that the cards contain a crystal clock and
> a battery to run it. So, the ATM supplies the date, x'2010'
> to the card which misinterprets it as 2016 and reports itself
> as expired.
>
> -- gil
Or, similarily, the card does no processing, just reports the expire date to the ATM as x'0A' (miscoded at the factory), and the ATM expects a BCD 0x'10'. 0x0A < 0x10, so the ATM thinks the card is expired.
--
John McKown
Systems Engineer IV
IT
Administrative Services Group
HealthMarkets(r)
9151 Boulevard 26 * N. Richland Hills * TX 76010
(817) 255-3225 phone * (817)-961-6183 cell
john....@healthmarkets.com * www.HealthMarkets.com
Confidentiality Notice: This e-mail message may contain confidential or proprietary information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. HealthMarkets(r) is the brand name for products underwritten and issued by the insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance Company(r), Mid-West National Life Insurance Company of TennesseeSM and The MEGA Life and Health Insurance Company.SM
----------------------------------------------------------------------
Andy Wood
>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 code with
>the same old errors. It got to the point, it was funny if tragic.
>
I certainly saw it happen in 1992, but the problem only showed up then rather
than 1990 for a different reason. In that system, incorrectly treating a non
leap year as a leap year (as in 1990) did not cause any noticeable trouble,
while incorrectly treating a leap year as a non leap year (1992) had very
visible symptoms.
From memory, that problem went a bit like this: Date of 31 December 1992
was presented to the system. One program correctly converted that to day
366 of 1992. It then passed that converted version of the date to another
program, the one with the bug, only to have it rejected since according to the
second program, there were only 365 days in 1992. Perhaps this bug did cause
some incorrect processing in 1990, but if it did, nobody noticed.
Charles Mills
x'10' and it interprets that as 2016 and says "I am expired." If that is
what is happening, no work-around other than replacing or re-programming the
cards seems apparent to me.
My point was that people seemed to be talking about the opposite situation
-- that the ATMs were interpreting whatever the card "said" as meaning 2016.
Charles
-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-...@bama.ua.edu] On Behalf
Of Paul Gilmartin
Sent: Friday, January 08, 2010 12:34 PM
To: IBM-...@bama.ua.edu
Subject: Re: y2k10 problem with credit cards in Germany
Paul Gilmartin
>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
>
... software that erroneously assumed that all years divisible
by 2 are leap years?
Jim Phoenix
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. 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
>>
>>
> ... software that erroneously assumed that all years divisible
> by 2 are leap years?
>
>
>
--
| Jim Phoenix | Voice: (310) 338-0400 x316 |
| Senior Software Developer | Fax: (310) 338-0801 |
| Phoenix Software International | Alt fax: (310) 337-2685 |
| 831 Parkview Drive North | jimph...@phoenixsoftware.com |
| El Segundo, CA 90245 | http://www.phoenixsoftware.com |
Opinions expressed by this individual are not necessarily those of the
Company.
Bernd Oppolzer
the current
date in BCD, and the card interprets it as 2016 and returns an error
code "expired"
to the ATM.
But recent news sound as if the truth is more complicated. The
communication between
the EMV chip and the ATM could be very sophisticated, involving lots of
messages in
both directions, and only some of these message types are affected by
this error. So
maybe there is a way to still use the authorization capabilities of the
chip, but only
using message types not affected by the error. Maybe the ATMs inside
germany
and the POS terminals can now be patched in such a way.
Another idea is: patching the faulty chips with spezialized ATMs. But it
seems as if
you need indeed spezialized ATMs, not only re-configured "normal" ATMs.
Falling back to the magnetic stripe is not as good, because, as others
have mentioned,
mag stripe cards can easily be copied (skimming).
Let's see what the next days will bring.
Kind regards
Bernd
(from Stuttgart, Germany)
Charles Mills schrieb:
> Right, that's what I meant. The card gets told that the current year is
> x'10' and it interprets that as 2016 and says "I am expired." If that is
> what is happening, no work-around other than replacing or re-programming the
> cards seems apparent to me.
>
> My point was that people seemed to be talking about the opposite situation
> -- that the ATMs were interpreting whatever the card "said" as meaning 2016.
>
> Charles
>
>
----------------------------------------------------------------------
Andy Wood
>
>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 by four as if it was a binary number. For example,
in assembler, using a TM instruction to check if the low order two bits were
both zero. By that method, or by actually doing a binary divide, X'1980' or
X'80' is correctly determined to be a leap year. It continues to work correctly
up to 1989 but since X'1990' or X'90' is divisible by four, 1990 is taken as a
leap. X'1992' or X'92' is not divisible by four, ergo 1992 is not a leap year ...
Robert A. Rosenberg
problem with credit cards in Germany:
>
>But recent news sound as if the truth is more complicated. The
>communication between the EMV chip and the ATM could be very
>sophisticated, involving lots of messages in both directions, and
>only some of these message types are affected by this error. So
>maybe there is a way to still use the authorization capabilities of
>the chip, but only using message types not affected by the error.
>Maybe the ATMs inside germany and the POS terminals can now be
>patched in such a way.
Since the error is occurring between the ATM and the Chip (but not
between the ATM and any other machine) just patch the ATM to send the
year as x'0a' not x'10' in those messages sent to the chip which have
a date in them. Since the chip is now getting a 'valid' date, it will
work correctly until the chips are fixed and replaced.
Robert A. Rosenberg
>But isn't the problem being described backwards? Is the external symptom
>expired cards not being recognized as expired, or is it valid cards being
>treated as though expired? Assuming the latter, the problem would seem to be
>not that an expiration date is being misinterpreted but rather that today's
>date is being misinterpreted. The card "knows" it expires in 2010 but
>"thinks" today's date is 8 January 2016. If so, you can't "fix" the machines
>(other than to provide the mag stripe workaround), you have to "fix" the
>cards by reprogramming or reissuing them. There's no "window" solution
>possible; the only solution is fixing the chips. Am I wrong?
Yes you are. The machines can be fixed to temporally send a year of
x'0A' in lieu of the x'10' which is being misinterpreted as 2016 (ie:
16 years into 20xx). The x'0a' would then be only 10 years.
Bernd Oppolzer
Maybe my brain refuses to take such ways of "correcting one error by
inserting another" into account.
Happy new year 200A to you all :-)
Robert A. Rosenberg schrieb:
Charles Mills
would make of x'0a' when they were expecting a BCD year. Apparently this is
just a problem with one "family" of cards -- the majority of cards in Europe
and the world are apparently okay. What will they "make" of x'0a' when they
are expecting a BCD year? I would hate to see the majority of cards going to
a S0C4 or blue screen of death or whatever the equivalent is for a
smart-card chip.
Charles
-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-...@bama.ua.edu] On Behalf
Of Robert A. Rosenberg
Joel C. Ewing
>> 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 by four as if it was a binary number. For example,
> in assembler, using a TM instruction to check if the low order two bits were
> both zero. By that method, or by actually doing a binary divide, X'1980' or
> X'80' is correctly determined to be a leap year. It continues to work correctly
> up to 1989 but since X'1990' or X'90' is divisible by four, 1990 is taken as a
> leap. X'1992' or X'92' is not divisible by four, ergo 1992 is not a leap year ...
>
The case I remember was IBM's SDSF. The intent obviously was an
overly-clever attempt to avoid the "overhead" of divides by using
multiple TM instructions to test bits in the BCD year, determining leap
year by looking for years 0, 4, 8 in even decades and years 2, 6 in odd
decades (an algorithm for leap year determination which would first fail
in 2100). The code was sufficiently obscure that a bug in the
implementation of the algorithm wasn't obvious until it reported 03/01
as 02/29 in a non leap year in the 1990s. I don't know if IBM resolved
this by just fixing the code to correctly implement the intended
algorithm, or whether they also corrected the algorithm to handle the
100/400 year exceptions. If the former, this may be an example of a
class of Y2100 leap-year problems that will surface in 2100 with the
crossing of the first yy00 boundary that is not a leap year since the
large-scale usage of digital computers.
Discussions on public Y2K forums a decade ago showed considerable
confusion over the 100/400 year leap-year exception rules. There were
some adamant claims by those who didn't understand the rules (even by
some technical types doing Y2K remediation!) that year 2000 would have
365, or even 367, days instead of the actual 366. This strongly
suggests that some minor leap-year problems will be seen in 2100, either
from code using an algorithm based on an incorrect understanding of the
rules, or from code that took a shortcut to just ignore the 100/400
exceptions under the assumption that no descendant of that code would be
running in 2100 when it next has an effect.
--
Joel C. Ewing, Fort Smith, AR jREMOVEc...@acm.org
Paul Gilmartin
>
>The case I remember was IBM's SDSF. The intent obviously was an
>overly-clever attempt to avoid the "overhead" of divides by using
>multiple TM instructions to test bits in the BCD year, determining leap
>year by looking for years 0, 4, 8 in even decades and years 2, 6 in odd
>decades (an algorithm for leap year determination which would first fail
>in 2100). The code was sufficiently obscure that a bug in the
>implementation of the algorithm wasn't obvious until it reported 03/01
>as 02/29 in a non leap year in the 1990s. I don't know if IBM resolved
>this by just fixing the code to correctly implement the intended
>algorithm, or whether they also corrected the algorithm to handle the
>100/400 year exceptions. If the former, this may be an example of a
>class of Y2100 leap-year problems that will surface in 2100 with the
>crossing of the first yy00 boundary that is not a leap year since the
>large-scale usage of digital computers.
>
instructions (and two branches). (Comments?) A third TM and branch
would handle the 400 year rule.
I wonder, however, whether the extra branches' interrupting the
pipeline more than offsets the overhead of the divide. (Divide?
I'd use a multiply and a TM.) CDC Cyber processors were notoriously
sensitive to pipeline interruptions, and their programmers similarly
notorious for avoiding branches, even by computing two results and
combining them with masks.
-- gil
Itschak Mugzach
cheaps to become inactive. Earlier last year it was with healthcare cards.
ITschak
On Sat, Jan 9, 2010 at 1:15 PM, Bernd Oppolzer
<bernd.o...@t-online.de>wrote:
Ted MacNEIL
Sort of.
Considering that the card is usable on many Financial Institutions in many counmtriess, how do you co-ordinate the changes to machines that don't belong to you, and don't even live at home?
-
Too busy driving to stop for gas!
Ed Gould
From: Elardus Engelbrecht <elardus.e...@SITA.CO.ZA>
To: IBM-...@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 will sue. I said go ahead
and here is our lawyers name & phone number.
They want to *sue* just because you dropped their product?
Yes in fact in the year since I have had another vendor say the same thing. My guess is that they think it will scare the client into renewing.
Either that or they are afraid that other clients will find out and it will cause a mass migration.
These vendors are desperately crazy!
>I have no idea if the vendor is around anymore and I could care less.
Good that you survived them. These unnamed vendors are probably bored or
clueless... :-D
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...
Groete / Greetings
Elardus Engelbrecht
I hear you on that. I have had 2 bad experiences just from Germany alone. One had to do with sending fixes out and expecting the user to hand re-link the lmod outside of SMPE's control. The other one was the typical how dare you question the software. The product about which I wrote the above item was American.
Ed
Joel C. Ewing
Wouldn't it take a fourth TM (or a CLI) to get the 100-year rule in as
well? Or is there a more subtle way than:
TM X'01',YY
BNZ NOT_LEAP Branch if odd
TM X'12',YY
BM NOT_LEAP Branch if 02, 06, 10, 14, 18
* Here if 00, 04, 08, 12, 16
CLI YY,X'00'
BNZ LEAP div by 4, not multiple of 100
TM X'03',CC
BNZ NOT_LEAP div by 100 but not 400
LEAP DS 0H
...
NOT_LEAP DS 0H
...
At least I think the above works... It isn't at all obvious without
checking through all the possible combinations.
--
Joel C. Ewing, Fort Smith, AR jREMOVEc...@acm.org
----------------------------------------------------------------------
Joel C. Ewing
requires the same sort of sensitivity to even/odd millenia as the tests
for even/odd decades in the checks for YY divisible by four. The logic
is so much more likely to be right if one sticks to the original
"divisible by" definition and avoids bit twiddding.
Paul Gilmartin
>>>>
>>> This ought to be feasible (correctly) for 1901 to 2099 with two TM
>>> instructions (and two branches). (Comments?) A third TM and branch
>>> would handle the 400 year rule.
>>>
>> well? Or is there a more subtle way than:
>>
>> TM X'01',YY
>> BNZ NOT_LEAP Branch if odd
>> TM X'12',YY
>> BM NOT_LEAP Branch if 02, 06, 10, 14, 18
>> * Here if 00, 04, 08, 12, 16
I stand corrected. We agree on the above except for century
years.
...
>Caught my own mistake. The test for CC divisible by four obviously
>requires the same sort of sensitivity to even/odd millenia as the tests
>for even/odd decades in the checks for YY divisible by four. The logic
>is so much more likely to be right if one sticks to the original
>"divisible by" definition and avoids bit twiddding.
>
The original definition was set up for bit twiddling (in decimal).
Otherwise, I did some trial and error. The tropical year is
astonishingly close to 365 31/128 days -- within a second! So
if a programmer had chosen the formula, it would be, years divisible
by 4 but not by 128 should be leap years; ideal for bit twiddling
(in binary).
-- gil
Joel C. Ewing
I believe it's even more remarkable than that. The existing leap year
rule will require another corrective extension well before it is
necessary to address the Y10K software problem. If one applied a
correction to the existing rule at the optimal point consistent with the
existing rules, one would add a counter-counter-exception on years that
are an exact multiple of 3200 making them not a leap year.
Mathematically a 4-year rule with an 128-year exception gives the same
average year length (31 leap-years per 128 years) as the 4-year rule
with 100-year exception with 400-year counter-exception, with a
3200-year counter-counter-exception (775 Leap years per 3200 years ==
31:128).
If the Pope and Luigi had only been astute enough to think in powers of
2 for all the corrective points, we could not only have had a much
simpler algorithm but one that would remain accurate well beyond the
year 10,000! I guess we should be thankful they didn't choose a much
less accurate corrective point of multiple of 500 years on the grounds
that 500 is simpler to express in Roman numerals than 400!
--
Joel C. Ewing, Fort Smith, AR jREMOVEc...@acm.org
----------------------------------------------------------------------
Shmuel Metz , Seymour J.
at 12:15 PM, Bernd Oppolzer <bernd.o...@T-ONLINE.DE> said:
>Happy new year 200A to you all :-)
Is that anything like the 19100 that one monitor displayed the year after
1999?
--
Shmuel (Seymour J.) Metz, SysProg and JOAT
ISO position; see <http://patriot.net/~shmuel/resume/brief.html>
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)
Shmuel Metz , Seymour J.
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 leasing his software in the first place.
--
Shmuel (Seymour J.) Metz, SysProg and JOAT
ISO position; see <http://patriot.net/~shmuel/resume/brief.html>
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)
----------------------------------------------------------------------
Kenneth R Barkhau
Hal Merritt
Kenneth R. Barkhau
NOTICE: This electronic mail message and any files transmitted with it are intended
exclusively for the individual or entity to which it is addressed. The message,
together with any attachment, may contain confidential and/or privileged information.
Any unauthorized review, use, printing, saving, copying, disclosure or distribution
is strictly prohibited. If you have received this message in error, please
immediately advise the sender by reply email and delete all copies.