Cool. Interesting, that I did not find this obvious work-around by myself.
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:
At 23:34 +0100 on 01/08/2010, Bernd Oppolzer wrote
I had thought of that. I was concerned about what the non-problem cards
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
On 01/08/2010 05:23 PM, Andy Wood wrote:
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
On Sat, 9 Jan 2010 09:49:22 -0600, Joel C. Ewing wrote:
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
If I recall correctly, this is the second case in Germany causing electronic
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.oppol...@t-online.dewrote:
Cool. Interesting, that I did not find this obvious
ti...@yahoo.com
I'll describe our DR exercise a bit and get you more information next
week when the SMS guy returns, including a sample of all of the SMS code
if you wish.
When we go to the DR site we take our backup tapes from a week back
(leaving the most current at our offsite home
The machines can be fixed to temporally send a year of x'0A' in lieu of the
x'10' which is being misinterprete
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
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
From: Rick Fochtman rfocht...@ync.net
To: IBM-MAIN@bama.ua.edu
Sent: Fri, January 8, 2010 2:14:13 PM
Subject: Re: Subject: Re: VTOC Fmt6
--snip---
---SNIP-
I
On 01/09/2010 10:43 AM, Paul Gilmartin wrote:
On Sat, 9 Jan 2010 09:49:22 -0600, Joel C. Ewing wrote:
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,
On 01/09/2010 04:32 PM, Joel C. Ewing wrote:
On 01/09/2010 10:43 AM, Paul Gilmartin wrote:
On Sat, 9 Jan 2010 09:49:22 -0600, Joel C. Ewing wrote:
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
On Sat, 9 Jan 2010 16:43:42 -0600, Joel C. Ewing wrote:
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.
Wouldn't it take a fourth TM (or a CLI) to get the 100-year rule in
12 matches
Mail list logo
