test-drb

test-drb@ccmp.vtda.org

101090 discussions

by lbickley＠bickleywest.com

There's what looks to be a nice collection of IBM Mainframe goodies on eBay: http://www.ebay.com/itm/Vintage-IBM-Computer-Mainframe-Lot-with-2-printers-… or Item #161566683205 Local Pickup, Huntington, New York NOT my listing - just "stumbled" across it today Cheers, Lyle -- Bickley Consulting West Inc. http://bickleywest.com "Black holes are where God is dividing by zero"

11 years, 6 months

Operating systems of the 1970s handling dates beyond the year 2000

by cctalk＠beyondthepale.ie

> >> After trying to get Unix v5 to understand dates beyond the year 2000 I >> had to wonder if any of the older operating systems from the 1970s or >> older could do this. >> >> So, did any operating system programmers from this time period have >> the foresight to use 4 digits for the year? I just checked APL/360 and >> it seems that it does not. >> > > TOPS-20? VMS? > It was very near the end of the 1970s but VMS made a really good effort to handle times and dates well from the beginning. A single 64 bit time format is used throughout the operating system and operating system routines are provided to manipulate it and convert to and from well chosen standardised display formats with no ambiguities such as two digit years or easily mixed up numbers for days and months. Everything [*] displays and accepts the same time and date formats and shortcuts such as YESTERDAY, TODAY and TOMORROW. No messing about trying to figure out what format a particular utility wants the date specified in and no wondering whether a unitless time displayed by something is days, hours or minutes. The areas where I think it could have been done better still are to have stored the time internally in UTC rather than local time while displaying local time and to have chosen an earlier base date than 17 November 1858. Also, there was originally a rule that time differences could not be larger than 10000 days which was poorly enforced and eventually had to be scrapped - this should have been handled much more gracefully. [*] A few system parameters are specified in seconds and TIMEPROMPTWAIT is specified in microfortnights with tongue in cheek. Regards, Peter Coghlan.

11 years, 6 months

Operating systems of the 1970s handling dates beyond the year 2000

by johnwallace4＠yahoo.co.uk

"an *awesome* cover letter that DEC sent out with the fix, assuring everyone that the libraries were now good internally until some crazy year like 31078, but there was still formatting code that assumed years fit in four digits so there would be Y10K bugs; but don't worry, DEC will issue a patch to VMS at that time." Sounds a little bit like (but maybe not identical with?) the well known Stan Rabinowicz Leap Year Software Performance Report (SPR) response in 1983 for VMS V3.2? Stashed in various places which search engines should find, currently including HP's website and http://www-users.cs.york.ac.uk/susan/joke/decly.htm Have a lot of fun John

11 years, 6 months

Operating systems of the 1970s handling dates beyond the year 2000

by jnc＠mercury.lcs.mit.edu

> From: Mark Longridge > I had to wonder if any of the older operating systems from the 1970s or > older could do this. > So, did any operating system programmers from this time period have > the foresight to use 4 digits for the year? It's probably worth distinguishing between the internal clock, the ability to set dates > 1999, the ability to print dates > 1999, etc. For instance, both Multics and Unix had an internal clock that ran correctly past the century end. (Although they do run out / roll over not too much later - in Multics' case, in 2039. For the Multics one, see here: http://www.multicians.org/jhs-clock.html for more.) However, in the case of Unix, both date setting and the canonical routine for date printing (separate code) didn't handle dates after 1999; for input, the year was only two digits, and for output, the first two digits were hard-coded to '19'. However, for calculating dates (which returned a vector of numbers), that part did theoretically work correctly for years after 1999 (it returned [$YEAR-1970]), but... There was a separate bug that caused the year calculation to fail in the closing months of 1999. Whether the person who wrote the code knew of the bug - it's a fairly simple one, an overflow of a short integer - I don't know, but it's possible they did, and on calculating when it would happen, decided that the fact that it would coincidentally also happen at century end meant it could be ignored at that point. However, once that was fixed, the date calcuation routine returned the correct year (without needing to change the interface). I don't know whether date input/calculation/output on Multics had similar issues: if you google "Multics leap year" it shows the source code for a couple of routines dealing with dates, but alas it's all in 645/6180 assembler, so I can't really grok it! It looks like it _might_ work, though (it seems to calculate the number of years since Multics' epoch - 1901 - and add that to 1901). If I had more time to expend, I could look at ITS too... :-( Noel

11 years, 6 months

the old VHS series on the history of computing

by sales＠elecplus.com

http://waxy.org/2008/06/the_machine_that_changed_the_world/ He found all 5 episodes, digitized them, and uploaded them. Cindy Croxton

11 years, 6 months

Sending 0377 via KL8JA

by cctalk＠beyondthepale.ie

> >I am noticing something odd in SimH when sending a 0377 (all ones) >character. It seems to be duplicating the byte. I haven't read anything >regarding this behavior. I'm away from my hardware PDP-8 at the moment, so >I can't confirm that this is not the behavior that I would experience on >the real thing. > It's not really that clear whether a telnet type connection is in use here but could it be something that does telnet negotiation is sending data to something which is not telnet negotiation aware? 0377 octal (FF hex) corresponds to IAC which would get sent as IAC IAC. Maybe monitoring the data on the network would confirm? > >Run 'nc localhost 2222 | od -to1' in a terminal, then 'go 200' and >repeatedly press 'c', seeing how many times it takes to generate a line of >characters in 'od'. Then, 'd sr 0376' and confirm that it takes twice as >many presses, indicating half as many characters being sent per TLS >instruction with the latter. > >Can anyone else confirm this for me? > Sorry - I don't follow that at all and figuring it out is probably above my pay grade :-) Regards, Peter Coghlan.

11 years, 6 months

more documentation...

by useddec＠gmail.com

I just looking for offers + shipping. Please contact me off list for more info or questions. I told Al he could have whatever he wants for free and I would pay shipping. Al, I hate typing, please take it all... NCR 801-0009975 801-0009981 powertec inc for GDI 3m lups module crt Buscher 0l400-3015r/4015r fisher controls type cp250 model sps-1878a allen-bradley 635344 ps cdc 83322310 54359803, maybe others... computer products (unipower) pwr div 800w multiple sc001-1442 MISC PWR SUPPLIES: tryger electronics uaro lear siegler GE century data condor Thanks, Paul

11 years, 6 months

TMS9918 (was Re: Seeking... TI TMS9902 ICs)

by spacewar＠gmail.com

On Sat, Jan 17, 2015 at 9:22 PM, Randy Dawson <rdawson16 at hotmail.com> wrote: > Later found their video chip 9918 Speaking of which, does anyone have the data sheet and/or user manual for the original TMS9918, *NOT* the improved 9918A? All my internet searches that turn up 9918 without an A suffix are in fact actually for the A part.

11 years, 6 months

Mystery ICs - AB 36D1024

by drlegendre＠gmail.com

Can't search up any data on these chips, they're marked with the Allen Bradley logo, and the code is 36D1024. Date codes are mid-1974. I have about 30 pcs. of them. But what are they?

11 years, 6 months

Shipping antique computers

by marc.verdiell＠gmail.com

Wow. Nice collection in a nice setting. I love the view of your commute. Where is your new shop located, still near Silicon Valley (near me ;-) )? Marc >Date: Sat, 17 Jan 2015 10:07:53 -0800 >From: Guy Sotomayor <ggs at shiresoft.com> >Here are some pictures of the stuff after I've moved it into my new shop but still on the pallets: >http://www.shiresoft.com/new-shop/Shiresoft/Almost_moved.html. > >TTFN - Guy

11 years, 6 months

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

1998

1997

test-drb