- HECnet - lists @ Update

promiscuous mode, was Re: [HECnet] Multinet Tunnel Connections to SG1::

by Paul_Koning＠Dell.com

On Jun 8, 2012, at 3:18 PM, Johnny Billquist wrote: On 2012-06-08 19:02, Paul_Koning at Dell.com wrote: ... Thanks for making me re-read the DELQA manual again. :-) You're very welcome! I'm not totally clear on this point. This might be getting a little too technical and offtopic here, but basically, reading the manual, it might appear that having several unicast addresses in the setup might only be respected if you are running your DELQA in DEQNA mode, and the manual warn against potential performance issues if you do this. But I had forgotten quite a lot of the DEQNA/DELQA anyway, including that you were supposed to fill the table with your own address to make it full. Gah! I've never liked the Q-bus ethernet controllers. And they are so buggy... Johnny QNA, yes -- it was abandoned after revision L still didn't work right. LQA is a completely new design that does work, but it is compatible at the driver level with QNA (or nearly so). The address match is really very simple. There are no bugs here... the hardware has a 16 entry table and it accepts packets whenever the DA matches any of the 16 entries (essentially a 16 entry CAM). There are no "valid" bits (as you might find in some more advanced CAMs) so it treats all 16 entries as meaningful addresses. That means you have to fill in all 16. If you don't need 16 distinct values, you simply pad the table with extra copies of any of the meaningful values; that way the result is what you want. The easiest way to do that is to make extra copies of the entry that specifies the MAC address, but that isn't necessary, it is mentioned only because it's easy to remember. paul

13 years, 1 month

1
0
0 0

promiscuous mode, was Re: [HECnet] Multinet Tunnel Connections to SG1::

by bqt＠softjar.se

On 2012-06-08 19:02, Paul_Koning at Dell.com wrote: On Jun 8, 2012, at 10:50 AM, Johnny Billquist wrote: On 2012-06-08 16:42, Paul_Koning at Dell.com wrote: ... That's true if you have a NIC and driver that only allows one individual address per physical MAC. Most modern NICs allow multiple individual addresses since the address filter is an exact match on N (say, 16 or so) addresses, and it doesn't care whether those are individual or multicast. The host OS drivers may or may not export that feature. If they do, then you don't need promiscuous mode. If they don't, or if the NIC is old enough that it can't do this, then you do. Interesting. I wasn't aware that NICs had filters that didn't make a difference between multicast and unicast anymore... Seems potentially bad if you start using IP multicast, since that can easily become a whole bunch of multicast addresses, and then I guess you'll have to turn on promiscuous mode anyway. A typical modern NIC has (a) a modest-sized list of exact match filters, (b) a hash (CRC) based multicast filter, and usually (c) a separate flag to enable broadcast. So if you have at most, say, 16 unicast + multicast addresses enabled, it uses (a); if you have at most 16 unicast but too many multicast addresses, it uses (b) to do an approximate filter of the multicasts with the exact match done in the driver, and if you ask for more than 16 unicasts it will tell you that it can't do that. I have forgotten most of what I might have known of modern NICs, I think... The old DEC controllers for PDP-11s have a list of multicast addresses that you want to receive, so they do filter on multicast, but that list is for multicast only. There is only one unicast address. (Those controllers also have a separate multicast promiscuous mode, except it don't work on the DEQNA and DELQA...) Johnny That's not quite true. DEC, not surprisingly, was the first to identify the need for multiple unicast support in NICs, so the DECnet Ethernet datalink spec calls for it and all except the very oldest DEC NICs support that. Specifically, QNA and LQA do, because they take a 16 entry address filter. The QNA manual says that you put in the MAC address, broadcast, multicast addresses, plus extra copies of the MAC address, but in fact the device is perfectly happy to accept additional individual addresses. I believe VMS (and possibly other OSs) took advantage of this to allow LAT to come up first with the ROM based MAC address, then enable DECnet with its address without disturbing LAT. Thanks for making me re-read the DELQA manual again. :-) I'm not totally clear on this point. This might be getting a little too technical and offtopic here, but basically, reading the manual, it might appear that having several unicast addresses in the setup might only be respected if you are running your DELQA in DEQNA mode, and the manual warn against potential performance issues if you do this. But I had forgotten quite a lot of the DEQNA/DELQA anyway, including that you were supposed to fill the table with your own address to make it full. Gah! I've never liked the Q-bus ethernet controllers. And they are so buggy... Johnny

