| Re: The ICL 2900 [message #338407 is a reply to message #338229] |
Sat, 25 February 2017 10:29   |
jmfbahciv
Messages: 6173
Registered: March 2012
Karma: 0
|
Senior Member |
|
|
Morten Reistad wrote:
> In article <PM00054932A0B00D6A@aca41e2b.ipt.aol.com>,
> jmfbahciv <See.above@aol.com> wrote:
>> capek@ieee.org <Peter Capek> wrote:
>>> On Saturday, February 18, 2017 at 8:52:58 AM UTC-5, jmfbahciv wrote:
>>>> Questor wrote:
>>>> > On 15 Feb 2017 16:48:56 GMT, Huge <Huge@nowhere.much.invalid> wrote:
>>>> >>On 2017-02-15, Scott Lurndal <scott@slp53.sl.home> wrote:
>>>> >>> jmfbahciv <See.above@aol.com> writes:
>>>> >>
>>>> >>[20 lines snipped]
>>>> >>>>
>>>> >>>>This kind of computer usage was not the norm.
>>>> >>>
>>>> >>> Huh? It was quite the norm from mainframes to departmental servers.
>>>> >>
>>>> >>Babs has a remarkable parochial view of how the computer industry
works.
>>>> >
>>>> > Ms. Huizenga has not been entirely candid about her work at DEC. She
has
>>>> used
>>>> > circumlocution and misdirection to obscure her true role. Most of the
>> time
>>>> when
>>>> > she talks about what "we" did, it should be taken and read as what
"they"
>>>> did.
>>>> > There's a reason for the obvious gaps in her technical knowledge and
her
>>>> focus
>>>> > on process.
>>>> >
>>>> > With regard to "parochial," literally her entire career was spent
working
>> in
>>>> the
>>>> > TOPS-10 group. Just about everything she knows about other computers
and
>>>> > operating systems is through the lens of how they relate to PDP-10s and
>>>> TOPS-10.
>>>> > Her lack of formal training and breadth of experience shows up in not
>> having
>>>> the
>>>> > abstractions and generalizations that would ease learning a new
>> environment,
>>>> > such as UNIX, Instead, she tries to put everything into a TOPS-10 box.
>>>> >
>>>> You don't know anything about what I did at DEC.
>>>>
>>>> /BAH
>>>
>>> I don't either. Why don't you tell us? I'm interested to know.
>>
>> Morten covered the work I was paid to do in another post. I also
>> did a lot of work I wasn't paid to do.
>>
>> /BAH
>
> I only have rudimentary information about what you did at DEC (and when you
> did what) . I would welcome a brief autobiography.
I'll give you the jobs I was paid to do. Note that I was always working on
other projects not approved by management which would increase the
efficiency of produding hard/software products.
Tape Prep - create everyone's code, documents, specs, and memos
in machine lanugage of some flavor (includes RUNOFF). I became
a group leader of the documentation prep group when the Tape Prep
was logically split into 3 groups. The work produced RUNOFF
manuals across all product lines. I had 3 people, plus myself,
doing the typing plus I was responsible for scheduling the work
and ensuring that the jobs were done on time. There was usually
a backlog of 15-20 manuals, 5 were new manuals and the rest would
be updates to manuals. A job could take anywhere from 3 to 25
or 30 hours to complete. Some had deadlines of yesterday; most
had deadlines of 2 weeks; a few had deadlines of a month or two.
Side non-paying projects was working on developing a typesetting
lanugage so we weren't hogtied by RUNOFF; convincing writes
to have all of their work put into manchine-readable format.
When I started about 75% of manuals were typed on a typewriter.
By the time I left, 25% were still done with a typewriter.
The lag distribution time of getting a manual done on a typewriter
w.r.t. the software it described was 1-2 years. Getting the
manuals into machine-readable format reduced the lag by 2 years.
Distribution was within a few months after software distribution.
Eventually part of the ship criteria was having the documentation
shipped with the software. It took about 8 years for this
reduction of timing to be completed. I didn't do all the work;
I just started it by changing attitudes, hidden assumptions
and convincing management that documentation was just as
important as the hard/software.
There were other, smaller projects which were completed during
this time.
This was the first job I was paid to do. I'll try to write
up the next one in another post.
/BAH
|
|
|
|
| Re: The ICL 2900 [message #338408 is a reply to message #338336] |
Sat, 25 February 2017 10:29 |
jmfbahciv
Messages: 6173
Registered: March 2012
Karma: 0
|
Senior Member |
|
|
William Pechter wrote:
> In article <5EYrA.17429$2F2.16618@fx22.iad>,
> Scott Lurndal <slp53@pacbell.net> wrote:
>> Morten Reistad <first@last.name.invalid> writes:
>>> In article <PM0005494742EE1C35@aca46ce8.ipt.aol.com>,
>>> jmfbahciv <See.above@aol.com> wrote:
>>
>>>> OK. So I've that concept correct. What are the minuses of having the
>>>> controller software in the disk rather than the kernal?
>>>
>>> They are in the kernal too, only used as a very last resort.
>>
>> No, there is no "disk controller" software in any kernel (Windows, Unix
>> or Linux). There is a driver for the host adapter which arranges
>> for command and data to be transferred from the drive. There is no
>> software in the kernel to replace the functionality of the drive
>> electronics.
>>
>> The protocols (SCSI, SATA, USB Block Storage) do provide mechanisms
>> (e.g. SCSI Mode Pages, ATAPI) for the
>> host to _influence_ the drive software by specifying performance
>> or other desired characteristics and to extract diagnostic information
>> from the drive, but it is not possible to replace e.g. the on-drive
>> scheduling algorithm.
>>
>>>
>>> The controller on the disk runs a realtime job, managing the heads, the
>>> actuators, the write and read operations and the comms to and from the
>>> next controller closer to the CPU.
>>
>> Comms is misleading in this context, particularly for your
>> respondent. While the SAS/SATA connections are serial, they're
>> not comms in the PDP-10 sense. It's the same protocol that runs
>> on the parallel (e.g. SCSI, pATA) interface serialized onto a pair
>> of wires.
>>
>
> Not really. Unlike the old days where you accessed by Cyl, Head, Sector
> and had to block out bad sectors manually... you're pretty much
> getting blocks of storage by a data comm protocol.
>
> When I first saw this in Digital Storage Architecture back in 85 or so
> I looked at the HSC50 and UDA50A and described the process
> of talking to intelligent (rather than blissfully stupid) disk drives
> with the words -- "Ah, DECnet for disk drives."
Yup. I had reservations about allowing a disk drive do all that work;
TW had enormous problems allowing the disk drives to do all that work.
He'd been writing the controller and device service routines for
TOPS-10 since 1966. It was a struggle to cede control for him.
>
> When the drives do things like bad block revectoring and disk location
> mapping of sectors to a unified piece of storage whos sector
> count vary by location -- it looks to old timers like things
> that are blatantly NON-DISK like actions.
It sure is a hell of a lot of code to lay bits on a platter. ;-)
/BAH
|
|
|
|
| Re: The ICL 2900 [message #338409 is a reply to message #338332] |
Sat, 25 February 2017 10:29 |
jmfbahciv
Messages: 6173
Registered: March 2012
Karma: 0
|
Senior Member |
|
|
William Pechter wrote:
> In article <PM0005494751A6CC32@aca46ce8.ipt.aol.com>,
> jmfbahciv <See.above@aol.com> wrote:
>> William Pechter wrote:
>>> In article <PM0005493306541D4F@aca41e2b.ipt.aol.com>,
>>> jmfbahciv <See.above@aol.com> wrote:
>>>> William Pechter wrote:
>>>> > In article <PM0005491E9D353FCC@aca480e6.ipt.aol.com>,
>>>> > jmfbahciv <See.above@aol.com> wrote:
>>>> >
>>>> >>Aren't today's controllers a part of the disk drive? So there's no
longer
>>>> >>one controller for many drives.
>>>> >>
>>>> >>/BAH
>>>> >
>>>> > Nope... except for the older IDE drive where the controller was a pretty
>>>> > small bus interface.
>>>> >
>>>> > There's still the need for the thing that connects the drive to the I/O
>> bus.
>>>> > Much of the logic now is kind of like the stuff DEC did for DSA (Digital
>>>> > Storage Architecture).
>>>> >
>>>> > The disks are smart devices talking some kind of data protocol to the
>> system
>>>> > via a controller.
>>>> >
>>>> > The disks are addressed by logical blocks and no longer Cylinder, Head
and
>>>> > Sector. The physical geometry is no longer tied to the disk software
>>>> > geometry.
>>>>
>>>> Somebody has to do the physcial-logical mapping. I figured it was part of
>>>> the [what I would think of as] the disk drive.
>>>>
>>>> >
>>>> > (This has had effects on some of the low level format and partition
layout
>>>> > software...like the BSD Disklabels).
>>>> >
>>>> > This change, as far as I know, started back in the 80's with DEC RA
drives
>>>> > and DSA as well as the SASI/SCSI stuff which was also becoming a
standard
>>>> > at the same time.
>>>>
>>>> Yes to the DEC RAs. TW worte that code for the PDP-10s; it used a
>>>> comm spec similar to DECnet's approach. We did not like them
>>>> because the disks were no availabe for booting the system. Another
>>>> design flaw. another design flaw was the number of ports; it was
>>>> still 2.
>>>>
>>>>
>>>> >
>>>> > The SCSI stuff was then kind of the grandfather of the stuff that
>>>> > started in the ATA (also called IDE drives) subsystem which became
>>>> > the SATA subsystem when they went from parallel to serial connections
>>>> > (which DEC did on the UDA's/HSC's and RA series back in the 80's.)
>>>> >
>>>> > Seems to me the cables even look a bit alike... just smaller.
>>>>
>>>> /BAH
>>>
>>> They were bootable on the VAX and PDP11. And there was not a 2 port
>>> restriction on anything.
>>>
>>> I thought they used the HSC50 and star coupler for connectivity.
>>
>> The HSC-50 couldn't be used as the frontend.
>
> Ah, crap. The lack of HSC Support on the PDP11 and the lack of UDA50
> support on the KL.
>
> Damn. The disk drives were completely dual ported by design and
> all they needed was controllers on both the KL and the PDP.
The disk hardware guys rarely asked software before they finished their
initial specs. It would not have been a lot of work but anything
promoting PDP-10s was verboten even though the PDP-10 business was
becoming cash cow by that time.
>
>
>>>
>>> Anyone know about the KL connection to the HSC50. Too bad there wasn't
>>> support for the UDA50 on the KS10.
>>>
>>> Or was there?
>>
>> It's not a familiar term so probably not. YOu have to remember that no more
>> development was allowed after 1983. The HSC was an exception to the rule
>> because ADP and a couple other customers wanted it.
>
>
> Yup... They could've put a controller in the 11/40 and one on the KL.
> Don't know if you can dual port between HSC50 and UDA50A -- anyone out there
> have an answer to if the software would work?
>
> In theory the RA should be dual-accessable from both. They had 18 bit
> RA60's you said so that could be the RP06 dual ported drive replacement.
We used them for our black packs. At least the disk people included
mountable packs for that device.
>
>>> (Youtube just made me bite my tongue. Damn BSDNow podcast just mentioned
>>> porting VMS from ia64 to amd64. They were kind of joking about it.
>>> Too bad some folks never had the exposure to the slick things that exist
>>> under VMS including real clusters.)
>>>
>>> Bill
>>
>> I think it's too bad enough people didn't get exposure to the TOPS-20
>> user interface.
>>
>> /BAH
>
> I did but it was pretty cumbersome over a 1200 or 2400 baud modem
> through a micom data switch to a VAX through Decnet to market 20 to run
kermit
> all the way back through to my house...
That would suck. TOPS-10 would have worked better. TOPS-20 was verbose.
>
> Working night shift was better -- I could take my computer to the office,
yank
> the VT100's micom cable and be online at 9600 baud if no one broke anything
> before midnight. I pretty much was downloading a ton of Simtel-20's stuff
> and filling floppies on slow nights and when I got snowed in at DEC once.
Getting snowed in at the plant was not a hardship unless one wanted beer.
/BAH
|
|
|
|
| Re: The ICL 2900 [message #338410 is a reply to message #338312] |
Sat, 25 February 2017 10:29 |
jmfbahciv
Messages: 6173
Registered: March 2012
Karma: 0
|
Senior Member |
|
|
Lawrence Statton NK1G wrote:
> jmfbahciv <See.above@aol.com> writes:
>> Bill Findlay wrote:
>>> Mike Spencer <mds@bogus.nodomain.nowhere> wrote:
>>>>
>>>> Jon Elson <jmelson@wustl.edu> writes:
>>>>
>>>> > William Pechter wrote:
>>>> >
>>>> >
>>>> >> As long as the toilets don't back up. I can take the clothes out
>>>> >> to a laundromat if needed.
>>>> >
>>>> > Oh, boy! When they hook the IoT to the toilets, then the hackers
>>>> > will REALLY start to have fun (= create chaos). Oh, I just CAN'T
>>>> > wait for that!
>>>>
>>>> "Funny once." [Moon is a Harsh Mistress.]
>>>>
>>>> I once had some fun, before we had electricity, leading on a guy who
>>>> wanted to sell us a vacuum cleaner. I can't wait for somebody who
>>>> wants to connect out outhouse to the internet.
>>>
>>> There is a book of photographs of Nova Scotian outhouses.
>>> Do you know it? Some of the pictures are very beautiful.
>>>
>> I was 15 the last time I used an outhouse.
>>
>> /BAH
>
> It's been 77 days since I used an outhouse. (My friends' who live in
> the country).
Kewl ;-) How often to they have to dig a new one?
/BAH
|
|
|
|
| Re: The ICL 2900 [message #338411 is a reply to message #338406] |
Sat, 25 February 2017 10:29 |
jmfbahciv
Messages: 6173
Registered: March 2012
Karma: 0
|
Senior Member |
|
|
JimP. wrote:
> On 25 Feb 2017 11:51:26 GMT, Huge <Huge@nowhere.much.invalid> wrote:
>
>> On 2017-02-25, Ahem A Rivet's Shot <steveo@eircom.net> wrote:
>>> On 24 Feb 2017 21:30:51 GMT
>>> Bill Findlay <findlaybill@blueyonder.co.uk > wrote:
>>>
>>>> Ahem A Rivet's Shot <steveo@eircom.net> wrote:
>>>> > On 24 Feb 2017 02:42:39 GMT
>>>> > Bill Findlay <findlaybill@blueyonder.co.uk > wrote:
>>>
>>>> >> There is no need for a trained sysadmin.
>>>> >
>>>> > There are a surprisingly large number of people making a living
>>>> > out of digging people out of the messes they manage to get into with
>>>> > their PCs and Macs. To me this indicates that a trained sysadmin would
>>>> > be beneficial.
>>>>
>>>> Numbers? Pro rata to system types?
>>>
>>> I've not done a census, but there's at least one in every small
>>> town hereabouts - it's easier to find someone to fix a PC than it is to
>>> find someone to cut a key.
>>
>> Ditto where I live in South Norfolk. One place cuts keys, there are
>> half-a-dozen PC menders.
>
> Wally world has automatic key cutters. Plug the key into the device,
> it scans the key, asks you to select a standard or colorful blank, you
> pay, it cuts new key. I don't think it does car keys.
Nor small keys. The key cutting business now seems to have devolved
into one size fits all. It was impossible for me to get copies
for the outside door lock of my Southboro house because key cutters
didn't have blanks that size. Now I buy a new lock instead of
getting copies of the key for the current lock on my fence.
/BAH
|
|
|
|
| Re: The ICL 2900 [message #338412 is a reply to message #338328] |
Sat, 25 February 2017 10:29 |
jmfbahciv
Messages: 6173
Registered: March 2012
Karma: 0
|
Senior Member |
|
|
William Pechter wrote:
> In article <PM000549475BFDCC4C@aca46ce8.ipt.aol.com>,
> jmfbahciv <See.above@aol.com> wrote:
>> William Pechter wrote:
>>> In article <PM0005493284D694EC@aca41e2b.ipt.aol.com>,
>>> jmfbahciv <See.above@aol.com> wrote:
>>>
>>>> I'm quite proficient learning new OSes. There are no books which
>>>> train new system owners. Part of the problem is that there is no
>>>> common user interface because of the shell concept. I'd like to
>>>> see the command language which is underneath those shells.
>>>>
>>>> /BAH
>>>
>>>
>>> Actually, there are books. Written by professionals with PHd's and
>> experience.
>>> One of whom set up the corporate training at a prior employer.
>>>
>>> PDF's were on the laptop I sent. They're often slightly out of date
>>> since Linux changes so quickly. But they do work well as a guide.
>>> I used them (earlier edition) back in '84 or so...
>>
>> Ah, I didn't find those. I'll look for them the next time I play
>> with the system. Taxes are taking the priority for the next 2 months
>>
>>
>> /BAH
>
> Understand the taxes stuff. Got my own to start on, and the kids.
> When I hire someone to do 'em they seem to screw up.
>
> Turbo Tax is my friend on this.
JMF used Turbo Tax once; I checked his forms and discovered that TT
couldn't do arithmetic. So he didn't buy it again. I do all of
mine "by hand". I've discovered that brokerages' software is
screwed up. They round monthly instead of keeping running
Fn.4 totals. So the numbers they report to the IRS are always
off by a couple of dollars for cost basis calculations.
/BAH
|
|
|
|
| Re: The ICL 2900 [message #338413 is a reply to message #338316] |
Sat, 25 February 2017 10:29 |
jmfbahciv
Messages: 6173
Registered: March 2012
Karma: 0
|
Senior Member |
|
|
Morten Reistad wrote:
> In article <PM0005494742EE1C35@aca46ce8.ipt.aol.com>,
> jmfbahciv <See.above@aol.com> wrote:
>> Morten Reistad wrote:
>>> In article <PM0005493306541D4F@aca41e2b.ipt.aol.com>,
>>> jmfbahciv <See.above@aol.com> wrote:
>>>> William Pechter wrote:
>>>> > In article <PM0005491E9D353FCC@aca480e6.ipt.aol.com>,
>>>> > jmfbahciv <See.above@aol.com> wrote:
>>>> >
>>>> >>Aren't today's controllers a part of the disk drive? So there's no
longer
>>>> >>one controller for many drives.
>>>> >>
>>>> >>/BAH
>>>> >
>>>> > Nope... except for the older IDE drive where the controller was a pretty
>>>> > small bus interface.
>>>> >
>>>> > There's still the need for the thing that connects the drive to the I/O
>> bus.
>>>> > Much of the logic now is kind of like the stuff DEC did for DSA (Digital
>>>> > Storage Architecture).
>>>> >
>>>> > The disks are smart devices talking some kind of data protocol to the
>> system
>>>> > via a controller.
>>>> >
>>>> > The disks are addressed by logical blocks and no longer Cylinder, Head
and
>>>> > Sector. The physical geometry is no longer tied to the disk software
>>>> > geometry.
>>>>
>>>> Somebody has to do the physcial-logical mapping. I figured it was part of
>>>> the [what I would think of as] the disk drive.
>>>
>>> This (and the badspot, block moving and renaming etc) is all done in the
>>> firmware of the "disk". Actually, the IBMism "DASD" becomes more fitting
as
>>> time goes on.
>>
>> OK. So I've that concept correct. What are the minuses of having the
>> controller software in the disk rather than the kernal?
>
> They are in the kernal too, only used as a very last resort.
>
> The controller on the disk runs a realtime job, managing the heads, the
> actuators, the write and read operations and the comms to and from the
> next controller closer to the CPU.
>
> It can do sector remapping from bad sectors, and have some (~1-5%) of
> the space on the disk set off for this. Modern disks always come with
> quite a bit of bad sectors, but they are hidden by the controller.
>
> And, yes, it is comms. It is almost exclusively serial these days, and
> have a comms protocol on top.
>
> This controller does all the stuff that needs to know the hardware closely.
>
>>>> > (This has had effects on some of the low level format and partition
layout
>>>> > software...like the BSD Disklabels).
>>>> >
>>>> > This change, as far as I know, started back in the 80's with DEC RA
drives
>>>> > and DSA as well as the SASI/SCSI stuff which was also becoming a
standard
>>>> > at the same time.
>>>>
>>>> Yes to the DEC RAs. TW worte that code for the PDP-10s; it used a
>>>> comm spec similar to DECnet's approach. We did not like them
>>>> because the disks were no availabe for booting the system. Another
>>>> design flaw. another design flaw was the number of ports; it was
>>>> still 2.
>>>
>>> Was the not-bootable thing a front end/firmware thing or was it
>>> a feature in tops10/20?
>>
>> It was a feature of the fucking hardware design done by people
>> who suffered from small computer thinking.
>
> Can you elaborate? What features weren't implemented? And was the
> missing part in the disk, controller, front end or in the pdp10?
Bill covered the hardware problems. There wasn't any access to the
20F front end. All PDP-10s still had to maintain the RP06. There was
a reluctance to provide mountable disks. DECnet was horrendously
bloatware; the protocols for the controller and disk created similarly
bloated software. The HSC software was installed using a device
which was worse than magtapes and corporate had the effontery to
call it DECtape. That's all I can recall right now. There was other
shit, as every hardware project has, which TW had "fix" via clever
software; extrapolating from his RP20 project report would give
you a general idea. All hardware projects were like that.
It was a fucking project because the fallout caused TW to quit DEC.
/BAH
|
|
|
|
| Re: The ICL 2900 [message #338414 is a reply to message #338357] |
Sat, 25 February 2017 10:29 |
jmfbahciv
Messages: 6173
Registered: March 2012
Karma: 0
|
Senior Member |
|
|
Mike Spencer wrote:
>
> jmfbahciv <See.above@aol.com> writes:
>
>> I was 15 the last time I used an outhouse.
>
> And you're now wht, 67? And look where it got you: All those years of
> the insanity inside Rt. 128 and then verbal harassment here on a.f.s.
> You could have moved to Coos County, NH right after you finished
> school. Or, considering that that would still have left you (now) in
> a country with a loose cannon for a leader, you could have moved here.
>
> ObAOLS, YADATROS: Yes, there is a tech industry in Nova Scotia. Not
> so much in Coos Cty. AFAIK.
>
<GRIN> I do not miss the flies.
/BAH
|
|
|
|
| Re: The ICL 2900 [message #338415 is a reply to message #338406] |
Sat, 25 February 2017 10:35 |
Peter Flass
Messages: 8375
Registered: December 2011
Karma: 0
|
Senior Member |
|
|
JimP. <solosam90@gmail.com> wrote:
> On 25 Feb 2017 11:51:26 GMT, Huge <Huge@nowhere.much.invalid> wrote:
>
>> On 2017-02-25, Ahem A Rivet's Shot <steveo@eircom.net> wrote:
>>> On 24 Feb 2017 21:30:51 GMT
>>> Bill Findlay <findlaybill@blueyonder.co.uk > wrote:
>>>
>>>> Ahem A Rivet's Shot <steveo@eircom.net> wrote:
>>>> > On 24 Feb 2017 02:42:39 GMT
>>>> > Bill Findlay <findlaybill@blueyonder.co.uk > wrote:
>>>
>>>> >> There is no need for a trained sysadmin.
>>>> >
>>>> > There are a surprisingly large number of people making a living
>>>> > out of digging people out of the messes they manage to get into with
>>>> > their PCs and Macs. To me this indicates that a trained sysadmin would
>>>> > be beneficial.
>>>>
>>>> Numbers? Pro rata to system types?
>>>
>>> I've not done a census, but there's at least one in every small
>>> town hereabouts - it's easier to find someone to fix a PC than it is to
>>> find someone to cut a key.
>>
>> Ditto where I live in South Norfolk. One place cuts keys, there are
>> half-a-dozen PC menders.
>
> Wally world has automatic key cutters. Plug the key into the device,
> it scans the key, asks you to select a standard or colorful blank, you
> pay, it cuts new key. I don't think it does car keys.
> --
> Jim
>
Any hardware store, including the big-box guys.
--
Pete
|
|
|
|
| Re: The ICL 2900 [message #338417 is a reply to message #338359] |
Sat, 25 February 2017 10:52 |
hancock4
Messages: 6746
Registered: December 2011
Karma: 0
|
Senior Member |
|
|
On Friday, February 24, 2017 at 3:27:54 PM UTC-5, Mike Spencer wrote:
> Our "network" is a copper line from the outdoor demarc and we have no
> TV. If someone shows up and offers to install a broadband net
> connection, the only worry would be that the "someone" is from the
> telco and would want to remove the copper landline. AFAICT, that
> "someone" will arrive on a flying pig if it's sooner that a decade or
> more and I'll be (or almost be) a nonogenarian.
Unfortunately, traditional Telco's aren't interested in maintaining
the old copper lines. If they fail, it's become very hard to get
a Telco to fix them.
> Only two competitors here: telco and cableco. Neither shows any
> inclination to run half a mile of cable or glass to my door and those
> of the other two houses in our little hamlet.
Many news reports have said customers in such isolated locations
get screwed when their traditional copper line fails. If it's too
far to be economically served after the copper fails, it won't
get service. Customers will be told go to wireless.
Heck, even customers in poor city neighborhoods have been told
that when a cable breaks and the Telco doesn't feel like ripping
up the street to fix it, and doesn't need a justification to run
fibre.
Not a good situation.
|
|
|
|
| Re: The ICL 2900 [message #338418 is a reply to message #338395] |
Sat, 25 February 2017 12:30 |
Gerard Schildberger
Messages: 163
Registered: September 2012
Karma: 0
|
Senior Member |
|
|
On Friday, February 24, 2017 at 10:17:40 PM UTC-6, Jon Elson wrote:
> Peter Flass wrote:
>> Jon Elson wrote:
>>> Peter Flass wrote:
>>>> Richard Thiebaud wrote:
>>>> > On 02/22/2017 08:56 AM, Peter Flass wrote:
>>>> >> I suspect lots of branch offices had VAXen just to run A-I-O just like
>>>> >> a lot had 4331s just to run PROFS.
>>>> > What are PROFS?
>>>> Office system - calendar, email, etc.
>>> Yes, we had it here. We had a pair of 370/145s, and each machine could
>>> support FOUR PROFS users! More than 4, and then the system got REALLY
>>> slow. Well, 145's were not speed demons, but that seems awfully mediocre.
>> What the heck were they doing? IME most PROFS users left the screen at
>> the
>> calendar unless they were doing email. You could support lots of users
>> doing nothing on almost any system. We had PROFS/OV, but I think I stuck
>> to simpler systems for mail, although the memory is all gone now.
> Well, I don't know. A good friend was on the support staff, but I was
> involved in PDP/11 and then VAX systems. They had 1 MB of GE/Intersil
> memory on the /145s, and Memorex 12...
As you said, most PROFS users left their screen at the calendar thingy,
(either that, at the "e-mail" screen, waiting for e-mail to arrive), but
if the PROFS system was configured (the default) to update the time-of-day
(on most PROFS screens), that meant that every PROFS user had to be paged
in, had the screen updated (written to), and then, eventually, paged out
again (depending on how busy the system was). If the system had
constrained storage, this lead to a lot of paging. A one-megabyte
370/145 doesn't seem quite large enough, depending on what else is running,
but PROFS wasn't exactly a small system.
Once the cause of our system problem(s) were identified, our company turned
off the PROFS time-of-day updates, and we bought everyone a $2 digital
clock that we stuck on every terminal that used PROFS. Problem solved.
(Well --- not quite, there was still a lot of managers that got used to
reading the TOD from the screen, and you wouldn't believe the kickback!)
We had well over 8,000 PROFS users on each of our two VM systems. That
required a pretty robust paging system (and a lot of full-pack paging
devices). __________________________________________ Gerard Schildberger
|
|
|
|
| Re: The ICL 2900 [message #338422 is a reply to message #338412] |
Sat, 25 February 2017 12:49 |
Jon Elson
Messages: 646
Registered: April 2013
Karma: 0
|
Senior Member |
|
|
jmfbahciv wrote:
> JMF used Turbo Tax once; I checked his forms and discovered that TT
> couldn't do arithmetic. So he didn't buy it again.
I've been using Tax Cut, now by H&R Block. But, I've been using it through
several owners since the late '90s. They have a free on-line service, but I
don't really care to do it that way. I have a home business plus
investments, so it is a fairly complicated return. When I last had a CPA do
it, it cost me over $1000, and I had to do as much digging and organizing of
records, anyway, as I need to enter data for the program. With the program,
if the result doesn't come out within shooting distance of last year, then I
can go looking for where I forgot to enter something and see if that fixes
it.
Jon
|
|
|
|
| Re: The ICL 2900 [message #338423 is a reply to message #338418] |
Sat, 25 February 2017 12:51 |
Jon Elson
Messages: 646
Registered: April 2013
Karma: 0
|
Senior Member |
|
|
Gerard Schildberger wrote:
> We had well over 8,000 PROFS users on each of our two VM systems. That
> required a pretty robust paging system (and a lot of full-pack paging
> devices). __________________________________________ Gerard Schildberger
Whew! And, I'll bet you weren't doing this on a /145, either.
Jon
|
|
|
|
| Re: The ICL 2900 [message #338424 is a reply to message #338407] |
Sat, 25 February 2017 12:54 |
Jon Elson
Messages: 646
Registered: April 2013
Karma: 0
|
Senior Member |
|
|
jmfbahciv wrote:
> When I started about 75% of manuals were typed on a typewriter.
> By the time I left, 25% were still done with a typewriter.
Ohhh, I REMEMBER those!
> The lag distribution time of getting a manual done on a typewriter
> w.r.t. the software it described was 1-2 years. Getting the
> manuals into machine-readable format reduced the lag by 2 years.
> Distribution was within a few months after software distribution.
> Eventually part of the ship criteria was having the documentation
> shipped with the software. It took about 8 years for this
> reduction of timing to be completed. I didn't do all the work;
> I just started it by changing attitudes, hidden assumptions
> and convincing management that documentation was just as
> important as the hard/software.
>
Uhhh, how could you (DEC) ship a product without documentation? Yikes!
Jon
|
|
|
|
| Re: The ICL 2900 [message #338425 is a reply to message #338411] |
Sat, 25 February 2017 13:08 |
|
|
Originally posted by: JimP.
On 25 Feb 2017 15:29:10 GMT, jmfbahciv <See.above@aol.com> wrote:
> JimP. wrote:
>> On 25 Feb 2017 11:51:26 GMT, Huge <Huge@nowhere.much.invalid> wrote:
>>
>>> On 2017-02-25, Ahem A Rivet's Shot <steveo@eircom.net> wrote:
>>>> On 24 Feb 2017 21:30:51 GMT
>>>> Bill Findlay <findlaybill@blueyonder.co.uk > wrote:
>>>>
>>>> > Ahem A Rivet's Shot <steveo@eircom.net> wrote:
>>>> > > On 24 Feb 2017 02:42:39 GMT
>>>> > > Bill Findlay <findlaybill@blueyonder.co.uk > wrote:
>>>>
>>>> > >> There is no need for a trained sysadmin.
>>>> > >
>>>> > > There are a surprisingly large number of people making a living
>>>> > > out of digging people out of the messes they manage to get into with
>>>> > > their PCs and Macs. To me this indicates that a trained sysadmin would
>>>> > > be beneficial.
>>>> >
>>>> > Numbers? Pro rata to system types?
>>>>
>>>> I've not done a census, but there's at least one in every small
>>>> town hereabouts - it's easier to find someone to fix a PC than it is to
>>>> find someone to cut a key.
>>>
>>> Ditto where I live in South Norfolk. One place cuts keys, there are
>>> half-a-dozen PC menders.
>>
>> Wally world has automatic key cutters. Plug the key into the device,
>> it scans the key, asks you to select a standard or colorful blank, you
>> pay, it cuts new key. I don't think it does car keys.
>
> Nor small keys. The key cutting business now seems to have devolved
> into one size fits all. It was impossible for me to get copies
> for the outside door lock of my Southboro house because key cutters
> didn't have blanks that size. Now I buy a new lock instead of
> getting copies of the key for the current lock on my fence.
I have had no problem getting keys cut for door and padlock keys. They
had a number of different blank sizes. Sounds like you need to go to a
different key place.
--
Jim
|
|
|
|
| Re: The ICL 2900 [message #338426 is a reply to message #338415] |
Sat, 25 February 2017 13:10 |
|
|
Originally posted by: JimP.
On Sat, 25 Feb 2017 08:35:34 -0700, Peter Flass
<peter_flass@yahoo.com> wrote:
> JimP. <solosam90@gmail.com> wrote:
>> On 25 Feb 2017 11:51:26 GMT, Huge <Huge@nowhere.much.invalid> wrote:
>>
>>> On 2017-02-25, Ahem A Rivet's Shot <steveo@eircom.net> wrote:
>>>> On 24 Feb 2017 21:30:51 GMT
>>>> Bill Findlay <findlaybill@blueyonder.co.uk > wrote:
>>>>
>>>> > Ahem A Rivet's Shot <steveo@eircom.net> wrote:
>>>> >> On 24 Feb 2017 02:42:39 GMT
>>>> >> Bill Findlay <findlaybill@blueyonder.co.uk > wrote:
>>>>
>>>> >>> There is no need for a trained sysadmin.
>>>> >>
>>>> >> There are a surprisingly large number of people making a living
>>>> >> out of digging people out of the messes they manage to get into with
>>>> >> their PCs and Macs. To me this indicates that a trained sysadmin would
>>>> >> be beneficial.
>>>> >
>>>> > Numbers? Pro rata to system types?
>>>>
>>>> I've not done a census, but there's at least one in every small
>>>> town hereabouts - it's easier to find someone to fix a PC than it is to
>>>> find someone to cut a key.
>>>
>>> Ditto where I live in South Norfolk. One place cuts keys, there are
>>> half-a-dozen PC menders.
>>
>> Wally world has automatic key cutters. Plug the key into the device,
>> it scans the key, asks you to select a standard or colorful blank, you
>> pay, it cuts new key. I don't think it does car keys.
>> --
>> Jim
>>
>
> Any hardware store, including the big-box guys.
The machine did tell me one time it couldn't do it. So I walked over
to Wally world's auto department. Told them the error message, they
looked at the key, made me a copy. No problem.
--
Jim
|
|
|
|
| Re: The ICL 2900 [message #338427 is a reply to message #338413] |
Sat, 25 February 2017 14:26 |
pechter
Messages: 452
Registered: July 2012
Karma: 0
|
Senior Member |
|
|
In article <PM0005495C9E39238F@aca4033f.ipt.aol.com>,
jmfbahciv <See.above@aol.com> wrote:
> Morten Reistad wrote:
>> In article <PM0005494742EE1C35@aca46ce8.ipt.aol.com>,
>> jmfbahciv <See.above@aol.com> wrote:
>>> Morten Reistad wrote:
>>>> In article <PM0005493306541D4F@aca41e2b.ipt.aol.com>,
>>>> jmfbahciv <See.above@aol.com> wrote:
>>>> >William Pechter wrote:
>>>> >> In article <PM0005491E9D353FCC@aca480e6.ipt.aol.com>,
>>>> >> jmfbahciv <See.above@aol.com> wrote:
>>>> >>
>>>> >>>Aren't today's controllers a part of the disk drive? So there's no
> longer
>>>> >>>one controller for many drives.
>>>> >>>
>>>> >>>/BAH
>>>> >>
>>>> >> Nope... except for the older IDE drive where the controller was a pretty
>>>> >> small bus interface.
>>>> >>
>>>> >> There's still the need for the thing that connects the drive to the I/O
>>> bus.
>>>> >> Much of the logic now is kind of like the stuff DEC did for DSA (Digital
>>>> >> Storage Architecture).
>>>> >>
>>>> >> The disks are smart devices talking some kind of data protocol to the
>>> system
>>>> >> via a controller.
>>>> >>
>>>> >> The disks are addressed by logical blocks and no longer Cylinder, Head
> and
>>>> >> Sector. The physical geometry is no longer tied to the disk software
>>>> >> geometry.
>>>> >
>>>> >Somebody has to do the physcial-logical mapping. I figured it was part of
>>>> >the [what I would think of as] the disk drive.
>>>>
>>>> This (and the badspot, block moving and renaming etc) is all done in the
>>>> firmware of the "disk". Actually, the IBMism "DASD" becomes more fitting
> as
>>>> time goes on.
>>>
>>> OK. So I've that concept correct. What are the minuses of having the
>>> controller software in the disk rather than the kernal?
>>
>> They are in the kernal too, only used as a very last resort.
>>
>> The controller on the disk runs a realtime job, managing the heads, the
>> actuators, the write and read operations and the comms to and from the
>> next controller closer to the CPU.
>>
>> It can do sector remapping from bad sectors, and have some (~1-5%) of
>> the space on the disk set off for this. Modern disks always come with
>> quite a bit of bad sectors, but they are hidden by the controller.
>>
>> And, yes, it is comms. It is almost exclusively serial these days, and
>> have a comms protocol on top.
>>
>> This controller does all the stuff that needs to know the hardware closely.
>>
>>>> >> (This has had effects on some of the low level format and partition
> layout
>>>> >> software...like the BSD Disklabels).
>>>> >>
>>>> >> This change, as far as I know, started back in the 80's with DEC RA
> drives
>>>> >> and DSA as well as the SASI/SCSI stuff which was also becoming a
> standard
>>>> >> at the same time.
>>>> >
>>>> >Yes to the DEC RAs. TW worte that code for the PDP-10s; it used a
>>>> >comm spec similar to DECnet's approach. We did not like them
>>>> >because the disks were no availabe for booting the system. Another
>>>> >design flaw. another design flaw was the number of ports; it was
>>>> >still 2.
>>>>
>>>> Was the not-bootable thing a front end/firmware thing or was it
>>>> a feature in tops10/20?
>>>
>>> It was a feature of the fucking hardware design done by people
>>> who suffered from small computer thinking.
>>
>> Can you elaborate? What features weren't implemented? And was the
>> missing part in the disk, controller, front end or in the pdp10?
>
> Bill covered the hardware problems. There wasn't any access to the
> 20F front end. All PDP-10s still had to maintain the RP06. There was
> a reluctance to provide mountable disks. DECnet was horrendously
> bloatware; the protocols for the controller and disk created similarly
> bloated software. The HSC software was installed using a device
> which was worse than magtapes and corporate had the effontery to
> call it DECtape. That's all I can recall right now. There was other
> shit, as every hardware project has, which TW had "fix" via clever
> software; extrapolating from his RP20 project report would give
> you a general idea. All hardware projects were like that.
>
> It was a fucking project because the fallout caused TW to quit DEC.
>
>
> /BAH
Well... there's no reason they couldn't have done a PDP10 controller
for the RA drive like the UDA50 on the PDP11. Then they could've
been able to do the dual port between the 11/40 and the KS/KL.
UDA50A drivers exist for PDP11's, VAXes, (even MicroVaxes support
RA's with their own KDA50 which is Qbus based)...
Perhaps they were unwilling to do the hardware engineering.
Putting dual port RA/UDA type drives would've been simpler, I think
than putting the HSC50 on the boxes -- if they would've made the disk packs
and HDA's to support the format needed. I'd have made the entire
pack in PDP10 sectoring and had the software on the controller
handle it to had the PDP11 what it needed.
Bill
--
--
Digital had it then. Don't you wish you could buy it now!
pechter-at-gmail.com http://xkcd.com/705/
|
|
|
|
| Re: The ICL 2900 [message #338428 is a reply to message #338408] |
Sat, 25 February 2017 14:29 |
pechter
Messages: 452
Registered: July 2012
Karma: 0
|
Senior Member |
|
|
In article <PM0005495BEAB47EF3@aca4033f.ipt.aol.com>,
jmfbahciv <See.above@aol.com> wrote:
> William Pechter wrote:
>> In article <5EYrA.17429$2F2.16618@fx22.iad>,
>> Scott Lurndal <slp53@pacbell.net> wrote:
>>> Morten Reistad <first@last.name.invalid> writes:
>>>> In article <PM0005494742EE1C35@aca46ce8.ipt.aol.com>,
>>>> jmfbahciv <See.above@aol.com> wrote:
>>>
>>>> >OK. So I've that concept correct. What are the minuses of having the
>>>> >controller software in the disk rather than the kernal?
>>>>
>>>> They are in the kernal too, only used as a very last resort.
>>>
>>> No, there is no "disk controller" software in any kernel (Windows, Unix
>>> or Linux). There is a driver for the host adapter which arranges
>>> for command and data to be transferred from the drive. There is no
>>> software in the kernel to replace the functionality of the drive
>>> electronics.
>>>
>>> The protocols (SCSI, SATA, USB Block Storage) do provide mechanisms
>>> (e.g. SCSI Mode Pages, ATAPI) for the
>>> host to _influence_ the drive software by specifying performance
>>> or other desired characteristics and to extract diagnostic information
>>> from the drive, but it is not possible to replace e.g. the on-drive
>>> scheduling algorithm.
>>>
>>>>
>>>> The controller on the disk runs a realtime job, managing the heads, the
>>>> actuators, the write and read operations and the comms to and from the
>>>> next controller closer to the CPU.
>>>
>>> Comms is misleading in this context, particularly for your
>>> respondent. While the SAS/SATA connections are serial, they're
>>> not comms in the PDP-10 sense. It's the same protocol that runs
>>> on the parallel (e.g. SCSI, pATA) interface serialized onto a pair
>>> of wires.
>>>
>>
>> Not really. Unlike the old days where you accessed by Cyl, Head, Sector
>> and had to block out bad sectors manually... you're pretty much
>> getting blocks of storage by a data comm protocol.
>>
>> When I first saw this in Digital Storage Architecture back in 85 or so
>> I looked at the HSC50 and UDA50A and described the process
>> of talking to intelligent (rather than blissfully stupid) disk drives
>> with the words -- "Ah, DECnet for disk drives."
>
> Yup. I had reservations about allowing a disk drive do all that work;
> TW had enormous problems allowing the disk drives to do all that work.
> He'd been writing the controller and device service routines for
> TOPS-10 since 1966. It was a struggle to cede control for him.
>
>
>>
>> When the drives do things like bad block revectoring and disk location
>> mapping of sectors to a unified piece of storage whos sector
>> count vary by location -- it looks to old timers like things
>> that are blatantly NON-DISK like actions.
>
> It sure is a hell of a lot of code to lay bits on a platter. ;-)
>
> /BAH
Nah... an electromagnet on a stick over spinning rust can lay disk bits
on a platter. The trick is to lay A LOT OF COMPACT BITS ON THE PLATTER
QUICKLY and RELIABLY. The old days had things like the RP06 having
to do write and read compensation depending upon how close the bits were in
the same sized sector. (Less read amp for example, more/less write current...
been a long time since disk school in '85 so I may be forgetting some of
the stuff the bits required).
Well, now you can make the sectors the same size and have more of them on
the wide part of the disk if you want and have the firmware hide it.
Bill
--
--
Digital had it then. Don't you wish you could buy it now!
pechter-at-gmail.com http://xkcd.com/705/
|
|
|
|
| Re: The ICL 2900 [message #338429 is a reply to message #338407] |
Sat, 25 February 2017 14:37 |
pechter
Messages: 452
Registered: July 2012
Karma: 0
|
Senior Member |
|
|
In article <PM0005495C7E0A6F51@aca4033f.ipt.aol.com>,
jmfbahciv <See.above@aol.com> wrote:
> This was the first job I was paid to do. I'll try to write
> up the next one in another post.
>
> /BAH
1. Don't forget "He who proposes disposes..." Make the suggestion for a
change and you own it unless you're not competent.
2. Or as the job descriptions at most places had -- "Or other duties
as required..."
This had Field Service rack mounting RA81's at mid level in DEC corporate
cabinets on existing sites. There was a hydraulic lift supposely necessary.
Try finding one in a Field Service DECwagon.
Field Service equivalent I used... A pile of books on top of secretary's
hydraulic office chair and prayer nothing slipped.
Raise drive to height and slide out rails and connect them.
Pray nothing slips.
Otherwise you need more than one Field Engineer or a spinal surgeon
to put you back together. RA81 weight 148 lbs... The RA60 was heavier.
This worked well on RL drives... tougher on RA.
Bill
--
--
Digital had it then. Don't you wish you could buy it now!
pechter-at-gmail.com http://xkcd.com/705/
|
|
|
|
| Re: The ICL 2900 [message #338431 is a reply to message #338406] |
Sat, 25 February 2017 09:28 |
Morten Reistad
Messages: 2108
Registered: December 2011
Karma: 0
|
Senior Member |
|
|
In article <2e43bcda3rdsrp1r46mmkdgaprr22rotga@4ax.com>,
JimP. <solosam90@gmail.com> wrote:
> On 25 Feb 2017 11:51:26 GMT, Huge <Huge@nowhere.much.invalid> wrote:
>
>> On 2017-02-25, Ahem A Rivet's Shot <steveo@eircom.net> wrote:
>>> On 24 Feb 2017 21:30:51 GMT
>>> Bill Findlay <findlaybill@blueyonder.co.uk > wrote:
>>>
>>>> Ahem A Rivet's Shot <steveo@eircom.net> wrote:
>>>> > On 24 Feb 2017 02:42:39 GMT
>>>> > Bill Findlay <findlaybill@blueyonder.co.uk > wrote:
>>>
>>>> >> There is no need for a trained sysadmin.
>>>> >
>>>> > There are a surprisingly large number of people making a living
>>>> > out of digging people out of the messes they manage to get into with
>>>> > their PCs and Macs. To me this indicates that a trained sysadmin would
>>>> > be beneficial.
>>>>
>>>> Numbers? Pro rata to system types?
>>>
>>> I've not done a census, but there's at least one in every small
>>> town hereabouts - it's easier to find someone to fix a PC than it is to
>>> find someone to cut a key.
>>
>> Ditto where I live in South Norfolk. One place cuts keys, there are
>> half-a-dozen PC menders.
>
> Wally world has automatic key cutters. Plug the key into the device,
> it scans the key, asks you to select a standard or colorful blank, you
> pay, it cuts new key. I don't think it does car keys.
Car keys got rfid transponders in the early 1990s. The first generation
was unencrypted and one-way; and therefore possible to duplicate without
very large hassles, but ca 2000 they went two-way with a challenge-response
design, and becoming VERY difficult to clone.
-- mrr
|
|
|
|
| Re: The ICL 2900 [message #338432 is a reply to message #336191] |
Sat, 25 February 2017 15:06 |
|
|
Originally posted by: JimP.
On 25 Feb 2017 19:29:01 GMT, Huge <Huge@nowhere.much.invalid> wrote:
> On 2017-02-25, JimP <solosam90@gmail.com> wrote:
>> On 25 Feb 2017 11:51:26 GMT, Huge <Huge@nowhere.much.invalid> wrote:
>
> [21 lines snipped]
>
>>> Ditto where I live in South Norfolk. One place cuts keys, there are
>>> half-a-dozen PC menders.
>>
>> Wally world has automatic key cutters. Plug the key into the device,
>> it scans the key, asks you to select a standard or colorful blank, you
>> pay, it cuts new key. I don't think it does car keys.
>
> I have never heard of "Wally World".
>
> And many (most? all?) car keys these days have electronics in them and
> need to be paired to the car.
Wally world is the nickname for Wall-Mart. I have seen car keys that
don't have an electronic thingie in them. My car isn't recent.
--
Jim
|
|
|
|
| Re: The ICL 2900 [message #338433 is a reply to message #338423] |
Sat, 25 February 2017 15:56 |
Gerard Schildberger
Messages: 163
Registered: September 2012
Karma: 0
|
Senior Member |
|
|
On Saturday, February 25, 2017 at 11:51:28 AM UTC-6, Jon Elson wrote:
> Gerard Schildberger wrote:
>
>
>> We had well over 8,000 PROFS users on each of our two VM systems. That
>> required a pretty robust paging system (and a lot of full-pack paging
>> devices). __________________________________________ Gerard Schildberger
> Whew! And, I'll bet you weren't doing this on a /145, either.
>
> Jon
No, both big VM systems (plus another two VM's) where on an Amdahl,
each of the two big VM's had about half of the 4-engine Amdahl.
(We were all shocked when our company ordered the Amdahl to replace
the IBM 3084.) ________________________________ Gerard Schildberger
|
|
|
|
| Re: The ICL 2900 [message #338434 is a reply to message #338418] |
Sat, 25 February 2017 16:02 |
hancock4
Messages: 6746
Registered: December 2011
Karma: 0
|
Senior Member |
|
|
On Saturday, February 25, 2017 at 12:30:25 PM UTC-5, Gerard Schildberger wrote:
> As you said, most PROFS users left their screen at the calendar thingy,
> (either that, at the "e-mail" screen, waiting for e-mail to arrive), but
> if the PROFS system was configured (the default) to update the time-of-day
> (on most PROFS screens), that meant that every PROFS user had to be paged
> in, had the screen updated (written to), and then, eventually, paged out
> again (depending on how busy the system was). If the system had
> constrained storage, this lead to a lot of paging. A one-megabyte
> 370/145 doesn't seem quite large enough, depending on what else is running,
> but PROFS wasn't exactly a small system.
FWIW, our system did not update an idle screen (except with reminder
messages). Indeed, we asked our VM system administrator about leaving
our PROFS session up all day and she said it was fine since an idle
terminal consumed no resources. In contrast, our TSO sessions were
timed, and would automatically logoff if unused after about 15 minutes.
(Now our PC's log out if unused after 20 minutes, but that's for
security, not resource usage).
> Once the cause of our system problem(s) were identified, our company turned
> off the PROFS time-of-day updates, and we bought everyone a $2 digital
> clock that we stuck on every terminal that used PROFS. Problem solved.
> (Well --- not quite, there was still a lot of managers that got used to
> reading the TOD from the screen, and you wouldn't believe the kickback!)
In those days, the computer time-of-day was set by the IPL operator,
who merely looked at his wristwatch. The time was often off by a few
minutes either way, and different mainframes had different times as
individual operators set their respective machines. Our individual
PC clocks could be way off depending on how we set them and the battery.
In later years, they got some sort of reliable time source and
everything was uniform.
As aside, long ago Western Union provided clocks and a time signal
from the National Observatory. I don't know if computers ever
linked into that, or when the service was discontinued. But WU
branch offices continued to show their synchronized clocks well
into the 1960s.
I don't know if IBM's time systems ever linked to Western Union.
It would certainly make sense to do so.
>
> We had well over 8,000 PROFS users on each of our two VM systems. That
> required a pretty robust paging system (and a lot of full-pack paging
> devices). __________________________________________ Gerard Schildberger
|
|
|
|
| Re: The ICL 2900 [message #338451 is a reply to message #338197] |
Sat, 25 February 2017 21:39 |
Gene Wirchenko
Messages: 1166
Registered: January 2012
Karma: 0
|
Senior Member |
|
|
On Thu, 23 Feb 2017 16:03:55 GMT, scott@slp53.sl.home (Scott Lurndal)
wrote:
[snip]
> The shell is a command language. The strength of Unix is that
> one can easily build a different command language to match ones needs.
A feature of UNIX is that one can do so. However, someone just
learning UNIX likely has no need for that yet.
One standard would help for newbies. Extra detail can be the
straw that breaks the camel's back.
[snip]
Sincerely,
Gene Wirchenko
|
|
|
|
| Re: The ICL 2900 [message #338452 is a reply to message #338292] |
Sat, 25 February 2017 21:59 |
Gene Wirchenko
Messages: 1166
Registered: January 2012
Karma: 0
|
Senior Member |
|
|
On Fri, 24 Feb 2017 07:00:58 -0700, Peter Flass
<peter_flass@yahoo.com> wrote:
[snip]
> Stupidity? It should be trivial to implement. The best they give you is a
> browse by first letter of last name, and for some names that's
> problematic.
The algorithm is simple and is in the Wikipedia article:
https://en.wikipedia.org/wiki/Soundex
Soundex does not handle initial silent letters; for example,
Knight's soundex is K523.
Soundex is based on English pronunciation. The Wikipedia article
mentions variants to cover some non-English names.
I tried some Japanese words written in Romaji, and one can get
weird rseults.
Aoi is a given name (meaning blue) and since Soundex ignores
vowels other than the first character, Aoi's soundex is A000.
The soundex for matcha (green tea) is M320. The T is not
pronounced; instead, it indicates that there is a pause in the middle
of the word.
I could have fun with French's CH which is pronounced like
English's SH.
Chinese's Pinyin has rather different phonetic values for some
letters.
Feel free to add other language examples.
I program in Microsoft Visual FoxPro. VFP has a soundex
function. I have never used it in an app.
Sincerely,
Gene Wirchenko
|
|
|
|
| Re: The ICL 2900 [message #338459 is a reply to message #338434] |
Sun, 26 February 2017 01:16 |
Dan Espen
Messages: 3867
Registered: January 2012
Karma: 0
|
Senior Member |
|
|
hancock4@bbs.cpcn.com writes:
> As aside, long ago Western Union provided clocks and a time signal
> from the National Observatory. I don't know if computers ever
> linked into that, or when the service was discontinued. But WU
> branch offices continued to show their synchronized clocks well
> into the 1960s.
>
> I don't know if IBM's time systems ever linked to Western Union.
> It would certainly make sense to do so.
https://en.wikipedia.org/wiki/Network_Time_Protocol
--
Dan Espen
|
|
|
|
| Re: The ICL 2900 [message #338460 is a reply to message #338452] |
Sun, 26 February 2017 01:27 |
Ahem A Rivet's Shot
Messages: 4843
Registered: January 2012
Karma: 0
|
Senior Member |
|
|
On Sat, 25 Feb 2017 18:59:40 -0800
Gene Wirchenko <genew@telus.net> wrote:
> On Fri, 24 Feb 2017 07:00:58 -0700, Peter Flass
> <peter_flass@yahoo.com> wrote:
>
> [snip]
>
>> Stupidity? It should be trivial to implement. The best they give you is
>> a browse by first letter of last name, and for some names that's
>> problematic.
>
> The algorithm is simple and is in the Wikipedia article:
> https://en.wikipedia.org/wiki/Soundex
I used Soundex as part of a name and address matching system around
1990, the standard algorithm produced quite poor results and needed
substantial tweaking to be useful.
--
Steve O'Hara-Smith | Directable Mirror Arrays
C:>WIN | A better way to focus the sun
The computer obeys and wins. | licences available see
You lose and Bill collects. | http://www.sohara.org/
|
|
|
|
| Re: The ICL 2900 [message #338461 is a reply to message #338451] |
Sun, 26 February 2017 01:28 |
Ahem A Rivet's Shot
Messages: 4843
Registered: January 2012
Karma: 0
|
Senior Member |
|
|
On Sat, 25 Feb 2017 18:39:23 -0800
Gene Wirchenko <genew@telus.net> wrote:
> One standard would help for newbies. Extra detail can be the
> straw that breaks the camel's back.
The Bourne shell (or a decent clone) is pretty much universal and
has been for a long time.
--
Steve O'Hara-Smith | Directable Mirror Arrays
C:>WIN | A better way to focus the sun
The computer obeys and wins. | licences available see
You lose and Bill collects. | http://www.sohara.org/
|
|
|
|
|
|
| Re: Digression: BSD detail and FFox (Was: The ICL 2900) [message #338463 is a reply to message #338404] |
Sun, 26 February 2017 02:09 |
Mike Spencer
Messages: 997
Registered: January 2012
Karma: 0
|
Senior Member |
|
|
Ahem A Rivet's Shot <steveo@eircom.net> writes:
> On 25 Feb 2017 03:10:42 -0400
> Mike Spencer <mds@bogus.nodomain.nowhere> wrote:
>
>> But I'm running a Linux system, not a BSD system and FF was allegedly
>> for Linux. So there is no /compat and an app should never look for
>> /etc/malloc.conf.
>
> Sounds like FF has been built using a copy of jemalloc, which is
> what really uses the /etc/malloc.conf symlink trick.
Huh. Nor something I knew about. No easy way to deal with that.
Still grovelling around, clingingto the trailing edge of tech.
Tnx for the clue,
--
Mike Spencer Nova Scotia, Canada
|
|
|
|
| Re: The ICL 2900 [message #338465 is a reply to message #338425] |
Sun, 26 February 2017 04:51 |
mausg
Messages: 2483
Registered: May 2013
Karma: 0
|
Senior Member |
|
|
On 2017-02-25, JimP <solosam90@gmail.com> wrote:
> On 25 Feb 2017 15:29:10 GMT, jmfbahciv <See.above@aol.com> wrote:
>> JimP. wrote:
>>> On 25 Feb 2017 11:51:26 GMT, Huge <Huge@nowhere.much.invalid> wrote:
>>>
>>
>> Nor small keys. The key cutting business now seems to have devolved
>> into one size fits all. It was impossible for me to get copies
>> for the outside door lock of my Southboro house because key cutters
>> didn't have blanks that size. Now I buy a new lock instead of
>> getting copies of the key for the current lock on my fence.
>
> I have had no problem getting keys cut for door and padlock keys. They
> had a number of different blank sizes. Sounds like you need to go to a
> different key place.
> --
> Jim
I have to go about 15 miles to get some keys cut, which really means
that I go to that place to get any key cut, saves being sent on.
As for PC menders, there are alot, but very few _genuine_ ones.
--
greymaus.ireland.ie
Just_Another_Grumpy_Old_Man
|
|
|
|
| Re: The ICL 2900 [message #338468 is a reply to message #338459] |
Sun, 26 February 2017 04:13 |
Morten Reistad
Messages: 2108
Registered: December 2011
Karma: 0
|
Senior Member |
|
|
In article <o8trov$dqf$1@dont-email.me>, Dan Espen <despen@verizon.net> wrote:
> hancock4@bbs.cpcn.com writes:
>
>> As aside, long ago Western Union provided clocks and a time signal
>> from the National Observatory. I don't know if computers ever
>> linked into that, or when the service was discontinued. But WU
>> branch offices continued to show their synchronized clocks well
>> into the 1960s.
>>
>> I don't know if IBM's time systems ever linked to Western Union.
>> It would certainly make sense to do so.
>
> https://en.wikipedia.org/wiki/Network_Time_Protocol
"This document will tell you far more about clocks and timekeeping
than you ever wanted to know.".
From the preface to the NTP RFC.
-- mrr
|
|
|
|
| Re: The ICL 2900 [message #338473 is a reply to message #338451] |
Sun, 26 February 2017 08:38 |
Peter Flass
Messages: 8375
Registered: December 2011
Karma: 0
|
Senior Member |
|
|
Gene Wirchenko <genew@telus.net> wrote:
> On Thu, 23 Feb 2017 16:03:55 GMT, scott@slp53.sl.home (Scott Lurndal)
> wrote:
>
> [snip]
>
>> The shell is a command language. The strength of Unix is that
>> one can easily build a different command language to match ones needs.
>
> A feature of UNIX is that one can do so. However, someone just
> learning UNIX likely has no need for that yet.
>
> One standard would help for newbies. Extra detail can be the
> straw that breaks the camel's back.
>
But unfortunately everything is like that these days. It's great that the
store carries 30 varieties of mustard, but when I go to the store I don't
want to research mustards, I just want to pick up a jar - usually the same
kind every time. Then someone comes out with a new release... er, " new and
improved", or usually just new packaging, and throws me for a loop.
--
Pete
|
|
|
|
| Re: The ICL 2900 [message #338479 is a reply to message #336191] |
Sun, 26 February 2017 09:10 |
jmfbahciv
Messages: 6173
Registered: March 2012
Karma: 0
|
Senior Member |
|
|
Huge wrote:
> On 2017-02-25, JimP <solosam90@gmail.com> wrote:
>> On 25 Feb 2017 19:29:01 GMT, Huge <Huge@nowhere.much.invalid> wrote:
>>
>>> On 2017-02-25, JimP <solosam90@gmail.com> wrote:
>>>> On 25 Feb 2017 11:51:26 GMT, Huge <Huge@nowhere.much.invalid> wrote:
>>>
>>> [21 lines snipped]
>>>
>>>> >Ditto where I live in South Norfolk. One place cuts keys, there are
>>>> >half-a-dozen PC menders.
>>>>
>>>> Wally world has automatic key cutters. Plug the key into the device,
>>>> it scans the key, asks you to select a standard or colorful blank, you
>>>> pay, it cuts new key. I don't think it does car keys.
>>>
>>> I have never heard of "Wally World".
>>>
>>> And many (most? all?) car keys these days have electronics in them and
>>> need to be paired to the car.
>>
>> Wally world is the nickname for Wall-Mart.
>
> Ahh, thank you. We don't have that in the Yoo Kay. I think they bought
> a large supermarket chain (ASDA), but they never rebranded it.
>
>> I have seen car keys that
>> don't have an electronic thingie in them. My car isn't recent.
>
> Hence the qualifications on my comment. Both my cars (an Audi & a Nissan)
> have electronics in the keys.
Not all keys start cars. It's those other keys which can't be dup'ed.
/BAH
|
|
|
|
| Re: The ICL 2900 [message #338480 is a reply to message #338429] |
Sun, 26 February 2017 09:10 |
jmfbahciv
Messages: 6173
Registered: March 2012
Karma: 0
|
Senior Member |
|
|
William Pechter wrote:
> In article <PM0005495C7E0A6F51@aca4033f.ipt.aol.com>,
> jmfbahciv <See.above@aol.com> wrote:
>
>> This was the first job I was paid to do. I'll try to write
>> up the next one in another post.
>>
>> /BAH
>
> 1. Don't forget "He who proposes disposes..." Make the suggestion for a
> change and you own it unless you're not competent.
I made lots of suggestions. It fell on deaf ears so I did the work
to get them started. I fully intended to see this work to the end
but the Fates intervened and I was moved to other areas. For the
machine-readable documentation project, my leaving was a good thing
because, later, a woman who really knew the typesetting business was
hired and she did a great job running that group. It ended up being
a cost center and she had groups in each plant.
>
> 2. Or as the job descriptions at most places had -- "Or other duties
> as required..."
Well, the other duties were my own ideas and never had approvals :-).
Note that I was not allowed to "work" extra hours because I was wage
class 2 (hourly pay). One of my personal goals was to become salaried
so that I didn't have to pay attention to the hours I did work.
I managed to do all the extra work at the same time I did the work
I was paid to do.
>
> This had Field Service rack mounting RA81's at mid level in DEC corporate
> cabinets on existing sites. There was a hydraulic lift supposely necessary.
> Try finding one in a Field Service DECwagon.
>
> Field Service equivalent I used... A pile of books on top of secretary's
> hydraulic office chair and prayer nothing slipped.
>
> Raise drive to height and slide out rails and connect them.
> Pray nothing slips.
>
> Otherwise you need more than one Field Engineer or a spinal surgeon
> to put you back together. RA81 weight 148 lbs... The RA60 was heavier.
{{{{{shudder}}}}}}
>
> This worked well on RL drives... tougher on RA.
I never did much work with FS. the second to last time was
to squash the guy who checked out each PDP-10 on the manufacturing
floor. He was still using MPB and other decade-old software.
FS had to use the pack he made for check out. What I did was
put my foot down and insist that the pack have the latest software
installed, including the monitor and CUSPs. I gave him his
own PPNs which he could use for his (supposedly) system checkout.
I made him very unhappy.
FS was crying for a pack which ran similar software to the customers
but, for reasons I never understood, they had to use the pack
that guy made for each system.
/BAH
|
|
|
|
|
|
| Re: The ICL 2900 [message #338482 is a reply to message #338424] |
Sun, 26 February 2017 09:11 |
jmfbahciv
Messages: 6173
Registered: March 2012
Karma: 0
|
Senior Member |
|
|
Jon Elson wrote:
> jmfbahciv wrote:
>
>
>> When I started about 75% of manuals were typed on a typewriter.
>> By the time I left, 25% were still done with a typewriter.
> Ohhh, I REMEMBER those!
>> The lag distribution time of getting a manual done on a typewriter
>> w.r.t. the software it described was 1-2 years. Getting the
>> manuals into machine-readable format reduced the lag by 2 years.
>> Distribution was within a few months after software distribution.
>> Eventually part of the ship criteria was having the documentation
>> shipped with the software. It took about 8 years for this
>> reduction of timing to be completed. I didn't do all the work;
>> I just started it by changing attitudes, hidden assumptions
>> and convincing management that documentation was just as
>> important as the hard/software.
>>
> Uhhh, how could you (DEC) ship a product without documentation? Yikes!
That was the purpose of the *.BWR, *.DOC, *.HLP files with each product.
If you look at the specifications in TOPS-10's Notebooks 12 and 13 (I think
those are the correct ones), you will see examples of the output of
Tape Prep using RUNOFF. The print quality was piss-poor and RUNOFF's
capabilities were minimal compared to a real typesetting system.
Software engineers wrote up their own BWR, HLP and DOC files. The
documentation group had to play catch up because of the production time
lag of the typing group who also cut and pasted a lot of the pages.
I just started the ball rolling. Later there was a woman who had
enormous experience in typesetting (I had none) who ran the
RUNOFF group I started; it became a cost center. In addition,
my efforts generated enough interest so that TYPESET-8 and
TYPESET-10 soft/hardware were developed and sold.
/BAH
|
|
|
|
|
|
| Re: The ICL 2900 [message #338489 is a reply to message #338434] |
Sun, 26 February 2017 11:52 |
Anne & Lynn Wheel
Messages: 3156
Registered: January 2012
Karma: 0
|
Senior Member |
|
|
hancock4@bbs.cpcn.com writes:
> from the National Observatory. I don't know if computers ever
> linked into that, or when the service was discontinued. But WU
> branch offices continued to show their synchronized clocks well
> into the 1960s.
science center had "chronolog" device (I don't remember where it got its
source) ... attached to 360/67 multiplexor channel (x'0ff') that cp67
read time/date at startup ... defined as some sort of tape device. all
the virtual machines had a virtual x'0ff' that they could read.
vmshare archives has discussion about NTP support for vm370
http://vm.marist.edu/~vmshare
trivia: person at delaware was earlier at Univ of Michigan and worked on
MTS for 360/67, and worked on PDP8 as "data concentrator" as terminal
controller ... which was latere replaced with pdp11 in the middle 70s.
https://www.eecis.udel.edu/~mills/gallery/gallery7.html
https://www.eecis.udel.edu/~mills/gallery/gallery8.html
later responsible for NTP protocol
5905 PS
Network Time Protocol Version 4: Protocol and Algorithms
Specification, Burbank J., Kasch W., Martin J., Mills D., 2010/06/21
(110pp) (.txt=241096) (Updated by 7822) (Obsoletes 1305, 4330) (See
Also 5906) (Refs 768, 791, 793, 1305, 1321, 1345, 4330) (Ref'ed By
5907, 5908, 5944, 5981, 6051, 6098, 6105, 6222, 6272, 6284, 6302,
6374, 6407, 6450, 6622, 6726, 6733, 6754, 6765, 6776, 6787, 6797,
6812, 6817, 6843, 6962, 6988, 7011, 7084, 7094, 7115, 7162, 7164,
7182, 7212, 7231, 7234, 7244, 7272, 7273, 7293, 7325, 7384, 7574,
7576, 7602, 7656, 7758, 7821, 7822, 7826, 7851, 8039)
1305 -
Network Time Protocol (v3), Mills D., 1992/04/09 (120pp)
(.pdf=442493, .tar=2682880, .txt=307085) (Obsoleted by 5905)
(Obsoletes 1119) (Refs 778, 781, 791, 792, 867, 868, 889, 891, 956,
957, 958, 1059, 1119) (Ref'ed By 1361, 1533, 1589, 1704, 1708, 1769,
1831, 1889, 2002, 2030, 2065, 2068, 2132, 2219, 2324, 2327, 2330,
2535, 2616, 2679, 2681, 2695, 2730, 2783, 2848, 2870, 2896, 2908,
2980, 3108, 3118, 3220, 3315, 3339, 3344, 3520, 3550, 3576, 3830,
3881, 3926, 3977, 4082, 4149, 4192, 4193, 4285, 4330, 4442, 4551,
4566, 4656, 4707, 4710, 4712, 4765, 4907, 5101, 5153, 5197, 5322,
5415, 5481, 5503, 5563, 5580, 5651, 5715, 5776, 5905, 5906) (NTPV3)
1119 -
Network Time Protocol version 2 specification and implementation,
Mills D., 1989/09/01 (64pp) (.pdf=187940, .ps=518020, .txt=143)
(Obsoleted by 1305) (Obsoletes 1059) (Ref'ed By 1165, 1190, 1305,
1700, 2375, 2822)
1059 -
Network Time Protocol version 1 specification and implementation,
Mills D., 1988/07/01 (58pp) (.txt=137645) (Obsoleted by 1119)
(Obsoletes 958) (Refs 768, 778, 781, 791, 792, 867, 868, 889, 891,
956, 958) (Ref'ed By 1305)
958 -
Network Time Protocol NTP, Mills D., 1985/09/01 (14pp) (.txt=30723)
(Obsoleted by 1059) (See Also 956, 957) (Refs 768, 778, 781, 792,
867, 868, 889, 891) (Ref'ed By 1057, 1059, 1305, 2924)
957
Experiments in network clock synchronization, Mills D., 1985/09/01
(27pp) (.txt=68952) (See Also 956, 958) (Refs 778, 781, 792, 867,
868, 889, 891) (Ref'ed By 1305)
956
Algorithms for synchronizing network clocks, Mills D., 1985/09/01
(26pp) (.txt=67387) (See Also 957, 958) (Refs 778, 781, 792, 867,
868, 889, 891) (Ref'ed By 1059, 1305)
.......
I've mentioned before about involved in something similar at univ starting
with interdata/3 ... which was later upgraded to interdata/4 (for
mainframe channel interface) and cluster of interdata/3s handling
line/port scanner interfaces. past posts
http://www.garlic.com/~lynn/subtopic.html#360pcm
--
virtualization experience starting Jan1968, online at home since Mar1970
|
|
|
|
| Re: The ICL 2900 [message #338490 is a reply to message #338479] |
Sun, 26 February 2017 12:07 |
pechter
Messages: 452
Registered: July 2012
Karma: 0
|
Senior Member |
|
|
In article <PM0005496F92714604@aca432e2.ipt.aol.com>,
jmfbahciv <See.above@aol.com> wrote:
> Huge wrote:
>> On 2017-02-25, JimP <solosam90@gmail.com> wrote:
>>> On 25 Feb 2017 19:29:01 GMT, Huge <Huge@nowhere.much.invalid> wrote:
>>>
>>>> On 2017-02-25, JimP <solosam90@gmail.com> wrote:
>>>> > On 25 Feb 2017 11:51:26 GMT, Huge <Huge@nowhere.much.invalid> wrote:
>>>>
>>>> [21 lines snipped]
>>>>
>>>> >>Ditto where I live in South Norfolk. One place cuts keys, there are
>>>> >>half-a-dozen PC menders.
>>>> >
>>>> > Wally world has automatic key cutters. Plug the key into the device,
>>>> > it scans the key, asks you to select a standard or colorful blank, you
>>>> > pay, it cuts new key. I don't think it does car keys.
>>>>
>>>> I have never heard of "Wally World".
>>>>
>>>> And many (most? all?) car keys these days have electronics in them and
>>>> need to be paired to the car.
>>>
>>> Wally world is the nickname for Wall-Mart.
>>
>> Ahh, thank you. We don't have that in the Yoo Kay. I think they bought
>> a large supermarket chain (ASDA), but they never rebranded it.
>>
>>> I have seen car keys that
>>> don't have an electronic thingie in them. My car isn't recent.
>>
>> Hence the qualifications on my comment. Both my cars (an Audi & a Nissan)
>> have electronics in the keys.
>
> Not all keys start cars. It's those other keys which can't be dup'ed.
>
> /BAH
I've been tempted to get an xx2247 cut so I had a PDP11 key on my keyring, even
though there's no non-emulated PDP11 here and the Vaxstation has no key.
Nothing like the turning on a key to bring up a machine. Have a circular
key for an old 386sx16 chassis. It was just a keylock -- but it felt so
PDP-like I kept connecting it to replacement upgrade motherboards until
they no longer
supported the keylock.
Bill
Bill
--
--
Digital had it then. Don't you wish you could buy it now!
pechter-at-gmail.com http://xkcd.com/705/
|
|
|
|
Members
Search
Help
Register
Login
Home
