Xenix y2k, profile
wvaughan
"follow me". I then pulled back the plastic sheet over top and said
look at this... TRS-80 Model 16B. I plugged her in and typed 9912312357
in response to the date. They were amazed... I was amazed that when her
clock rolled over the year showed as 2000 just fine and dandy.
Scriptsit seemed just fine...
@td in Profile worked perfectly, displaying Jan 1, 2000 on the screen.
Of course @dt was /OV, but that was to be expected.
I even bumped the date up to Feb 2, 2002 and everything seemed okay.
It's amazing how "not slow" the machine felt.
My question is does anyone know the window of years that date
will accept as valid on Tandy Xenix?
I also have wondered how to make this machine telnettable.
Ward Donald Griffiths III
>
> I also have wondered how to make this machine telnettable.
Attach it to a serial port on your Linux box. Give the invited
guests telnetting to your Linux box a 'cu' or minicom connection
to the T6k. There's no native TCP/IP stack for the T6k.
--
Ward Griffiths
"Men will never be free until the last king is strangled with
the entrails of the last priest." Denis Diderot
F Barry Mulligan
> My question is does anyone know the window of years that date
> will accept as valid on Tandy Xenix?
Start making your preparations now. At 03:14:08 GMT, 19 Jan 2038
your Mod 16 will fail. Unfortunately, so will all Unix based systems.
Everyone knows this, but what do you want to bet there's a mad scramble
in 2037 to finally deal with the problem?
The designers of Unix laid out a clean, logical system. One of their
inspirations was to avoid the hassles of our weird time and date system
by keeping all internal values as elapsed seconds since 00:00 GMT 01 Jan
1970. Only when this is entered or displayed do system functions go to
the trouble of converting to the various local formats (i.e. 12/24 clock,
12/08/99 vs 08-12-99 for today's date, time zones, etc).
The one problem: this integer is stored in 32 bits, including the sign
bit. 00 Jan 1970 + 21 secs yields the magic date. Since every date and
time calculation assumes a 32-bit integer, changing the size of the number
means changing the entire Unix system, and every application program (not
to mention the physical size of the CPU's registers).
Since I'm unlikely to be around when Unix's epoch rolls over, I can
view this with bemusement, but if you're planning on taking out a 30 year
mortgage, I'd suggest stopping by the bank before 2008.
By the way, Profile uses a similar idea for it's internal time stamps.
The dates of creation, update and batch processing of each record are
recorded as the number of days since 01 Jan 1983. This is stored in two
bytes, so (assuming one bit for a sign) it should last until 2072.
/* barry /&
mull...@acm.org
Lord Apollyon
<wvau...@steelerubber.com> wrote:
> It's amazing how "not slow" the machine felt.
Yah, most of those old machines didn't feel slow - many felt "faster" than
today's computers, because they did direct to screen memory sorta things,
and there weren't large bitmappy graphics to deal with. Things just
popped and snapped on-screen, and responded instantly... none of this
type-type-click [wait-hard-drive-thrash][wait][wait][response] like
today's LosingDoze systems.
> My question is does anyone know the window of years that date
> will accept as valid on Tandy Xenix?
Doesn't it use the same 32 bit count of seconds since 1970 scheme most
UNIces seem to use?
> I also have wondered how to make this machine telnettable.
Didn't Xenix have networking of any kind? I can't imagine a UNIX system
without networking, even an 80s era one. :)
=R=
--
The reply-to-address will expire on Midnight 1-January-2000.
Spammers: You will lose your network access. Guaranteed.
99 domains, 360 web-accounts, and 561 dialup ISP accounts flushed.
Stan Barr
>
>My question is does anyone know the window of years that date
>will accept as valid on Tandy Xenix?
I think most Unices and variants ore OK until 2040.
--
Cheers,
Stan Barr st...@dial.pipex.com
The future was never like this!
wvaughan
seems to be strange in what it will accept
However, the startup time/date when booting (which I would think would
be the same) does accept up to 2038 and displays it correctly. After the
epoch roll over the time is displayed as
Dec. 13th, 1901 @ 20:45 (or there abouts).
Hum, thats 58 years before I was born to the day. I own a 1958 Chevy.
<insert twilight zone theme music>
Ward Donald Griffiths III
> Didn't Xenix have networking of any kind? I can't imagine a UNIX system
> without networking, even an 80s era one. :)
Sure it does. It has uucp, the original Unix networking over
serial hardware. But there was never an ethernet card and
there were never Xenix drivers for the Arcnet cards that we
sold for the Midel II. And, as I mentioned earlier, there was
never a TCP/IP stack. Even for SCO Xenix, TCP/IP was an
expensive add-on, along about 1988 when it first appeared.
F Barry Mulligan
> 00 Jan 1970 + 21 secs yields the magic date.
Whoops. That was supposed to be 1970 + 2 exp 31 secs - seems the
CIS e-mailer thought a caret meant a deletion.
Frank Durda IV
: But ...
: there were never Xenix drivers for the Arcnet cards that we
: sold for the Midel II.
Actually, there were. The product was VIANET. A heavily-fixed Arcnet
card was needed (look for the "deadbug" fix in order for it to actually
work, but it did work.
Frank Durda IV - only this address works:|"The Knights who say "LETNi"
<uhclem.jan00%nemesis.lonestar.org> | demand... A SEGMENT REGISTER!!!"
|"A what?"
This Anti-spam address expires Jan. 31st |"LETNi! LETNi! LETNi!" - 1983
Copr. 1999, ask before reprinting.
Ward Donald Griffiths III
>
> Ward Donald Griffiths III (wdg...@home.com) wrote:
> : But ...
> : there were never Xenix drivers for the Arcnet cards that we
> : sold for the Midel II.
>
> Actually, there were. The product was VIANET. A heavily-fixed Arcnet
> card was needed (look for the "deadbug" fix in order for it to actually
> work, but it did work.
Yes, I _know_ you cats in the Towers and connecting Atrium had lots
of things we never saw out in the world. But the only things I ever
got to hook up to Vianet were T2000s and lesser machines that were
(ugh) PC compatible.
Mike Yetsko
Was that to fix the problem with the buffers?? I thought there was an
updated chip to fix that? (Hmm, if it's what I think, that could have
been fixed in software, it was just that the buffers weren't contiguous)
Or was there 'another' problem...
Mike
Frank Durda IV <uhclem...@nemesis.lonestar.org> wrote in message
news:FMGLD...@nemesis.lonestar.org...
> Ward Donald Griffiths III (wdg...@home.com) wrote:
> : But ...
> : there were never Xenix drivers for the Arcnet cards that we
> : sold for the Midel II.
>
> Actually, there were. The product was VIANET. A heavily-fixed Arcnet
> card was needed (look for the "deadbug" fix in order for it to
actually
> work, but it did work.
>
>
Eric J. Korpela
Lord Apollyon <spammersmu...@paypc.com> wrote:
>> I also have wondered how to make this machine telnettable.
>
>without networking, even an 80s era one. :)
It did have an arcnet card available, supposedly. But I've never seen one.
As far as networking, I'm sure KA9Q was ported to it, so outgoing SLIP is
feasable. But without PTY support in the kernel, incoming telnet would be
a bit on the difficult side. You'd need to write some sort of userland
virtual terminal.
Remember, Xenix was written by Microsoft, (or for, depending upon who you ask,
I'm personally undecided about SCO's status at that point in time) a company
that couldn't see the Internet on the horizon in 1993.
On the other hand, a lot of competing systems didn't offer networking at that
point either.
Eric
--
Eric Korpela | An object at rest can never be
kor...@ssl.berkeley.edu | stopped.
<a href="http://sag-www.ssl.berkeley.edu/~korpela">Click for home page.</a>
Neil Bradley
Actually, you're a bit wrong on this.
2^31 Seconds is about 68 years, so 1970+68=2038 or so. That doesn't
include the sign bit. Time_t is defined as a signed 32 bit integer. So
if worse came to worst, all those people running FreeBSD and Linux could
change the time library to treat it as unsigned which would make it good
to 2106 or so. By then we should be using 64 bit integers and then we'd
be good until the year 584542048060, or half that if it's signed. ;-)
-->Neil
Frank Durda IV
: Was that to fix the problem with the buffers?? I thought there was an
: updated chip to fix that? (Hmm, if it's what I think, that could have
: been fixed in software, it was just that the buffers weren't contiguous)
: Or was there 'another' problem...
There was another problem with the MII/12/16/6000 ARCNET card that I found.
This must have been in mid-to-late 1986 or the first-half of 1987. I got
sucked into working on Vianet briefly because the Vianet people and the
guy working on the driver locally could not get it to work reliably. At
that time, I was the sole keeper of the Z80 side of XENIX and had replaced
all of the earlier drivers with my own, except for this new ARCNET driver
which I didn't want to have anything to do with. (I remembered TRSDOS ARCNET
and what a tar-baby it was to the people who got stuck working on that.)
Anyway, once involved, a few weeks with a 'scope and some special test
programs revealed the main problem with non-deterministic behavior to be a
hardware timing problem. Definitely the wrong answer at Tandy. :-)
The timing glitch would cause the "next byte" pointer to double-step or skip
a byte in the on-board buffer every now and then, rendering the data being
sent/read rubbish. The hardware timing bug was there all the way back in
the cards used in the TRSDOS ARCNET implementation and probably explained
the years of unreliability that hounded that product, and probably also
explains why TRSDOS had to assume it was an unreliable transport media and
add their own checksums to the packets, do retries, etc.
I just went into my board archive and found two rev versions of that card.
The 512-byte mod consists mainly of a 74S74 dead-bugged on U17, and
four blue wires between the 7474 and the Z80A CTC, and the on-board RAM.
This appears to provide the addressing to get to the upper part of the RAM.
However if I remember right, this wasn't necessary for XENIX, since you could
not send a buffer larger than 480-something bytes long anyway, thus requiring
two packets to send a 512-byte disk block. There is also a jumper that
applied +5 to a pull-up resistor, that wasn't connected to +5 (missing etch).
The "DMA mod" (the fix for the bug I found) consists of six additional wires
(red on my samples) and cuts, with the red wires running between two spare
NAND gates on U31 (74LS00) and a spare inverter on U20 (74S04). From these,
jumpers went to U32 (74LS02), U28 (74LS04), U15 (74LS145), and U33 (74LS03).
In addition, in most units, they removed U22 and U23 (TI 74S74) and replaced
them with socketed and screened Signetics 74S74 parts.
Note the failure didn't require DMA to be used, but that was the name the fix
was given by the hardware management when forced to fix this. The failure
was blamed on us using DMA, but when shown that received data packets coming
off the 9026 chip were being put into onboard RAM in the same unpredictable
way, they had no choice but to fix regardless of whether we used DMA or not.
As was typical when the Tandy software groups found hardware problems, there
was an extended battle between us and the hardware departments managers,
hardware director(s) and hardware VP over whether this was a real problem and
whether it really mattered even if it was a real bug. You would hear stuff
like "you software guys don't know how to work a 'scope", "it doesn't happen
all time, so you can retry, right?", and "can't you hide the problem with a
software change? I'll talk to your boss about making you guys do a software
change.", "Software patches are cheaper than hardware fixes so patch around
it", "The lack of a software workaround for the alleged hardware bug you
found has shut the factory down", etc. You know, the same hide-the-hardware-
bugs-with-software stuff that was going on when you were there...
By the way, to the other note in this thread, VIANET for XENIX was shipped and
was actually available to customers who wanted it for a while. Apart from
a special z80ctl module, everything else pretty-much layered on top of the
XENIX kernel link kit. (Some copies were given away as a way to get sites
off TRSDOS ARCNET platforms.) Meanwhile, inside R&D, we didn't use Vianet at
all, apart from a two or three station test system that eventually went back
to Vianetics and returned one day unexpectedly from Western Digital. That's
how we found out that Vianetics had been bought by WD, and had apparently
WD decided to scrap the entire project. WD apparently simply emptied those
former employees offices into boxes and mailed them back to us. We got
staplers, notepads, computers, ketchup packets, disk drives and so on.
Instead of deploying with Vianet/ARCNET within TSS (Tandy System Software),
most of the R&D software groups at that time were busy draping Tandylink wire
all over creation and pretending that Tandylink was a network... We had
ripped most of the ARCNET wiring out of the ceiling years earlier.
Frank Durda IV
: Remember, Xenix was written by Microsoft, (or for, depending upon who you ask,
: I'm personally undecided about SCO's status at that point in time) a company
: that couldn't see the Internet on the horizon in 1993.
Yes and no. Microsoft alternated between wanting to control XENIX and
abandoning/farming it to others. MS did the V7 port, then decided they didn't
like XENIX and abandoned V7 and handed the preliminary System III work to SCO.
SCO finished System III and did the 68000 port for the Lisa which was used as
the basis for the Model 16 System III port, although almost all the adaptation
to the Model 16/6000 was done at Tandy.
By summer of 1983, SCO had a XENIX-86 port that they had minor success with
and I went out to SCO in August of 1983 to build the bootstrap for the Model
2000, which SCO then dis a port for.
Then when XENIX-286 appeared which started as a System III port, Microsoft
decided to take control again and handled that, probably because IBM wanted
XENIX for the PC/AT. Then MS switched to working on System V for IBM (while
still doing System III for OEMs like Tandy who weren't being told System V
was available yet - nice, level playing field). MS ran both of these tracks
for a while (till about mid 1986), then MS got bored with XENIX again (about
the same time as IBM abandoned XENIX-286 due to poor sales) and shifted the
XENIX-286 work to SCO, where it stayed.
For a while, SCO was doing the work on XENIX-286, but MS was still doing the
OEM distributions, meaning you had to wait for code to go from SCO to MS who
might massage it a bit and then would forward the code on to you, a process
that added days or weeks to each release. Finally we got MS out of the loop.
We celebrated a lot.
XENIX-386 was delivered to OEMs (like Tandy) directly from SCO and Microsoft
stayed out of the XENIX world from that point on.
Leonard Erickson
> wvaughan <wvau...@steelerubber.com> wrote:
>> My question is does anyone know the window of years that date
>> will accept as valid on Tandy Xenix?
>
> Start making your preparations now. At 03:14:08 GMT, 19 Jan 2038
> your Mod 16 will fail. Unfortunately, so will all Unix based systems.
> Everyone knows this, but what do you want to bet there's a mad scramble
> in 2037 to finally deal with the problem?
Not true! See below.
Systems storing the time in a 32-bit *signed* variable will crash then.
Systems storing it in a 32-bit *unsigned* variable won't crash until
Friday, February 5, 2106 at 06:28:16.
And even now newer systems are using *64-bit* registers and variables
for the time. Those won't overflow for almost 585 *billion* years.
So only old legacy gear will fail.
> The designers of Unix laid out a clean, logical system. One of their
> inspirations was to avoid the hassles of our weird time and date system
> by keeping all internal values as elapsed seconds since 00:00 GMT 01 Jan
> 1970. Only when this is entered or displayed do system functions go to
> the trouble of converting to the various local formats (i.e. 12/24 clock,
> 12/08/99 vs 08-12-99 for today's date, time zones, etc).
So far so good.
> The one problem: this integer is stored in 32 bits, including the sign
> bit. 00 Jan 1970 + 21 secs yields the magic date. Since every date and
> time calculation assumes a 32-bit integer, changing the size of the number
> means changing the entire Unix system, and every application program (not
> to mention the physical size of the CPU's registers).
And here's where you go wrong. The size of the variable that is used to
store time values is a *parameter* in the source code. You *define* the
size before you compile the OS. To "fix" this, you simple change *one
line* of the source code. Something like this:
Change:
time_type : dword; (unsigned 32-bit integer)
to:
time_type : qword; (unsigned 64-bit integer)
Of course, doing this means the directory structure will have changed,
but that's solved by simply backing up the system, installing the new
version, and restoring from backup. :-)
The problem is is that many current systems don't have any types larger
than dword. And some either don't have dword, or had programmers use
longint inspite of the existence of dword.
Longint is a *signed* 32-bit integer. Which loses us a bit for the
"maximum" time (though it *does* allow the use of negative values for
times *before* 1970).
Systems storing the time in a 32-bit *signed* variable will crash in
2038. Systems storing it in a 32-bit *unsigned* variable won't crash
until Friday, February 5, 2106 at 06:28:16.
And newer systems using *64-bit* registers and variables for the time
won't overflow for almost 585 *billion* years.
So only old legacy gear will fail.
--
Leonard Erickson (aka Shadow)
sha...@krypton.rain.com <--preferred
leo...@qiclab.scn.rain.com <--last resort
Leonard Erickson
> My question is does anyone know the window of years that date
> will accept as valid on Tandy Xenix?
Xenix is essentially a Unix clone. Unix stores the time as the number
of seconds since the start of 1970.
Since it accepted a 2000 date, it must be using a 32 bit variable to
store the time in (well, it could be using a 30 bit value, but that's
*really* unlikely :-). If it's using a *signed* variable, then it can't
go higher than:
31 7FFFFFFF -> Tue Jan 19 03:14:07 2038
If it's using an *unsigned* variable then the limit is:
32 FFFFFFFF -> Fri Feb 5 06:28:15 2106
Lord Apollyon
sha...@krypton.rain.com (Leonard Erickson) wrote:
> Systems storing the time in a 32-bit *signed* variable will crash in
> 2038. Systems storing it in a 32-bit *unsigned* variable won't crash
> until Friday, February 5, 2106 at 06:28:16.
Colour me cranky... but I've put up with far too many "non-computer-types"
pestering me about Y2k and how the world will end in 19 days.
Having dates roll over to their origins didn't cause any of the computers
I use to crash. Funny dates on the files, yes. Crashes, no. The worst I
had to do was "make clean" my code to ensure the object files were cleared
out.
This isn't to say there are applications and tools that may generate
"incorrect" output when this rollover occurs, but crashing and utter
dysfunction... I think not.
I can see the surveys in the year 2000....
"The top 10 biggest media hype stories of the 1990s:
10) Netscape Communications
[...]
1) Your computers and the entire world will explode on Jan 1, 2000
Bill Vermillion
>Didn't Xenix have networking of any kind? I can't imagine a UNIX
>system without networking, even an 80s era one. :)
Tandy had that ever-popular Arcnet :-)
--
Bill Vermillion bv @ wjv.com
Bill Vermillion
Frank Durda IV <uhclem...@nemesis.lonestar.org> wrote:
>Then when XENIX-286 appeared which started as a System III port,
>Microsoft decided to take control again and handled that, probably
>because IBM wanted XENIX for the PC/AT.
IBM's first Xenix (1.1??) was released as unsupported. WHen they
released the next version (1.2???), it was supported.
That had to be the buggiest release of a Unix type operating system
I've ever used. I was only working in a few parts, and they had
things broken in ioctl. I was doing some work on reading RF
modems at that time. (A LONG time ago)
There were places were standards called for 'anding' values, and
the original value was replaced, and others (in file creation)
where you were supposed to give specific values, and it anded them
with the original value.
Then MS switched to working on System V for IBM (while
>still doing System III for OEMs like Tandy who weren't being told System V
>was available yet - nice, level playing field). MS ran both of these tracks
>for a while (till about mid 1986), then MS got bored with XENIX again (about
>the same time as IBM abandoned XENIX-286 due to poor sales) and shifted the
>XENIX-286 work to SCO, where it stayed.
>
>For a while, SCO was doing the work on XENIX-286, but MS was still doing the
>OEM distributions, meaning you had to wait for code to go from SCO to MS who
>might massage it a bit and then would forward the code on to you, a process
>that added days or weeks to each release. Finally we got MS out of the loop.
>We celebrated a lot.
>
>XENIX-386 was delivered to OEMs (like Tandy) directly from SCO and Microsoft
>stayed out of the XENIX world from that point on.
>
>
>Frank Durda IV - only this address works:|"The Knights who say "LETNi"
> <uhclem.jan00%nemesis.lonestar.org> | demand... A SEGMENT REGISTER!!!"
> |"A what?"
>This Anti-spam address expires Jan. 31st |"LETNi! LETNi! LETNi!" - 1983
>Copr. 1999, ask before reprinting.
>
Bill Vermillion
>> wvaughan <wvau...@steelerubber.com> wrote:
>>> My question is does anyone know the window of years that date
>>> will accept as valid on Tandy Xenix?
>> Start making your preparations now. At 03:14:08 GMT, 19 Jan 2038
>> your Mod 16 will fail. Unfortunately, so will all Unix based systems.
>> Everyone knows this, but what do you want to bet there's a mad scramble
>> in 2037 to finally deal with the problem?
>Not true! See below.
>Systems storing the time in a 32-bit *signed* variable will crash then.
>Systems storing it in a 32-bit *unsigned* variable won't crash until
>Friday, February 5, 2106 at 06:28:16.
>And even now newer systems are using *64-bit* registers and variables
>for the time. Those won't overflow for almost 585 *billion* years.
It's been a long time since the days of the VAX which was basically
a 1 MIPS machine.
With 64 bit registers we should probably take 10 of the 64 bits
so we can divide/store times at the microsecond level.
Of course in these days with operational (but not deployed)
6 Terabit fiber links even a microsecond encompasses a lot of data.
Frank Durda IV
: Then when XENIX-286 appeared which started as a System III port,
: Microsoft decided to take control again and handled that, probably
: because IBM wanted XENIX for the PC/AT.
Bill Vermillion (bi...@wjv.com.REMOVEME) wrote:
: That had to be the buggiest release of a Unix type operating system
: I've ever used. I was only working in a few parts, and they had
: things broken in ioctl. I was doing some work on reading RF
: modems at that time. (A LONG time ago)
You can thank Microsoft for a shaky port, shaky compiler, shaky, well,
everything. The compiler was a port of MS-DOS Microsoft C 4.0, but you
aren't supposed to notice that.
Tandy was racing to try to beat IBM to the street with XENIX-286, but IBM
released it first. When we looked at what IBM had shipped, we were happy
because IBM released it with all the bugs we were waiting on Microsoft to fix
and Tandy was unwilling to ship in that bad a shape. We still got our ears
nailed to the floor for not getting our release out before IBM, but it was
tempered by everybody knowing that IBM shipped junk, and our release would
have more Tandy-only goodies.
Mike Yetsko
Lord Apollyon <spammersmu...@paypc.com> wrote in message
>
> Colour me cranky... but I've put up with far too many
"non-computer-types"
> pestering me about Y2k and how the world will end in 19 days.
>
> Having dates roll over to their origins didn't cause any of the
computers
> I use to crash. Funny dates on the files, yes. Crashes, no. The
worst I
> had to do was "make clean" my code to ensure the object files were
cleared
> out.
>
> This isn't to say there are applications and tools that may generate
> "incorrect" output when this rollover occurs, but crashing and utter
> dysfunction... I think not.
Well, I've seen some problems, but most are BS. I've had people ask
me about their ammo for their M16 being Y2K!! (But that was actually
related to a serious issue with taggants, and the fact that for a short
time, there was an issue with primers being made to 'expire' that
never made it to pass.
And you hear these stories about valves that will open or shut on Y2K.
Give me a Fnnn (and NOT the function key!) break! Idiots are spreading
these stories. Show me ONE freaking valve with a microcontroller on
it that uses a DATE for comparison!!
Sure, there may be problems with prisons and parole, but surely not
in the cell doors! Probably with automatic recordkeeping of time
served kind of thing. But where is the 'human' involvement?
I explain to people that the issue is like my checkbook. Since I moved
from Texas years ago (1985) I've kept sequential check numbers.
About 2 years ago, they hit 10000. Well, I happened to be at this
'discount' salvage store when I wrote check 10000 for a refurb
garage door opener and a few other things. Ever write a multi-
hundred dollar check at a 'salvage' store to begin with? Well, it
CRASHED their check system. It couldn't handle check number
'0000'. (This was a 4-digit issue the same as the Y2K 2-digit
issue!) They had to reboot their system, and try again. CRASH!
Mean time this fat lady with one tooth in line behind me kept
getting annoying repeatedly asking "What's the holdup?"
They finally called the check approval place on the phone, and manually
put it through. Since then, checks 10001 to 10099 would sometimes
come up with errors, and a notice to 'call in' for approval. Seems
check numbers 0001 through 0099 are 'illegal' but the account
showed proper activity so they all went through.
This problem appeared to be with just one of the check approval
companies. Probably the cheapest one, since the salvage store I
was at certainly didn't spend any money on anything they didn't
absolutely have to. They made Building 19 and Ocean State
Joblots look like A&F.
Then some stores flag any checks under number 500 as 'new account'
and require manager sign-off...
So, there can be problems, but most are BS and hype.
Do I personally expect problems on New Years Eve? Yeah, some
minor ones. And some civil unrest in some cities if the weather
is nice because there's always some idiot looking for excuses just
to get away with things. But nothing major.
Except for one thing... I know of one MAJOR city that bought 800mhz
trunked radios just a couple years ago, but they bid out on lowest
cost at the time, electing instead to 'upgrade' to spread the cost even
though it ended up costing more, even with finance charges, than if
they had bought the better system originally. Anyway, the system was
an older version of a state of the art system that did date/time
stamping
and encryption and such. Well, they KNEW it was not Y2K compliant,
and they KNEW at the time it would shut down on 2000, and they
KNEW how much the conversion/upgrade cost would be, and they
KNEW the conversion/upgrade schedule.
But they drug their feet getting a contract, then drug their feet doing
the scheduling, now they are in a semi-panic as technicians working
overtime STILL can't get much more than 1/3 the system converted
by New Years.....
Mike
Lord Apollyon
uhclem...@nemesis.lonestar.org (Frank Durda IV) wrote:
> You can thank Microsoft for a shaky port, shaky compiler, shaky, well,
> everything. The compiler was a port of MS-DOS Microsoft C 4.0, but you
> aren't supposed to notice that.
Wow. Talking to you is an enlightening education. Whatever last shreds
of "benefit of the doubt" I ever possessed for Micro$oft as a technology
company have been utterly expunged. :)
They've been peddling garbage for their entire existence, it would seem.
=R=
--
The reply-to-address will expire on Midnight 1-January-2000.
Spammers: You will lose your network access. Guaranteed.
101 domains, 367 web-accounts, and 563 dialup ISP accounts flushed.
Lord Apollyon
Vermillion) wrote:
> Of course in these days with operational (but not deployed)
> 6 Terabit fiber links even a microsecond encompasses a lot of data.
Damn, baby. Sign me up!