13 years, 1 month

1
0
0 0

Multinet Tunnel Connections to SG1::

by md.benson＠gmail.com

On 8 Jun 2012, at 16:58, Steve Davidson wrote: PATHWORKS for MAC V1.3... That's one option. Alternatively, I have White Pine Softwares Mac320 Terminal emulation package in a box on my shelf (original complete and working) which includes Thursby's DECnet stack, TSSnet (although I don't think/know if it is capable of file sharing in the Mac320 package). It works well as a terminal program but it's pretty antiquated and barely works on Macintosh System 7.0 (it was originally designed for Macintosh System 6.0). I have it installed on my SE/30 50MHz and it did okay. Wasn't anything special though. Some guy gave me that about 12 years ago. I had no idea what it was but he insisted. Kind a cool I eventually got to use it :) -- Mark Benson http://DECtec.info Twitter: @DECtecInfo HECnet: STAR69::MARK Online Resource & Mailing List for DEC Enthusiasts.

13 years, 1 month

1
0
0 0

promiscuous mode, was Re: [HECnet] Multinet Tunnel Connections to SG1::

by Paul_Koning＠Dell.com

On Jun 8, 2012, at 10:50 AM, Johnny Billquist wrote: On 2012-06-08 16:42, Paul_Koning at Dell.com wrote: ... That's true if you have a NIC and driver that only allows one individual address per physical MAC. Most modern NICs allow multiple individual addresses since the address filter is an exact match on N (say, 16 or so) addresses, and it doesn't care whether those are individual or multicast. The host OS drivers may or may not export that feature. If they do, then you don't need promiscuous mode. If they don't, or if the NIC is old enough that it can't do this, then you do. Interesting. I wasn't aware that NICs had filters that didn't make a difference between multicast and unicast anymore... Seems potentially bad if you start using IP multicast, since that can easily become a whole bunch of multicast addresses, and then I guess you'll have to turn on promiscuous mode anyway. A typical modern NIC has (a) a modest-sized list of exact match filters, (b) a hash (CRC) based multicast filter, and usually (c) a separate flag to enable broadcast. So if you have at most, say, 16 unicast + multicast addresses enabled, it uses (a); if you have at most 16 unicast but too many multicast addresses, it uses (b) to do an approximate filter of the multicasts with the exact match done in the driver, and if you ask for more than 16 unicasts it will tell you that it can't do that. The old DEC controllers for PDP-11s have a list of multicast addresses that you want to receive, so they do filter on multicast, but that list is for multicast only. There is only one unicast address. (Those controllers also have a separate multicast promiscuous mode, except it don't work on the DEQNA and DELQA...) Johnny That's not quite true. DEC, not surprisingly, was the first to identify the need for multiple unicast support in NICs, so the DECnet Ethernet datalink spec calls for it and all except the very oldest DEC NICs support that. Specifically, QNA and LQA do, because they take a 16 entry address filter. The QNA manual says that you put in the MAC address, broadcast, multicast addresses, plus extra copies of the MAC address, but in fact the device is perfectly happy to accept additional individual addresses. I believe VMS (and possibly other OSs) took advantage of this to allow LAT to come up first with the ROM based MAC address, then enable DECnet with its address without disturbing LAT. paul

13 years, 1 month

1
0
0 0

Multinet Tunnel Connections to SG1::

by sampsa＠mac.com

