larry@zeek.UUCP (Larry Podmolik) (05/16/89)
I need a C function that, given a date, would return what day of the week it fell on. Of course, I didn't think to save it at the time. I seem to remember this coming up in comp.lang.c, but I can't be sure. If anybody out there has this, could you please e-mail it to me? Thanks in advance, Larry
kar@cs.rit.edu (05/19/89)
In article <234@zeek.UUCP> larry@zeek.UUCP (Larry Podmolik) writes: >I need a C function that, given a date, would return what day of the >week it fell on. ... Check out the February 1979 issue of Interface Age (page 75-79). They give algorithms for all sorts of time/date problems. I used one to do what you want to do, and needed only the additional knowledge of today's date and today's day of the week. Kenneth A. Reek Rochester Institute of Technology {harvard,rutgers}!rochester!ritcv!kar
doug@xdos.UUCP (Doug Merritt) (05/22/89)
In article <234@zeek.UUCP> larry@zeek.UUCP (Larry Podmolik) writes: >I need a C function that, given a date, would return what day of the >week it fell on. ... Try this: ((year * 1.25) + (day-of-the-year) + constant) modulo 7 ...where day-of-the-year is obtained by adding day-of-month to sum of days in each month prior to month-of-year, and I forget the exact value of constant, but it's trivial to obtain by using the formula on today's date, and seeing what adjustment is needed (it really is a constant). An adjustment for the switchover from the Julian to the Gregorian calendar may be needed depending on the era and country of interest. A variation on this formula (involving a table of constants for each month in place of day of the year) can be used to easily *mentally* calculate day of the week. All calculations can be done modulo 7, which makes it easier. The factor of 1.25 is what makes it work despite leap years. Doug -- Doug Merritt {pyramid,apple}!xdos!doug Member, Crusaders for a Better Tomorrow Professional Wildeyed Visionary
flaps@dgp.toronto.edu (Alan J Rosenthal) (05/22/89)
In article <234@zeek.UUCP> larry@zeek.UUCP (Larry Podmolik) writes: >I need a C function that, given a date, would return what day of the >week it fell on. It's in almost all C libraries and it's called localtime(). Depending on which format your input date is in, you might want to use the new mktime() function. I've seen PD mktime()s go by. I can mail you non-PD versions of these functions for your personal use if you want. ajr -- "The winners write the history books."
flee@shire.cs.psu.edu (Felix Lee) (05/23/89)
In article <322@xdos.UUCP>, doug@xdos.UUCP (Doug Merritt) writes: >Try this: > ((year * 1.25) + (day-of-the-year) + constant) modulo 7 Using a strict interpretation of (day-of-the-year), you should use (year + (year-1)/4) instead of (year * 1.25). For the Gregorian calendar, try this instead: year + (year-1)/4 - (year-1)/100 + (year-1)/400. Note that not all countries adopted the Gregorian calendar at the same time. (Japan was quite late, something like 19th century?) -- Felix Lee flee@shire.cs.psu.edu *!psuvax1!shire!flee
rjd@occrsh.ATT.COM (Randy_Davis) (05/24/89)
In article <234@zeek.UUCP> larry@zeek.UUCP (Larry Podmolik) writes: |I need a C function that, given a date, would return what day of the |week it fell on. Of course, I didn't think to save it at the time. Well, this is not C, but it is a cheap and easy shell script that will do the same, based on the "cal" command. Randy Davis UUCP: ...(att!)ocrjd!randy ...(att!)occrsh!rjd --------------------------cut here-------------------------------------- # How this for simple - "dow", a simple day of week calculator, written 1/11/89 # by Randy Davis. Error checking and error messages added 3/9/89. USAGE="Usage: $0 month[1-12] day[1-31] year[00-99] - to calculate the day\nof week for a certain date." MONTH=$1 DAY=$2 YR=$3 case "$DAY" in [1-9]|[12][0-9]|3[01]) ;; *) echo $USAGE ; exit ;; esac case "$MONTH" in [1-9]|1[012]) ;; *) echo $USAGE ; exit ;; esac case "$YR" in [0-9][0-9]) ;; *) echo $USAGE ; exit ;; esac set `cal $MONTH 19$YR | egrep "^$DAY | $DAY | $DAY$"` for DOW in Sunday Monday Tuesday Wednesday Thursday Friday Saturday do if [ "$1" = "$DAY" ] then break fi shift done echo $DOW
mark@drd.UUCP (Mark Lawrence) (05/26/89)
flee@shire.cs.psu.edu (Felix Lee) wrote: .... } Note that not all countries adopted the Gregorian calendar at the } same time. (Japan was quite late, something like 19th century?) Just going through receipts for an expense report for a trip last week and I spot a receipt for a train-trip to Yumoto which took place on May 15, 1 Heisei. Last time I was there, everything was dated 63 (or was it 64?) Showa.
henry@utzoo.uucp (Henry Spencer) (05/30/89)
In article <554@drd.UUCP> lawrence@tusun2.knet.utulsa.edu (Mark Lawrence) writes: >} Note that not all countries adopted the Gregorian calendar at the >} same time. (Japan was quite late, something like 19th century?) > >Just going through receipts for an expense report for a trip last >week and I spot a receipt for a train-trip to Yumoto which took place on >May 15, 1 Heisei. Last time I was there, everything was dated 63 (or was >it 64?) Showa. Two different problems. Note that it *did* say "May 15". That's the Gregorian calendar, specifying number of days in each month and when the leap-years occur. The *name* given to each year is a different story. Most of the Gregorian world uses the standard "AD" numbering, but Japan numbers from the start of the reign of the current emperor. Last time you were there, Hirohito was still alive. (Yes, he'd been emperor for over 60 years.) The mind boggles at how many programs had to be fixed to know about the new year numbering... -- Van Allen, adj: pertaining to | Henry Spencer at U of Toronto Zoology deadly hazards to spaceflight. | uunet!attcan!utzoo!henry henry@zoo.toronto.edu
jamesa@arabian.Sun.COM (James D. Allen) (05/30/89)
In article <1989May29.232954.25638@utzoo.uucp>, henry@utzoo.uucp (Henry Spencer) writes: > >May 15, 1 Heisei. Last time I was there, everything was dated 63 (or was > >it 64?) Showa. > > Most of the Gregorian world uses the standard "AD" numbering, but Japan > numbers from the start of the reign of the current emperor. Last time > you were there, Hirohito was still alive. (Yes, he'd been emperor for > over 60 years.) > > The mind boggles at how many programs had to be fixed to know about the > new year numbering... Are you sure? Even the most loyal of Japanese programmers should have anticipated outliving the aging emperor. Now a Christian programmer whose software is ready to switch to the year 1 A.A. (Anno Antichristi) ... that would be defensive programming! > -- > Van Allen, adj: pertaining to | Henry Spencer at U of Toronto Zoology > deadly hazards to spaceflight. | James Allen, interj: pertaining to dreadful hazards of unmoderated newsgroups.
trebor@biar.UUCP (Robert J Woodhead) (05/30/89)
In article <107107@sun.Eng.Sun.COM> jamesa@arabian.Sun.COM (James D. Allen) writes: >In article <1989May29.232954.25638@utzoo.uucp>, henry@utzoo.uucp (Henry Spencer) writes: >> The mind boggles at how many programs had to be fixed to know about the >> new year numbering... > >Are you sure? Even the most loyal of Japanese programmers should have >anticipated outliving the aging emperor. Well, for many computer tasks the Japanese use the gregorian calendar. When Hirohito died and the name of the new era (Heisei) was announced, those machines (most notably, bank machines) all had to have their date routines updated. The hooks were already there; in most cases it involved setting a table entry to indicate that 1989 was year 1 of the new era and another entry giving the kanji characters for Heisei. As a matter of note, all of the ticket printing machines in Tokyo subways, which use the Japanese dating system, changed over flawlessly. The major expense was reprinting all the government documents, calendars, etc. This, and not the Recruit scandal, was what really brought down the Takeshita government. Seems that they hadn't set aside enough bribe money to pay for the new calendars, and... -- Robert J Woodhead, Biar Games, Inc. !uunet!biar!trebor | trebor@biar.UUCP ``The worst thing about being a vampire is that you can't go to matinees and save money anymore.''
henry@utzoo.uucp (Henry Spencer) (05/30/89)
In article <107107@sun.Eng.Sun.COM> jamesa@arabian.Sun.COM (James D. Allen) writes: >> The mind boggles at how many programs had to be fixed to know about the >> new year numbering... > >Are you sure? Even the most loyal of Japanese programmers should have >anticipated outliving the aging emperor... Even the stupidest of North American programmers should anticipate that the first two digits of the year will change not too far in the future... but in fact often this gets botched. Forecasting programs are already running into this: 1975 was a bad year for 25-year forecasts, and 1990 will most probably be a rough year for 10-year forecasts. The chaos in 2000 AD will be something to behold. What will happen when the 32-bit Unix date goes negative in mid-January 2038 does not bear thinking about... :-) -- Van Allen, adj: pertaining to | Henry Spencer at U of Toronto Zoology deadly hazards to spaceflight. | uunet!attcan!utzoo!henry henry@zoo.toronto.edu
diamond@diamond.csl.sony.junet (Norman Diamond) (05/31/89)
Minor point first (it came first): In article <554@drd.UUCP> lawrence@tusun2.knet.utulsa.edu (Mark Lawrence) writes: >>} Note that not all countries adopted the Gregorian calendar at the >>} same time. (Japan was quite late, something like 19th century?) >> >>Just going through receipts for an expense report for a trip last >>week and I spot a receipt for a train-trip to Yumoto which took place on >>May 15, 1 Heisei. Last time I was there, everything was dated 63 (or was >>it 64?) Showa. Last time was Showa 63. Showa 64 lasted one week, and Heisei 1 is the rest of this year. There is no Japanese name for this year as a whole. Major point second: In article <1989May29.232954.25638@utzoo.uucp> henry@utzoo.uucp (Henry Spencer) writes: >The mind boggles at how many programs had to be fixed to know about the >new year numbering... Yup. But my mind boggles at how many programs will have to be fixed to know that 2000 is a leap year ... and then all the programs that will have to be fixed to know that 2000 is not 1900 and 2001 is not 1901, and then that 1999 is not 2099, etc. Of course these programs are already broken because these facts are already known, and my mind boggles at how many programmers and managers refuse to permit correct programs to be written instead ... but just wait 'til they need fixing. -- Norman Diamond, Sony Computer Science Lab (diamond%csl.sony.co.jp@relay.cs.net) The above opinions are my own. | Why are programmers criticized for If they're also your opinions, | re-implementing the wheel, when car you're infringing my copyright. | manufacturers are praised for it?
dgibbs@bnr-fos.UUCP (David Gibbs) (05/31/89)
In article <1989May30.155016.11099@utzoo.uucp> henry@utzoo.uucp (Henry Spencer) writes: > >What will happen when the 32-bit Unix date goes negative in mid-January >2038 does not bear thinking about... :-) >-- Nothing of course, because nobody (but nobody) will be using piddly little 32-bit machines in 2038. -David Gibbs dgibbs@bnr-fos.UUCP ...!{utzoo | utgpu}!bnr-vpa!bnr-fos!dgibbs
richard@pantor.UUCP (Richard Sargent) (05/31/89)
> From: henry@utzoo.uucp (Henry Spencer) > Message-ID: <1989May30.155016.11099@utzoo.uucp> > > [...] > > What will happen when the 32-bit Unix date goes negative in mid-January > 2038 does not bear thinking about... :-) > -- > Van Allen, adj: pertaining to | Henry Spencer at U of Toronto Zoology > deadly hazards to spaceflight. | uunet!attcan!utzoo!henry henry@zoo.toronto.edu I've pretty well decided to be several hundred miles away from anything that relies on computers, starting about Summer'99 ... :-). I *hate* to even think about the chaos which will result with the turn of the 'millenium' :-( Maybe the doomsayers had something after all ... Richard Sargent Internet: richard@pantor.UUCP Systems Analyst UUCP: uunet!pantor!richard
cowan@marob.masa.com (John Cowan) (06/01/89)
In article <1989May29.232954.25638@utzoo.uucp> henry@utzoo.uucp (Henry Spencer) writes: >Most of the Gregorian world uses the standard "AD" numbering However, much of the world >calls< that numbering "C.E.", for Common Era. (Used to be "Christian Era".) "In the year of our Lord" is a bit too Christian for lots of nations. -- John Cowan <cowan@marob.masa.com> or <cowan@magpie.masa.com> UUCP mailers: ...!uunet!hombre!{marob,magpie}!cowan Fidonet (last resort): 1:107/711 Aiya elenion ancalima!
emuleomo@yes.rutgers.edu (Emuleomo) (06/01/89)
> What will happen in 2038 when UNIX 32-bit dates will become negative... > Dont worry about it. The world will end in 2025 at 2:02 pm, Jan 2nd. -- Emuleomo O.O.
henry@utzoo.uucp (Henry Spencer) (06/01/89)
In article <534@bnr-fos.UUCP> dgibbs@bcars115.UUCP (David Gibbs) writes: >>What will happen when the 32-bit Unix date goes negative in mid-January >>2038 does not bear thinking about... :-) > Nothing of course, because nobody (but nobody) will be using piddly little >32-bit machines in 2038. Dream on... :-) Have you looked at how many PDP-8s are still in service? I won't even mention the staggering production runs of PDP-11s, which are still in production in fact. (I *think* the 8 is finally out of production, but I could well be wrong.) Nobody uses them in leading-edge applications any more, but there are still lots of them around. The transition from 32 to 64 is going to be long and painful; I predict that there will still be plenty of 32-bit machines serving in secondary roles in 2038. -- You *can* understand sendmail, | Henry Spencer at U of Toronto Zoology but it's not worth it. -Collyer| uunet!attcan!utzoo!henry henry@zoo.toronto.edu
charlie@mica.stat.washington.edu (Charlie Geyer) (06/02/89)
In response to Henry Spencer's question > What will happen when the 32-bit Unix date goes negative in mid-January > 2038 does not bear thinking about ... :-) David Gibbs in article <534@bnr-fos.UUCP> dgibbs@bcars115.UUCP replies > Nothing of course, because nobody (but nobody) will be using piddly little > 32-bit machines in 2038. To which Henry replies > Dream on ... :-) The transition from 32 to 64 is going to be long > and painful; I predict that there will still be plenty of 32-bit > machines serving in secondary roles in 2038. What's more, the 64 bit hardware will all be running 32 bit software. Count on it.
diamond@diamond.csl.sony.junet (Norman Diamond) (06/02/89)
In article <1989May30.155016.11099@utzoo.uucp> henry@utzoo.uucp (Henry Spencer) writes: >>What will happen when the 32-bit Unix date goes negative in mid-January >>2038 does not bear thinking about... :-) In article <534@bnr-fos.UUCP> dgibbs@bcars115.UUCP (David Gibbs) writes: > Nothing of course, because nobody (but nobody) will be using piddly little >32-bit machines in 2038. When I was introduced to a 5-year-old mainframe in 1970, I thought "32 bits isn't enough. Why is this thing less powerful than that slow old little machine that uses BCD, Can't Add and Doesn't Even Try?" Surely no one would have predicted that piddly little 32-bit machines and piddlier littler 16-bit machines would still be used 19 years later. Well, in those 19 years, I adapted not only to 32-bit limitations but also to 16-bit limitations. (Somehow the 8-bit machines had 16-bit library routines supplied by their vendors. Never saw the famous 4-bit machines, except maybe the one that Couldn't Add and Didn't Even Try.) Why can't all these eunuchs do it.... -- Norman Diamond, Sony Computer Science Lab (diamond%csl.sony.co.jp@relay.cs.net) The above opinions are my own. | Why are programmers criticized for If they're also your opinions, | re-implementing the wheel, when car you're infringing my copyright. | manufacturers are praised for it?
badri@valhalla.ee.rochester.edu (Badri Lokanathan) (06/02/89)
Henry Spencer: >> What will happen when the 32-bit Unix date goes negative in mid-January >> 2038 does not bear thinking about ... :-) >David Gibbs in article <534@bnr-fos.UUCP>: >> Nothing of course, because nobody (but nobody) will be using piddly little >> 32-bit machines in 2038. Henry Spencer: >> Dream on ... :-) The transition from 32 to 64 is going to be long >> and painful; I predict that there will still be plenty of 32-bit >> machines serving in secondary roles in 2038. Charlie Geyer in article <1474@uw-entropy.ms.washington.edu>: >What's more, the 64 bit hardware will all be running 32 bit software. >Count on it. Are you guys serious? Do you actually think that 50 years from now people will be doing their computing on 32/64/128/256 bit machines? Or even Von-Neumann machines? With Unix as the operating system? Just think: 50 years ago they were still sending messages through naked runners (no - not quite, but almost that primitive!) PS. There is a rumor that PDP-11's have been microcoded to self destruct one minute before the year 2000. I also hope that I am alive 50 years from today to witness the computing of that time! -- "I care about my fellow man {) badri@ee.rochester.edu Being taken for a ride, //\\ {ames,cmcl2,columbia,cornell, I care that things start changing ///\\\ garp,harvard,ll-xn,rutgers}! But there's no one on my side."-UB40 _||_ rochester!ur-valhalla!badri
cramer@optilink.UUCP (Clayton Cramer) (06/02/89)
In article <534@bnr-fos.UUCP>, dgibbs@bnr-fos.UUCP (David Gibbs) writes: > In article <1989May30.155016.11099@utzoo.uucp> henry@utzoo.uucp (Henry Spencer) writes: > > > >What will happen when the 32-bit Unix date goes negative in mid-January > >2038 does not bear thinking about... :-) > >-- > Nothing of course, because nobody (but nobody) will be using piddly little > 32-bit machines in 2038. > > -David Gibbs Nonsense. All 32-bit machines will be used in the Third World by then. As a consequence, all those dates going negative will cause the collapse of their economies. Once again, the racist, sexist, ageist, imperialist conspiracy will crush the suffering oppressed countries of the Third World. :-):-) -- Clayton E. Cramer {pyramid,pixar,tekbspa}!optilink!cramer "He chose...poorly." -- Indiana Jones & The Last Crusade ---------------------------------------------------------------------------- Disclaimer? You must be kidding! No company would hold opinions like mine!
cramer@optilink.UUCP (Clayton Cramer) (06/02/89)
In article <1989May30.155016.11099@utzoo.uucp>, henry@utzoo.uucp (Henry Spencer) writes: > In article <107107@sun.Eng.Sun.COM> jamesa@arabian.Sun.COM (James D. Allen) writes: # ## The mind boggles at how many programs had to be fixed to know about the # ## new year numbering... # # # #Are you sure? Even the most loyal of Japanese programmers should have # #anticipated outliving the aging emperor... # # Even the stupidest of North American programmers should anticipate that the # first two digits of the year will change not too far in the future... but # in fact often this gets botched. Forecasting programs are already running # into this: 1975 was a bad year for 25-year forecasts, and 1990 will most # probably be a rough year for 10-year forecasts. The chaos in 2000 AD will # be something to behold. # # What will happen when the 32-bit Unix date goes negative in mid-January # 2038 does not bear thinking about... :-) # -- # Van Allen, adj: pertaining to | Henry Spencer at U of Toronto Zoology Even the stupidest should -- but when I raised this issue in a meeting a couple of years ago, people laughed! They thought I was making a joke! Especially since our equipment will have a very, very long lifetime, this is an important issue. After the Wall Street Journal carried an article about "Doomsday" and its effect on data processing, people started to take the subject seriously. I sure hope that I have retired from computers before 2000 -- all hell is going to break loose, if people aren't already planning to bring on battalions of maintenance programmers to go looking for year dependencies -- especially those sticky situations where someone sorts by 2-digit year, and uses all the available characters in a filename with the year included. -- Clayton E. Cramer {pyramid,pixar,tekbspa}!optilink!cramer "He chose...poorly." -- Indiana Jones & The Last Crusade ---------------------------------------------------------------------------- Disclaimer? You must be kidding! No company would hold opinions like mine!
peter@ficc.uu.net (Peter da Silva) (06/02/89)
Charlie Geyer <charlie@mica.stat.washington.edu> in <1474@uw-entropy.ms.washington.edu>: > David Gibbs in article <534@bnr-fos.UUCP> dgibbs@bcars115.UUCP: > > nobody (but nobody) will be using piddly little 32-bit machines in 2038. > To which Henry replies [ pdp-8s still in use ] > > Dream on ... :-) The transition from 32 to 64 is going to be long > > and painful; I predict that there will still be plenty of 32-bit > > machines serving in secondary roles in 2038. > What's more, the 64 bit hardware will all be running 32 bit software. > Count on it. 2038 is nearly 50 years away. PDP-8s were a going concern 20 years ago and still any remaining ones are hanging on by the ragged edge. Sure, you'll still see a fair number of 32-bit machines 20 years from now, but 64-bit machines with 64-bit software will be on the rise. In 50 years... who knows. I really doubt if there will be *plenty* of 32-bit machines... maybe as embedded controllers along with 8- and 16- bit micros (see, for example, _Across Realtime_ by Vernor Vinge), but I suspect that 64-bit machines will be on the way out. Of course, there's always the possibility that in 50 years computing will be done by teams of scribes. "Nuclear war can ruin your whole compile" -- Karl Lehenbauer. -- Peter da Silva, Xenix Support, Ferranti International Controls Corporation. Business: uunet.uu.net!ficc!peter, peter@ficc.uu.net, +1 713 274 5180. Personal: ...!texbell!sugar!peter, peter@sugar.hackercorp.com.
desnoyer@Apple.COM (Peter Desnoyers) (06/03/89)
In article <4384@ficc.uu.net> peter@ficc.uu.net (Peter da Silva) writes: > [32 bits will be around in 50 years. No it won't. Yes it will ...] > >2038 is nearly 50 years away. PDP-8s were a going concern 20 years ago >and still any remaining ones are hanging on by the ragged edge. I have heard that a lot of bank ATMs are controlled by PDP-8s. Can anyone with better knowledge than be confirm/deny this rumor? (Or are they all on IBM mainframes connected to private SNA networks? :-) Peter Desnoyers
d88-jwa@nada.kth.se (Jon W{tte) (06/03/89)
In article <4384@ficc.uu.net> peter@ficc.uu.net (Peter da Silva) writes: >still see a fair number of 32-bit machines 20 years from now, but 64-bit >machines with 64-bit software will be on the rise. In 50 years... who knows. >_Across Realtime_ by Vernor Vinge), but I suspect that 64-bit machines will >be on the way out. So, if computers have stuck with 32 bits for n years, are there not chances that computers will do so for another n years ? And the dawn of parallell cube machines suggest that computing power is increased through new architectures, not through more bits in the registers. Of course, IF Unix (TM of AT&T, isn't it ?) is still around at 2038, I think THAT implementation will take care of the 32-bit problem... Especially since this meeting ALREADY is suggesting something is done about this problem. >Peter da Silva, Xenix Support, Ferranti International Controls Corporation. -- __ Jon W{tte (The dread Smiley Shark) email:h+@nada.kth.se / \ (+46 (0) 8 258 268) /--- (c) 1989 Yessbox Allright Professional Products Inc. - Y.A.P.P.I. / -- No More --
erict@flatline.UUCP (J. Eric Townsend) (06/04/89)
In article <32220@apple.Apple.COM> desnoyer@Apple.COM (Peter Desnoyers) writes: >I have heard that a lot of bank ATMs are controlled by PDP-8s. Can >anyone with better knowledge than be confirm/deny this rumor? (Or are >they all on IBM mainframes connected to private SNA networks? :-) I used to work for Integrated BancSystems, a company that produced banking software. We played around with Diebold equipment that was used as ATM servers (we were thinking about expanding). The Diebold box we got the most use of was a 8-something-86 box running iRMX (or something like that). Basically, it was a very small, very underpowered multi-tasking system that could do nothing but drive ATMs. Also, most Circle-K's have Diebold-brand ATMs these days, so I'd guess that a large chunk of the ATM servers are Diebold boxes with Intel chips. Might as well be PDP-8s... :-) -- "I'm chronically unable to enjoy most formula fiction, be it by Larry Niven, Norman Mailer or Margaret Drabble." -- Michael Moorcock. J. Eric Townsend Inet: <temporarily disabled> 511 Parker #2 Houston,Tx,77007 EastEnders Mailing List: eastender@flatline.UUCP
peter@ficc.uu.net (Peter da Silva) (06/05/89)
In article <1158@draken.nada.kth.se>, d88-jwa@nada.kth.se (Jon We"tte) writes: > In article <4384@ficc.uu.net> peter@ficc.uu.net (Peter da Silva) writes: > >still see a fair number of 32-bit machines 20 years from now, but 64-bit > >machines with 64-bit software will be on the rise. In 50 years... I > >suspect that 64-bit machines will be on the way out. > So, if computers have stuck with 32 bits for n years, are there not > chances that computers will do so for another n years ? Sure, but we're talking about 2.5 * n years here. -- Peter da Silva, Xenix Support, Ferranti International Controls Corporation. Business: uunet.uu.net!ficc!peter, peter@ficc.uu.net, +1 713 274 5180. Personal: ...!texbell!sugar!peter, peter@sugar.hackercorp.com.
diamond@csl.sony.co.jp (Norman Diamond) (06/05/89)
Does anyone else get "interp buffer overflow" trying to follow-up to a message like this: References: <234@zeek.UUCP> <322@xdos.UUCP> <FLEE.89May22191959@shire.cs.psu.edu> <1989May29.232954.25638@utzoo.uucp> <107107@sun.Eng.Sun.COM> <1989May30.155016.11099@utzoo.uucp> <534@bnr-fos.UUCP> <1989Jun1.160913.8849@utzoo.uucp> <1474@uw-entropy.ms.was Does anyone else get ".newsrc restored" and find that their .newsrc is not restored? Well, it's slightly better than having to skip past the 30 preceding comp.lang.c articles again. Anyway... Henry Spencer: >> Dream on ... :-) The transition from 32 to 64 is going to be long >> and painful; I predict that there will still be plenty of 32-bit >> machines serving in secondary roles in 2038. Charlie Geyer in article <1474@uw-entropy.ms.washington.edu>: >What's more, the 64 bit hardware will all be running 32 bit software. >Count on it. Badri Lokanathan: >Are you guys serious? Do you actually think that 50 years from now >people will be doing their computing on 32/64/128/256 bit machines? >Or even Von-Neumann machines? With Unix as the operating system? Are you serious, Mr. Lokanathan? Did anyone believe that a mainframe operating system would still be in use 25 years later? And if that's not enough, consider this: No one, but no one, wants to be seen using a 10-year-old piece of hardware. Sure, they'll use them in secondary roles, but no one wants to be seen using them. But a 20-year-old operating system is another story. Everyone wants to run a 20-year-old operating system with their 3-year-old workstation, bitmapped screen, network, and megabytes of RAM. No one wants to use an operating system newer than that, even though a few of the newer ones are better. This kind of attitude isn't going to change in the next 50 years either. Oh there are exceptions of course, for instance I prefer a certain 10-year-old operating system and a certain 5-year-old one, and would be interested in watching a few others that are now under development. But such preferences are risky to careers, and should be kept quiet. -- Norman Diamond, Sony Computer Science Lab (diamond%csl.sony.co.jp@relay.cs.net) The above opinions are my own. | Why are programmers criticized for If they're also your opinions, | re-implementing the wheel, when car you're infringing my copyright. | manufacturers are praised for it?
mcdonald@uxe.cso.uiuc.edu (06/06/89)
>I have heard that a lot of bank ATMs are controlled by PDP-8s. Can >anyone with better knowledge than be confirm/deny this rumor? (Or are >they all on IBM mainframes connected to private SNA networks? :-) I have no knowledge, but one comforting thought: a lot of PDP-8 software used triple precision (36bits)! I know mine did. And, since the biggest number added at one time was 4096, the DMA hardware and a few gates took care of all the overflow automatically! Doug McDonald
bradb@ai.toronto.edu (Brad Brown) (06/09/89)
In article <32220@apple.Apple.COM> desnoyer@Apple.COM (Peter Desnoyers) writes: > >I have heard that a lot of bank ATMs are controlled by PDP-8s. Can >anyone with better knowledge than be confirm/deny this rumor? (Or are >they all on IBM mainframes connected to private SNA networks? :-) I'm told by someone who works for CIBC (Canadian Imperial Bank of Commerce) that at least most of the ATMs currently being shipped by IBM are controlled by what is essentially an AT -- that is, it's an AT motherboard and it uses IBM format 1.2MB floppy disks, at least for IPL. BTW, the new IBM 4800 series POS (Point of Sale) terminals are controlled by AT motherboards or a close derivative, too. (-: Brad Brown :-) bradb@ai.utoronto.ca