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
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
>>>
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 yea
From: Rick Fochtman
To: IBM-MAIN@bama.ua.edu
Sent: Fri, January 8, 2010 2:14:13 PM
Subject: Re: Subject: Re: VTOC Fmt6
-
---SNIP-
> I strongly disagree
> Quali
From: Elardus Engelbrecht
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 will sue. I said go ahead
an
>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 e
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 locati
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
wrote:
> Cool. Interesting, that I did not find this obvious work-around by myself.
> May
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
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
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 t
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 abo
12 matches
Mail list logo