I wonder if that'll run in Basilisk - could pop up an emulated 68k classic System Mac on HECnet too.. Sampsa On 8 Jun 2012, at 16:58, Steve Davidson wrote: PATHWORKS for MAC V1.3... -Steve

13 years, 1 month

1
0
0 0

lunchbox VAXen, was Re: [HECnet] Introducing myself... and my little network

by angela＠kahealani.com

On Fri, Jun 08, 2012 at 12:32:04PM +0100, Peter Coghlan wrote: (How come I can remember this stuff and I have trouble remembering what happened yesterday!) That condition is a "medical" impairment whereby your brain is unable to successfuly transfer information from short term memory to long term memory, because you have a combination of too many toxins and not enough of the necessary nutrients to support building new neuronal pathways. Modern toxins are: MonoSodium Glutamate, Aspartame, Fluoride, Cesium, Plutonium, Uranium, etc... and the nutrients you need are not likely in the modern version of what people mistakenly call "food" but is mostly devoid of anything due to soil depletion. An example of something intended to help people like you (including all of us) is "cognition ignition" product from http://www.nutrimedical.com/ I have no relationship with Dr. Deagle's operations other than that I am a customer of some of his products. He is a leader in anti-aging research. Since mostly only us old-school old-farts care about DECtech, I considered the relevancy factor high enough here to venture a bit "off topic". -- Aloha, Avination: Celestial Angela; 2ndLife: Celeste Python; Angela Kahealani "(I'll) Be Seeing You..." All information and transactions are private between the parties, and are non negotiable. All rights reserve without prejudice by Angela Kahealani http://www.kahealani.com/kahealani/angela_kahealani.html

13 years, 1 month

1
0
0 0

Multinet Tunnel Connections to SG1::

by jeep＠scshome.net

PATHWORKS for MAC V1.3... -Steve -----Original Message----- From: owner-hecnet at Update.UU.SE [mailto:owner-hecnet at Update.UU.SE] On Behalf Of Gregg Levine Sent: Friday, June 08, 2012 11:09 To: hecnet at update.uu.se Subject: Re: [HECnet] Multinet Tunnel Connections to SG1:: On Fri, Jun 8, 2012 at 4:06 AM, Sampsa Laine <sampsa at mac.com> wrote: On 8 Jun 2012, at 00:10, Dave McGuire wrote: Of course it'd be preferable in a dozen ways to have the native kernel-based DECnet support continue to be maintained, alongside IPv4, IPv6, etc where it belongs...but if we can't find anyone to do that work, we'll have to solve the problem some other way, when it actually becomes a problem. The upside of this solution is that it's relatively portable though - I'd love to have a DECNET stack on my OS X boxes, for example (in fact as mentioned before latd DOES work on OS X as it's kinda implemented in a similar way).. Sampsa Hello! At one point in time, the OS for the Mac did speak natively to the DEC family of hardware. It would be very interesting to find out how they did it. This would greatly benefit Sampsa at least. As for us? Excellent question. ----- Gregg C Levine gregg.drwho8 at gmail.com "This signature fought the Time Wars, time and again."

13 years, 1 month

1
0
0 0

Multinet Tunnel Connections to SG1::

by gregg.drwho8＠gmail.com

On Fri, Jun 8, 2012 at 11:21 AM, Mark Benson <md.benson at gmail.com> wrote: On 8 Jun 2012, at 16:09, Gregg Levine <gregg.drwho8 at gmail.com> wrote: Hello! At one point in time, the OS for the Mac did speak natively to the DEC family of hardware. Do you mean OS X ir Classic Mac OS? It would be very interesting to find out how they did it. This would greatly benefit Sampsa at least. If it's OS X It'd benefit me too provided it still works on modern versions. -- Mark Benson http://markbenson.org/blog http://twitter.com/MDBenson Hello! Oh okay. Consider this, it was for the classic Mac. And the big guys. Shortly before the PowerPC processor was released. I remember going to a trade show that showed just such a network being there. They had everything named, including a VAX named VAX Masterston. I pointed out that the original name retired from being a gunfighter and ended up becoming a New York sportswriter. He died soon after that and ended up in Woodlawn. I can't recall if he was present at that gunfight. All of that took place sometime in the late 80s. ----- Gregg C Levine gregg.drwho8 at gmail.com "This signature fought the Time Wars, time and again."

