 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>>>> The next one will be 2049 and my life support will start playing up. ;-)
>>> 2038, I expect. Then 2059.
> No clue about 2059.
That was a typo. I just meant 2049 but hit the wrong key. Sorry.
--
Darren New, San Diego CA, USA (PST)
"Oh no! We're out of code juice!"
"Don't panic. There's beans and filters
in the cabinet."
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 7/21/2012 9:27 PM, Jim Henderson wrote:
>> Given the broadcast of the cheering from the FAA when the clocks rolled
>> over GMT and planes didn't fall out of the sky, I'm not totally inclined
>> to dismiss the first possibility.
>
> I'm not really inclined that way either. I had systems that needed to be
> updated to deal with potential issues, but I don't know that anyone knows
> for sure that if we'd done nothing if there would've been the chaos that
> was predicted.
>
> Jim
>
I think the issue would have hit a lot of financial companies, and a lot
of DOS/Windows machines, but not all of them. Mostly financial though. A
"Huge" issue with most banks was that many still ran mainframes, with
old COBOL in them. To save space, the whole systems used a two digit
number to track dates. And, no, I don't mean an integer, I mean a "human
readable" two digit number, which could only contain 0-9, in two characters.
Due to the way they where coded, you would have had to either rewrite
the entire systems, or you had to convert the existing DBs to something
that did work, or you had to add code to "work around" the problem. The
first one was mad, the second one not possible (since many of them
couldn't afford to just boat anchor their mainframe, or install a real
OS and language on them), and the last one.. while more viable, was just
a total pain in the ass. We could have ended up with today's recession,
12 years ago, as whole banks "lost track" of when, who, how much, and
maybe even, in some cases, to what, money was owed.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 7/22/2012 21:33, Patrick Elliott wrote:
> dates. And, no, I don't mean an integer, I mean a "human readable" two digit
> number, which could only contain 0-9, in two characters.
Most likely packed BCD, with two digits in one byte, actually.
--
Darren New, San Diego CA, USA (PST)
"Oh no! We're out of code juice!"
"Don't panic. There's beans and filters
in the cabinet."
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Sun, 22 Jul 2012 21:33:42 -0700, Patrick Elliott wrote:
> And, no, I don't mean an integer, I mean a "human readable"
> two digit number, which could only contain 0-9, in two characters
What it's called is "Binary Coded Decimal" IIRC
Jim
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>> And, no, I don't mean an integer, I mean a "human readable"
>> two digit number, which could only contain 0-9, in two characters
>
> What it's called is "Binary Coded Decimal" IIRC
BCD is where you use 8 bits to represent two 4-bit binary integers which
are constrained to be less than 10 each.
If he really /means/ that it stored two /characters/, that would be 16
bits, not 8. (But I rather doubt that's what it does.)
Exhibit C: EBCDIC.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 23.07.2012 06:44, schrieb Darren New:
> On 7/22/2012 21:33, Patrick Elliott wrote:
>> dates. And, no, I don't mean an integer, I mean a "human readable" two
>> digit
>> number, which could only contain 0-9, in two characters.
>
> Most likely packed BCD, with two digits in one byte, actually.
Fortunately in many cases, AFAIK actually no. So often enough, migrating
from BCD to packed BCD was sufficient.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 23.07.2012 16:04, schrieb Invisible:
>>> And, no, I don't mean an integer, I mean a "human readable"
>>> two digit number, which could only contain 0-9, in two characters
>>
>> What it's called is "Binary Coded Decimal" IIRC
>
> BCD is where you use 8 bits to represent two 4-bit binary integers which
> are constrained to be less than 10 each.
No; that would be /packed/ BCD.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 23/07/2012 2:49 PM, Jim Henderson wrote:
> What it's called is "Binary Coded Decimal" IIRC
I remember that. I used to boot H316s by entering BCD into the switch
register, step by step. Until it would load the loader tape.
Ah! Memories.
--
Regards
Stephen
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 7/23/2012 7:04, Invisible wrote:
> If he really /means/ that it stored two /characters/, that would be 16 bits,
> not 8. (But I rather doubt that's what it does.)
Sometimes, sometimes not. There's a data type for "packed BCD", and a data
type for "display BCD." Which you stored depends on what you intended to do
with it. Remember that COBOL is also intended as a report generator, to a
large extent.
--
Darren New, San Diego CA, USA (PST)
"Oh no! We're out of code juice!"
"Don't panic. There's beans and filters
in the cabinet."
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 7/22/2012 9:44 PM, Darren New wrote:
> On 7/22/2012 21:33, Patrick Elliott wrote:
>> dates. And, no, I don't mean an integer, I mean a "human readable" two
>> digit
>> number, which could only contain 0-9, in two characters.
>
> Most likely packed BCD, with two digits in one byte, actually.
>
I have to say.. I am glad I forgot what those where. lol
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