13 years, 1 month

1
0
0 0

Multinet Tunnel Connections to SG1::

by md.benson＠gmail.com

On 8 Jun 2012, at 16:09, Gregg Levine <gregg.drwho8 at gmail.com> wrote: Hello! At one point in time, the OS for the Mac did speak natively to the DEC family of hardware. Do you mean OS X ir Classic Mac OS? It would be very interesting to find out how they did it. This would greatly benefit Sampsa at least. If it's OS X It'd benefit me too provided it still works on modern versions. -- Mark Benson http://markbenson.org/blog http://twitter.com/MDBenson

13 years, 1 month

1
0
0 0

Multinet Tunnel Connections to SG1::

by gregg.drwho8＠gmail.com

On Fri, Jun 8, 2012 at 4:06 AM, Sampsa Laine <sampsa at mac.com> wrote: On 8 Jun 2012, at 00:10, Dave McGuire wrote: Of course it'd be preferable in a dozen ways to have the native kernel-based DECnet support continue to be maintained, alongside IPv4, IPv6, etc where it belongs...but if we can't find anyone to do that work, we'll have to solve the problem some other way, when it actually becomes a problem. The upside of this solution is that it's relatively portable though - I'd love to have a DECNET stack on my OS X boxes, for example (in fact as mentioned before latd DOES work on OS X as it's kinda implemented in a similar way).. Sampsa Hello! At one point in time, the OS for the Mac did speak natively to the DEC family of hardware. It would be very interesting to find out how they did it. This would greatly benefit Sampsa at least. As for us? Excellent question. ----- Gregg C Levine gregg.drwho8 at gmail.com "This signature fought the Time Wars, time and again."

13 years, 1 month

1
0
0 0

netowrk flapping....

by rok.vidmar＠gmail.com

9 nyc9-peer-1.xe-1-2-0-unit0.tele2.net (130.244.64.138) 110 ms 110 ms 110 ms 10 198.32.118.31 (198.32.118.31) 100 ms 110 ms 110 ms 11 69.21.253.154 (69.21.253.154) 160 ms 140 ms 150 ms 12 * * * Route 13 cr2-TE-0-3-0-0.frankfurtft3.savvis.net (204.70.206.157) 21 ms 21 ms 21 ms 14 cr1-bundle-pos1.NewYork.savvis.net (204.70.196.137) 119 ms 119 ms 119 ms 15 er2-tengig-9-5.newyork.savvis.net (204.70.224.253) 118 ms 118 ms 118 ms 16 fortressitx.NewYork.savvis.net (206.24.195.134) 118 ms 118 ms 118 ms 17 wltonhhed11-gi1-2-1.network.tds.net (64.50.239.94) 133 ms 126 ms 125 ms 18 h69-21-253-154.wltonh.dedicated.static.tds.net (69.21.253.154) 158 ms 155 ms 156 ms seems to be OK. -- Regards, Rok

13 years, 1 month

1
0
0 0

promiscuous mode, was Re: [HECnet] Multinet Tunnel Connections to SG1::

by bqt＠softjar.se

On 2012-06-08 16:42, Paul_Koning at Dell.com wrote: On Jun 8, 2012, at 2:00 AM, Johnny Billquist wrote: On 2012-06-08 01:13, Dave McGuire wrote: On 06/07/2012 08:16 AM, Johnny Billquist wrote: Any program that needs access to raw ethernet packets needs to run as root. Promiscuous mode or not. Promiscuous mode itself has little to do with this. So if you want to run anything like a bridge or a router, you will need to run it as root. Promiscuous mode is basically just allowing you to share the same interface as the system is otherwise using, instead of having to dedicate a separate ethernet interface for this. Maybe you're just putting this another way, but promiscuous mode is correctly defined a bit differently than this. When an Ethernet controller is placed into promiscuous mode, its on-chip MAC address filters, which normally either select or ignore inbound packets based on their MAC address, are disabled. ALL packets are received by the hardware and passed to the Ethernet driver in the OS, rather than only the ones destined for that specific interface as defined by its MAC address. I'm reasonably certain that you know this but were just explaining it in a more abstract way...? Yes. Well, actually I wasn't describing it in a more abstract way, but in a way more in terms of why you need promiscuous mode instead of what it actually does on the interface. But reading it through now, I see that there was one implicit assumption in my text which I could have pointed out. If you need to share the device with the system, while using a different MAC address, you need to place the device in promiscuous mode. And such is the case if we talk DECnet, since DECnet requires that you use a specific MAC address which is not the same as the default MAC address of a device. That's true if you have a NIC and driver that only allows one individual address per physical MAC. Most modern NICs allow multiple individual addresses since the address filter is an exact match on N (say, 16 or so) addresses, and it doesn't care whether those are individual or multicast. The host OS drivers may or may not export that feature. If they do, then you don't need promiscuous mode. If they don't, or if the NIC is old enough that it can't do this, then you do. Interesting. I wasn't aware that NICs had filters that didn't make a difference between multicast and unicast anymore... Seems potentially bad if you start using IP multicast, since that can easily become a whole bunch of multicast addresses, and then I guess you'll have to turn on promiscuous mode anyway. The old DEC controllers for PDP-11s have a list of multicast addresses that you want to receive, so they do filter on multicast, but that list is for multicast only. There is only one unicast address. (Those controllers also have a separate multicast promiscuous mode, except it don't work on the DEQNA and DELQA...) Johnny

13 years, 1 month

1
0
0 0

New bridge.c feedback

by bqt＠softjar.se

On 2012-06-08 16:39, Paul_Koning at Dell.com wrote: On Jun 8, 2012, at 3:00 AM, Johnny Billquist wrote: On 2012-06-08 08:39, Boyanich, Alastair wrote: Hi Johnny, Your welcome. Yes, it's pretty chatty. MIPSPro and DECC are my favourite C compilers as they're quite anal and chatty warning wise. Yeah. gcc is stupid. They added -Wall several years ago, but apparently people got upset by it's anal reporting, so they dumbed it down. So -Wall does not turn on all warnings anymore. And I just don't have the enery right now to figure out what more switches I should throw on it to actually make it complain about everything... If you really want lots of warnings, say -Wall -Wpedantic. But in fact -Wall is quite good in more recent versions of gcc. The issues mentioned before would certainly be caught by GCC 4.6 or later. Well, with one caveat: quite a number of the things that gcc can warn about are found as a consequence of the deeper analysis done when you turn on optimization. So you need at least -O1 and more likely -O2 if you want to get good warnings. Actually, I didn't get any warnings with -Wall, for which the mips compiler complained about. (Well, I had already fixed two issues, but the others gcc didn't complain about.) Thanks, however. It was -Wpendantic that I was thinking of, even though I never seem to be able to remember the name. But I still think it is backwards to have a -Wall, which do not enable all warnings. :-) Johnny

13 years, 1 month

1
0
0 0

promiscuous mode, was Re: [HECnet] Multinet Tunnel Connections to SG1::

by Paul_Koning＠Dell.com

On Jun 8, 2012, at 2:00 AM, Johnny Billquist wrote: On 2012-06-08 01:13, Dave McGuire wrote: On 06/07/2012 08:16 AM, Johnny Billquist wrote: Any program that needs access to raw ethernet packets needs to run as root. Promiscuous mode or not. Promiscuous mode itself has little to do with this. So if you want to run anything like a bridge or a router, you will need to run it as root. Promiscuous mode is basically just allowing you to share the same interface as the system is otherwise using, instead of having to dedicate a separate ethernet interface for this. Maybe you're just putting this another way, but promiscuous mode is correctly defined a bit differently than this. When an Ethernet controller is placed into promiscuous mode, its on-chip MAC address filters, which normally either select or ignore inbound packets based on their MAC address, are disabled. ALL packets are received by the hardware and passed to the Ethernet driver in the OS, rather than only the ones destined for that specific interface as defined by its MAC address. I'm reasonably certain that you know this but were just explaining it in a more abstract way...? Yes. Well, actually I wasn't describing it in a more abstract way, but in a way more in terms of why you need promiscuous mode instead of what it actually does on the interface. But reading it through now, I see that there was one implicit assumption in my text which I could have pointed out. If you need to share the device with the system, while using a different MAC address, you need to place the device in promiscuous mode. And such is the case if we talk DECnet, since DECnet requires that you use a specific MAC address which is not the same as the default MAC address of a device. That's true if you have a NIC and driver that only allows one individual address per physical MAC. Most modern NICs allow multiple individual addresses since the address filter is an exact match on N (say, 16 or so) addresses, and it doesn't care whether those are individual or multicast. The host OS drivers may or may not export that feature. If they do, then you don't need promiscuous mode. If they don't, or if the NIC is old enough that it can't do this, then you do. paul

13 years, 1 month

1
0
0 0

New bridge.c feedback

by Paul_Koning＠Dell.com

On Jun 8, 2012, at 3:00 AM, Johnny Billquist wrote: On 2012-06-08 08:39, Boyanich, Alastair wrote: Hi Johnny, Your welcome. Yes, it's pretty chatty. MIPSPro and DECC are my favourite C compilers as they're quite anal and chatty warning wise. Yeah. gcc is stupid. They added -Wall several years ago, but apparently people got upset by it's anal reporting, so they dumbed it down. So -Wall does not turn on all warnings anymore. And I just don't have the enery right now to figure out what more switches I should throw on it to actually make it complain about everything... If you really want lots of warnings, say -Wall -Wpedantic. But in fact -Wall is quite good in more recent versions of gcc. The issues mentioned before would certainly be caught by GCC 4.6 or later. Well, with one caveat: quite a number of the things that gcc can warn about are found as a consequence of the deeper analysis done when you turn on optimization. So you need at least -O1 and more likely -O2 if you want to get good warnings. paul

13 years, 1 month

1
0
0 0

Introducing myself... and my little network

by pechter＠gmail.com

On Thu, Jun 7, 2012 at 7:14 PM, Dave McGuire <mcguire at neurotica.com> wrote: On 06/07/2012 08:35 AM, Jordi Guillaumes i Pons wrote: According to this: http://h71000.www7.hp.com/openvms/os/openvms-release-history.html Support for the 4000/90 came in version 5.5-2 (1992). The 3300 was supported in 5.0-2 and the 4000 mod. 2000 in 5.4-2. So none of my real boxen can run 4.7. Well you've gotta find yourself some more machines! 11/750s are probably the most common of the 4.x-capable machines, though there don't seem to be many left floating around. Heh, then I would have to find also a new home and probably an attorney to handle de divorce demand ;) I'll keep my mouth shut.. ;) -- Dave McGuire, AK4HZ New Kensington, PA My wife refers to the 11/7xx boxes I worked on as my old girlfriends. If one more piece of hardware hits the house I'll need the same lawyer. As soon as I can find it a good home I'm getting rid of my Vaxstation and going to go to only emulated hardware under VMware Workstation/ESXi/XenServer at home. Bill Pechter, N2RDI Holmdel, NJ -- d|i|g|i|t|a|l had it THEN. Don't you wish you could still buy it now! pechter-at-gmail.com

13 years, 1 month

1
0
0 0

lunchbox VAXen, was Re: [HECnet] Introducing myself... and my little network

by pechter＠gmail.com

On Thu, Jun 7, 2012 at 7:42 PM, Bob Armstrong <bob at jfcl.com> wrote: Lunchboxes! :-) And there are images for new boot ROMs available for those which will allow you to boot from the on-board SCSI host adapter, ... I've heard of this, but I haven't seen it. As I recall, the onboard SCSI adapter uses programmed I/O (no DMA!) so it's really slow. For a TK50 nobody would ever notice, but for the system disk it's a problem. Better to cluster boot one, diskless. FWIW, an RD54 isn't necessary. The 2000 can easily be convinced to use _any_ MFM drive, DEC or not. You can get VMS V4 on a 30 meg drive, maybe even 20, if you're determined. Long ago I wrote up a little description of all the VS 2000 disk formatter parameters, what they meant, and how to fake them for non-DEC drives. Google ancient Usenet postings if you're interested. Bob The real problem I've found lately is getting VMS V4 or V3. I used to do installs of V2, V3, and V4 when I was at DEC. It is really hard to find VMS installation media of the pre CD variety. We really could use an archive site for stuff like this, but HP would probably have a fit over the copyright. Unfortunately, getting a legal archive will probably not happen. Bill -- d|i|g|i|t|a|l had it THEN. Don't you wish you could still buy it now! pechter-at-gmail.com

13 years, 1 month

1
0
0 0

netowrk flapping....

by bob＠jfcl.com

We (all of us with Multinet, I think) see this problem occasionally. AFAIK no one has come up with an adequate explanation, let alone a solution. You can always turn off logging if it bothers you :-) Bob

13 years, 1 month

1
0
0 0

Introducing myself... and my little network

by md.benson＠gmail.com

On 8 Jun 2012, at 10:58, Johnny Billquist <bqt at softjar.se> wrote: Yes, a TZ87 (DLT2000) can read TK50 tapes and TK70 tapes as well. Really? That is even better. I had a fleeting memory of the TZ87, but I just assumed I must be remembering wrong. That lines up, my DLT4000 is a TZ88 and won't, was the first DLT that didn't read them IIRC -- Mark Benson http://markbenson.org/blog http://twitter.com/MDBenson

13 years, 1 month

1
0
0 0

lunchbox VAXen, was Re: [HECnet] Introducing myself... and my little network

by HECNET＠beyondthepale.ie

Lunchboxes! :-) And there are images for new boot ROMs available for those which will allow you to boot from the on-board SCSI host adapter, which is relatively slow (NCR5380-based) but still less painful than trying to find, and then afford to purchase, an RD54. I think someone even wrote a driver for VMS to use disks on that controller. I have several of those machines; I really should look into that. Does anyone have any further information on, or actual copies of, those boot ROMs and/or the VMS device driver? That's a patch for VAX/VMS 5.5-2 called PK2KDRVR which Wolfgang Moeller wrote in response to the moaning years ago on comp.os.vms etc that the VS2000 would be so much more useful if it could use SCSI disks. To his surprise, he found there was very little interest in his solution. I was interested and I found the patched driver worked well. I found I couldn't tell if it was slow or not as the 2000 is so slow anyway! I never tried the patched boot ROMs as I boot my 2000's from a 3100. (How come I can remember this stuff and I have trouble remembering what happened yesterday!) Wolfgang also did patches for VS3100 boot ROMs which had problems booting disks over 1GB in size. I also have another patch he wrote which makes the floppy driver in a 2000 treat the drive as an RX23 instead of an RX33 making it possible for VMS to correctly access 3.5in disks in a 2000. I've put what I have on CEIRE:: (I can't find the original PK2KDRVR.ZIP so I've just zipped up the contents of my PK2KDRVR directory which is likely what I got when I unzipped the original zip file...) Regards, Peter Coghlan.

13 years, 1 month

1
0
0 0

Introducing myself... and my little network

by bqt＠softjar.se

On 2012-06-08 11:10, Kari Uusim ki wrote: On 8.6.2012 10:31, Mark Benson wrote: On 8 Jun 2012, at 08:23, Dave McGuire<mcguire at neurotica.com> wrote: I haven't tried cleaning TK50 heads in years, but I will (now that I have a more respectable workspace) start trying that. I will let you know how things go. I'll probably start digging into those within the next month or two. Thank you for the suggestion! I take it TK50 tapes won't read in a later drive? Yes, a TZ87 (DLT2000) can read TK50 tapes and TK70 tapes as well. Really? That is even better. I had a fleeting memory of the TZ87, but I just assumed I must be remembering wrong. Johnny

13 years, 1 month

1
0
0 0

Introducing myself... and my little network

by bqt＠softjar.se

On 2012-06-08 11:10, Dave McGuire wrote: On 06/08/2012 05:08 AM, Mark Benson wrote: The TK85 can read TK50s? I didn't know that! If that's the case, it's likely that the TF85 (DSSI version) may as well, and I have one of those. That may be one more option to get my huge pile of TK50s read. I had a feeling the later TKs read TK50. I read it on on of HP's DLT compatibility docs but couldn't remember if it was TK50 or TK70 that was the oldest compatible format. I have a SCSI-II DLT4000 drive (TK88 or 89??) and I know that doesn't read any old TK tapes, only DLT1,2 etc. The general rule with most of those format is that the current drive will read and write the current format, and read (but not write) the previous format. There are of course exceptions, but not many. Indeed. Such as the Tx85 reading both TK50 and TK70. :-) Johnny

13 years, 1 month

1
0
0 0

DECnet-DOS, was Re: [HECnet] Size of HECnet

by mcguire＠neurotica.com

On 06/08/2012 05:11 AM, Mark Benson wrote: Dave outside your door is a well dressed gentleman in a suit that looks like something a certain outrageous poet and author wore, and has hair to match. (Hint: its the same daft stuff I sometimes pull on Sampsa.) There's also a blue colored box outside......... Ok, you lost me there, my friend. Welcome to the world of strange Dr Who references.. Uh-oh. Explains why I didn't get it either (not a fan). Me neither. ;) No offense, Gregg! -Dave -- Dave McGuire, AK4HZ New Kensington, PA

13 years, 1 month

1
0
0 0

Introducing myself... and my little network

by mcguire＠neurotica.com

On 06/08/2012 04:24 AM, Johnny Billquist wrote: I haven't tried cleaning TK50 heads in years, but I will (now that I have a more respectable workspace) start trying that. I will let you know how things go. I'll probably start digging into those within the next month or two. Thank you for the suggestion! I take it TK50 tapes won't read in a later drive? They will. TK70 and TK85 (if I remember right) can both read TK50. You also have the TZ30 (I think the name is), which is a TK50 compatible, but smaller drive, with SCSI. The TK85 can read TK50s? I didn't know that! If that's the case, it's likely that the TF85 (DSSI version) may as well, and I have one of those. That may be one more option to get my huge pile of TK50s read. Yes, it should. See http://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&cd=5&ved=0CGYQFjA… (Page 5) Thanks for the info! This gives me a nice option. -Dave -- Dave McGuire, AK4HZ New Kensington, PA

13 years, 1 month

1
0
0 0

DECnet-DOS, was Re: [HECnet] Size of HECnet

by md.benson＠gmail.com

On 8 Jun 2012, at 10:09, Dave McGuire <mcguire at neurotica.com> wrote: On 06/08/2012 04:58 AM, Sampsa Laine wrote: Dave outside your door is a well dressed gentleman in a suit that looks like something a certain outrageous poet and author wore, and has hair to match. (Hint: its the same daft stuff I sometimes pull on Sampsa.) There's also a blue colored box outside......... Ok, you lost me there, my friend. Welcome to the world of strange Dr Who references.. Uh-oh. Explains why I didn't get it either (not a fan). -- Mark Benson http://markbenson.org/blog http://twitter.com/MDBenson

13 years, 1 month

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

HECnet