At 7:12 PM -0700 8/27/08, Zane H. Healy wrote:
At 9:25 PM -0400 8/27/08, Fred wrote:
Good evening ...
Got NOTES installed.
However, after adding the couple of conferences I saw at the nodes listing on avanthar:8080/nodes ... (specifically MONK::VMS for starters) trying to open that conference reveals:
Notes>
Login information invalid at remote node
Looks like the owner of MONK doesn't have NOTES set up for "remote" or HECNet access. :(
Let me take a look at it, something must be wrong.
If anyone has any ideas on this, I'd love to hear them. I've been looking and have been unable to find anything. I had it working so you could read NOTES conferences from PDXVAX, but that gives the same error now. I am able to read them from MONK. I don't see any sign of any management manual either.
Of course I have no idea when this last worked...
Zane
--
| Zane H. Healy | UNIX Systems Administrator |
| healyzh at aracnet.com (primary) | OpenVMS Enthusiast |
| MONK::HEALYZH (DECnet) | Classic Computer Collector |
+----------------------------------+----------------------------+
| Empire of the Petal Throne and Traveller Role Playing, |
| PDP-10 Emulation and Zane's Computer Museum. |
| http://www.aracnet.com/~healyzh/ |
At 9:25 PM -0400 8/27/08, Fred wrote:
Good evening ...
Got NOTES installed.
However, after adding the couple of conferences I saw at the nodes listing on avanthar:8080/nodes ... (specifically MONK::VMS for starters) trying to open that conference reveals:
Notes>
Login information invalid at remote node
Looks like the owner of MONK doesn't have NOTES set up for "remote" or HECNet access. :(
Let me take a look at it, something must be wrong.
Zane
--
| Zane H. Healy | UNIX Systems Administrator |
| healyzh at aracnet.com (primary) | OpenVMS Enthusiast |
| MONK::HEALYZH (DECnet) | Classic Computer Collector |
+----------------------------------+----------------------------+
| Empire of the Petal Throne and Traveller Role Playing, |
| PDP-10 Emulation and Zane's Computer Museum. |
| http://www.aracnet.com/~healyzh/ |
At 8:20 PM -0400 8/27/08, Fred wrote:
On Wed, 27 Aug 2008, Bob Armstrong wrote:
VAX Notes is on the OpenVMS Freeware CD V7, disk 2 -
http://h71000.www7.hp.com/openvms/freeware/
I'm not clear on whether there was ever an Alpha version of Notes...
Well, since MONK is a Compaq XP1000/667 I sure hope there is an Alpha version. :^)
Found individual packages from the freeware distribution (includes notes for Alpha and a field-test for Alpha and port to IA64.)
http://mvb.saic.com/freeware/freewarev70/notes/
Downloading now, installing shortly. :)
I believe the IA64 version is due to the OpenVMS development team using Notes.
BTW, you can log into PDXVAX and use the Notes client on it. Last I checked no one has really made use of the Notes conferences on MONK other than to post a couple test messages.
Zane
--
| Zane H. Healy | UNIX Systems Administrator |
| healyzh at aracnet.com (primary) | OpenVMS Enthusiast |
| MONK::HEALYZH (DECnet) | Classic Computer Collector |
+----------------------------------+----------------------------+
| Empire of the Petal Throne and Traveller Role Playing, |
| PDP-10 Emulation and Zane's Computer Museum. |
| http://www.aracnet.com/~healyzh/ |
Good evening ...
Got NOTES installed.
However, after adding the couple of conferences I saw at the nodes listing on avanthar:8080/nodes ... (specifically MONK::VMS for starters) trying to open that conference reveals:
Notes>
Login information invalid at remote node
Looks like the owner of MONK doesn't have NOTES set up for "remote" or HECNet access. :(
If nothing else I have my own private install of NOTES now so I don't look like a total idiot when I'm posting on Encompasserve ... ;)
The kits from mvb.saic.com do work - I used notes026.a and had to run a "fix backup attributes" DCL routine to straighten out the file attributes, otherwise VMSINSTAL (actually BACKUP) barfed all over. Probably related to transfering it to my laptop first before FTP'ing it to MISER.
That's enough beating on the Alpha for one night. :) I really should consider figuring out a way to do an /IMAGE backup on this thing soon, too ...
Fred
On Wed, 27 Aug 2008, Bob Armstrong wrote:
VAX Notes is on the OpenVMS Freeware CD V7, disk 2 -
http://h71000.www7.hp.com/openvms/freeware/
I'm not clear on whether there was ever an Alpha version of Notes...
Found individual packages from the freeware distribution (includes notes for Alpha and a field-test for Alpha and port to IA64.)
http://mvb.saic.com/freeware/freewarev70/notes/
Downloading now, installing shortly. :)
Fred
I would love a copy of that as well.
Sampsa
On 27 Aug 2008, at 21:48, Fred wrote:
Hi all ...
I noticed MONK:: has some notes conferences available. I'd like to browse them, but my Alpha is missing a NOTES kit. I downloaded a kit from an associate of mine, but my two problems are:
1. his Alpha is shut down at the moment
2. I downloaded the Japanese kit from his Alpha by accident
Could someone zip up a (English) notes kit for me and send it? I can also FTP or do a copy over HECNET if you give me a node::disk:[dir] combo ... :)
Cheers,
Fred
Hi all ...
I noticed MONK:: has some notes conferences available. I'd like to browse them, but my Alpha is missing a NOTES kit. I downloaded a kit from an associate of mine, but my two problems are:
1. his Alpha is shut down at the moment
2. I downloaded the Japanese kit from his Alpha by accident
Could someone zip up a (English) notes kit for me and send it? I can also FTP or do a copy over HECNET if you give me a node::disk:[dir] combo ... :)
Cheers,
Fred
I am aware of the issues with both ECB (statistical inference, known plaintext attacks, replay
attacks etc etc) and CRC-32. However considering the application (i.e. to stop DECNET credentials
going over the wide Internet entirely in the clear and rudimentary identification of the end-points) I doubt
that there would be many attackers who would bother with the extra effort of attacking this compared to
the current completely unprotected setup.
But since this doesn't seem to interest that many people anyway I think I'll give it a miss.
Sampsa
On 25 Aug 2008, at 15:44, Paul Koning wrote:
Sampsa> My proposal is that each end point of a bridge connection
Sampsa> share a secret and use some form of symmetric encryption (say
Sampsa> AES in ECB mode) whilst communicating....
Sampsa> A CRC-32 (of the unencrypted frame) would be used to
Sampsa> determine the validity of the data.
Um, no.
I rather doubt this sort of thing is worth doing, but if you think
it's useful, you should use a design that has the right security
properties.
Doing crypto right is hard -- much harder than you might think. ECB
is never right; neither is CRC for integrity (in a crypto setting).
On the other hand, the right way already exists. Just turn on IPsec.
If you want to invent your own, you should study IPsec to see how it
is constructed, and understand why it is constructed that way.
Studying the prior art is a good idea. It helps to avoid building
stuff that doesn't work. And unfortunately there's plenty of that.
WEP is a classic example of a "security" system designed by people who
didn't know what they were doing, and didn't know that they didn't know.
paul
"Sampsa" == Sampsa Laine <sampsa at mac.com> writes:
Sampsa> Guys, I've had an idea for improving the usability and
Sampsa> security of the bridge: Encryption.
Sampsa> Now I realise that we're not dealing with a massively
Sampsa> high-security installation here with with HECnet but please
Sampsa> hear me out :)
Sampsa> My proposal is that each end point of a bridge connection
Sampsa> share a secret and use some form of symmetric encryption (say
Sampsa> AES in ECB mode) whilst communicating....
Sampsa> A CRC-32 (of the unencrypted frame) would be used to
Sampsa> determine the validity of the data.
Um, no.
I rather doubt this sort of thing is worth doing, but if you think
it's useful, you should use a design that has the right security
properties.
Doing crypto right is hard -- much harder than you might think. ECB
is never right; neither is CRC for integrity (in a crypto setting).
On the other hand, the right way already exists. Just turn on IPsec.
If you want to invent your own, you should study IPsec to see how it
is constructed, and understand why it is constructed that way.
Studying the prior art is a good idea. It helps to avoid building
stuff that doesn't work. And unfortunately there's plenty of that.
WEP is a classic example of a "security" system designed by people who
didn't know what they were doing, and didn't know that they didn't know.
paul
Yeah, that might be version 2 then :)
At the moment I'll just add some code to do the AES encryption and identity verification using CRC-32.
Sampsa.
On 25 Aug 2008, at 11:38, Johnny Billquist wrote:
Sampsa Laine wrote:
I figured I might just add some kind of identifier to the packet, and just grab the source address of the packet and use it as the new address, every time. Would this not work?
Well, you need to change the current code, since it don't work that way.
Also, you need to figure out which "old" source the packet came from, so that you don't change the source for the wrong other endpoint.
At my end, the bridge is talking to about 12 different other ends...
Johnny
Sampsa
On 25 Aug 2008, at 09:48, Johnny Billquist wrote:
Sampsa Laine wrote:
OK, I'll have a go at it later on today if possible, this literally should not be TOO difficult to code in.
Oh, it should definitely be easy. The data receive and data transmit are located in very few places.
There are some trickery in there that you additionally need to maybe think about, such as the code that tries to avoid receiving the same packets that are sent out.
Also, if you later plan to add functionality to enable sending meta-data, such as IP address changes, you need to change the contents of the packets, remove the verification of source address of data, maybe add some handling to make sure that address changes packets really are received (remember, this is all UDP).
There might be some other things to think about as well. Can't think of anything offhand, but one never knows... :-)
Johnny
Sampsa
On 25 Aug 2008, at 09:27, Johnny Billquist wrote:
Sampsa Laine wrote:
Guys,
I've had an idea for improving the usability and security of the bridge: Encryption.
Now I realise that we're not dealing with a massively high-security installation here with
with HECnet but please hear me out :)
Gha! Feel free.
But I don't really want to fool around with that. My aim was to get something rather simple, that was easy to diagnose when problems occur. :-)
So I'll stick with my version for now. If someone else hacks something together, I might install it if it don't add much overhead to the data.
Johnny
Sampsa Laine wrote:
I figured I might just add some kind of identifier to the packet, and just grab the source address of the packet and use it as the new address, every time. Would this not work?
Well, you need to change the current code, since it don't work that way.
Also, you need to figure out which "old" source the packet came from, so that you don't change the source for the wrong other endpoint.
At my end, the bridge is talking to about 12 different other ends...
Johnny
Sampsa
On 25 Aug 2008, at 09:48, Johnny Billquist wrote:
Sampsa Laine wrote:
OK, I'll have a go at it later on today if possible, this literally should not be TOO difficult to code in.
Oh, it should definitely be easy. The data receive and data transmit are located in very few places.
There are some trickery in there that you additionally need to maybe think about, such as the code that tries to avoid receiving the same packets that are sent out.
Also, if you later plan to add functionality to enable sending meta-data, such as IP address changes, you need to change the contents of the packets, remove the verification of source address of data, maybe add some handling to make sure that address changes packets really are received (remember, this is all UDP).
There might be some other things to think about as well. Can't think of anything offhand, but one never knows... :-)
Johnny
Sampsa
On 25 Aug 2008, at 09:27, Johnny Billquist wrote:
Sampsa Laine wrote:
Guys,
I've had an idea for improving the usability and security of the bridge: Encryption.
Now I realise that we're not dealing with a massively high-security installation here with
with HECnet but please hear me out :)
Gha! Feel free.
But I don't really want to fool around with that. My aim was to get something rather simple, that was easy to diagnose when problems occur. :-)
So I'll stick with my version for now. If someone else hacks something together, I might install it if it don't add much overhead to the data.
Johnny
I figured I might just add some kind of identifier to the packet, and just grab the source address of the packet and use it as the new address, every time. Would this not work?
Sampsa
On 25 Aug 2008, at 09:48, Johnny Billquist wrote:
Sampsa Laine wrote:
OK, I'll have a go at it later on today if possible, this literally should not be TOO difficult to code in.
Oh, it should definitely be easy. The data receive and data transmit are located in very few places.
There are some trickery in there that you additionally need to maybe think about, such as the code that tries to avoid receiving the same packets that are sent out.
Also, if you later plan to add functionality to enable sending meta-data, such as IP address changes, you need to change the contents of the packets, remove the verification of source address of data, maybe add some handling to make sure that address changes packets really are received (remember, this is all UDP).
There might be some other things to think about as well. Can't think of anything offhand, but one never knows... :-)
Johnny
Sampsa
On 25 Aug 2008, at 09:27, Johnny Billquist wrote:
Sampsa Laine wrote:
Guys,
I've had an idea for improving the usability and security of the bridge: Encryption.
Now I realise that we're not dealing with a massively high-security installation here with
with HECnet but please hear me out :)
Gha! Feel free.
But I don't really want to fool around with that. My aim was to get something rather simple, that was easy to diagnose when problems occur. :-)
So I'll stick with my version for now. If someone else hacks something together, I might install it if it don't add much overhead to the data.
Johnny
Sampsa Laine wrote:
OK, I'll have a go at it later on today if possible, this literally should not be TOO difficult to code in.
Oh, it should definitely be easy. The data receive and data transmit are located in very few places.
There are some trickery in there that you additionally need to maybe think about, such as the code that tries to avoid receiving the same packets that are sent out.
Also, if you later plan to add functionality to enable sending meta-data, such as IP address changes, you need to change the contents of the packets, remove the verification of source address of data, maybe add some handling to make sure that address changes packets really are received (remember, this is all UDP).
There might be some other things to think about as well. Can't think of anything offhand, but one never knows... :-)
Johnny
Sampsa
On 25 Aug 2008, at 09:27, Johnny Billquist wrote:
Sampsa Laine wrote:
Guys,
I've had an idea for improving the usability and security of the bridge: Encryption.
Now I realise that we're not dealing with a massively high-security installation here with
with HECnet but please hear me out :)
Gha! Feel free.
But I don't really want to fool around with that. My aim was to get something rather simple, that was easy to diagnose when problems occur. :-)
So I'll stick with my version for now. If someone else hacks something together, I might install it if it don't add much overhead to the data.
Johnny
OK, I'll have a go at it later on today if possible, this literally should not be TOO difficult to code in.
Sampsa
On 25 Aug 2008, at 09:27, Johnny Billquist wrote:
Sampsa Laine wrote:
Guys,
I've had an idea for improving the usability and security of the bridge: Encryption.
Now I realise that we're not dealing with a massively high-security installation here with
with HECnet but please hear me out :)
Gha! Feel free.
But I don't really want to fool around with that. My aim was to get something rather simple, that was easy to diagnose when problems occur. :-)
So I'll stick with my version for now. If someone else hacks something together, I might install it if it don't add much overhead to the data.
Johnny
Sampsa Laine wrote:
Guys,
I've had an idea for improving the usability and security of the bridge: Encryption.
Now I realise that we're not dealing with a massively high-security installation here with
with HECnet but please hear me out :)
Gha! Feel free.
But I don't really want to fool around with that. My aim was to get something rather simple, that was easy to diagnose when problems occur. :-)
So I'll stick with my version for now. If someone else hacks something together, I might install it if it don't add much overhead to the data.
Johnny
Guys,
I've had an idea for improving the usability and security of the bridge: Encryption.
Now I realise that we're not dealing with a massively high-security installation here with
with HECnet but please hear me out :)
My proposal is that each end point of a bridge connection share a secret and use some
form of symmetric encryption (say AES in ECB mode) whilst communicating. This shouldn't
be terribly difficult to achieve (I might take a look at coding this myself once the rum-fuelled
haze from last night's Notting Hill Carnival wears off) in a fairly small amount of code.
If in addition a receiver of a valid packet constantly updated the target address of it's packets
to the source address of the last valid packet received the arrangement would not only ensure
that the host sending the data is in fact who they claim they are, but would enable a sending
host to change its IP address without borking things up, thus making our beloved bridge
usable on dynamic IP setups.
A CRC-32 (of the unencrypted frame) would be used to determine the validity of the data.
Example connection, Host A -> B
1. A receives a decnet frame on ethernet
2. A calculates a CRC-32 for the frame
3. A encrypts frame using shared secret with B
4. A appends CRC-32 from step 2 to the encrypted frame from step 3.
5. Frame is sent to B
6. B decrypts frame using shared secret with A
7. B calculates a CRC-32 of decrypted frame, compares with received CRC-32
8. Are they equal, if not abort.
9. Frame is valid, send onto ethernet.
10. B updates A's address to that of source address of the last frame.
Comments anyone?
Sampsa
On Sun, Aug 24, 2008 at 8:33 AM, Johnny Billquist <bqt at softjar.se> wrote:
Zane H. Healy wrote:
At 8:40 AM +0200 8/24/08, Johnny Billquist wrote:
Zane H. Healy wrote:
I assume 4.6 should have a separate tape for the DECnet install?
If you by that mean that DECnet isn't on the normal RSX distribution,
then yes.
If, on the other hand, you guess that the DECnet distribution itself is
multiple tapes, then no. It's only one tape in 4.6. It was only one tape in
4.5 as well. I can't remember if it was one or two tapes in 4.4 now.
I was simply asking if the DECnet distribution was separate from the RSX
distribution. Which means I'm lacking DECnet.
Ok. I wasn't sure. In the past, the DECnet distribution was on two (or
three) tapes. I don't think it have ever been on the same tapes as RSX
itself. And in the past, the RSX distribution came on two tapes as well, You
had the BRUSYS tape, and then the actual system. But that changed in the
last few releases as well.
Johnny
Hello!
Well I did mention that the Trailing-Edge ftp site was up to it's ears
in things and as it happens I didn't find the tapes for RSX, but I did
find stuff for RSTS:
Index of ftp://ftp.trailing-edge.com/pub/rsts_dists
Up to higher level directory
File: basic_plus_2_v2_1.zip 553 KB 10/30/2005 12:00:00 AM
File: basic_plus_2_v2_2.zip 282 KB 10/30/2005 12:00:00 AM
File: basic_plus_2_v2_3.zip 784 KB 10/30/2005 12:00:00 AM
File: basic_plus_2_v2_4.zip 1169 KB 10/30/2005 12:00:00 AM
File: basic_plus_2_v2_5.zip 1214 KB 10/30/2005 12:00:00 AM
File: basic_plus_2_v2_6.zip 1983 KB 10/30/2005 12:00:00 AM
File: basic_translator_rsts_fieldtext.tap.bz2 50 KB 10/30/2005 12:00:00 AM
File: bb-k400d-bc_pdp_f77_rsts_v5_0_c1983.tap.bz2 210 KB 10/30/2005
12:00:00 AM
File: bb-k400e-bc_pdp_f-77_rsts_v5_w_c1987.tap.bz2 303 KB 10/30/2005
12:00:00 AM
File: bb-k400e-bc_pdp_f77_rsts_v5_2_c1987.tap.bz2 303 KB 10/30/2005
12:00:00 AM
File: bb-k400f-bc_pdp_f77_rsts_v5_3_c1988.tap.bz2 300 KB 10/30/2005
12:00:00 AM
File: bb-p655c-bc_decmail11rsts_v3_0_c1986.tap.bz2 972 KB 10/30/2005
12:00:00 AM
File: bp2_v2_7.zip 1804 KB 10/30/2005 12:00:00 AM
File: c_v1_2.zip 1658 KB 10/30/2005 12:00:00 AM
File: cobol-11_v4_4.zip 606 KB 10/30/2005 12:00:00 AM
File: cobol-81_v2_3.zip 577 KB 10/30/2005 12:00:00 AM
File: decmail-11_v3_1.zip 461 KB 10/30/2005 12:00:00 AM
File: decnet-e_v2_0.zip 382 KB 10/30/2005 12:00:00 AM
File: decnet-e_v2_1.zip 811 KB 10/30/2005 12:00:00 AM
File: decnet-e_v4_0.zip 1113 KB 10/30/2005 12:00:00 AM
File: decnet-e_v4_1.zip 703 KB 10/30/2005 12:00:00 AM
File: f4p_rl02.zip 697 KB 10/30/2005 12:00:00 AM
File: f77_v5_3.zip 317 KB 10/30/2005 12:00:00 AM
File: fms11_v2_1.zip 321 KB 10/30/2005 12:00:00 AM
File: fortran-77_v5_4.zip 504 KB 10/30/2005 12:00:00 AM
File: fortran_iv_v2_8.zip 277 KB 10/30/2005 12:00:00 AM
File: microrsts.zip 3371 KB 10/30/2005 12:00:00 AM
File: pdp-11_c_for_rsts_e_t1_0_ft_7july89.tap.bz2 526 KB 10/30/2005
12:00:00 AM
File: pdp-11_c_for_rsts_e_t1_1_7_13_90.tap.bz2 1097 KB 10/30/2005 12:00:00 AM
File: pdp-11_c_for_rsts_e_v1_0_22_dec_89.tap.bz2 1003 KB 10/30/2005
12:00:00 AM
File: pdp-11_c_t1_0_fieldtest2_rstse.tap.bz2 762 KB 10/30/2005 12:00:00 AM
File: pdp11_c_rsts_v1_1.zip 1623 KB 10/30/2005 12:00:00 AM
File: rsts_e_v9_3_ft_update.tap.bz2 5054 KB 10/30/2005 12:00:00 AM
File: rsts_v8_csp180.zip 2289 KB 10/30/2005 12:00:00 AM
File: rsts_v8_sysgnl.zip 3484 KB 10/30/2005 12:00:00 AM
File: rsts_v8_update-g.zip 3397 KB 10/30/2005 12:00:00 AM
File: rsts_v9_0_install.zip 2331 KB 10/30/2005 12:00:00 AM
File: rsts_v9_1_install.zip 4016 KB 10/30/2005 12:00:00 AM
File: rsts_v9_2_install.zip 5320 KB 10/30/2005 12:00:00 AM
File: rsts_v9_3_install.zip 5900 KB 10/30/2005 12:00:00 AM
File: rsts_v9_4_install.zip 6636 KB 10/30/2005 12:00:00 AM
File: rsts_v9_5_install.zip 7297 KB 10/30/2005 12:00:00 AM
File: rsts_v9_6_install.zip 7883 KB 10/30/2005 12:00:00 AM
File: rsts_v9_library.zip 4852 KB 10/30/2005 12:00:00 AM
File: rstse_v9_3_field_test.tap.bz2 5013 KB 10/30/2005 12:00:00 AM
File: rstse_v9_6_final_field_test.tap.bz2 6908 KB 10/30/2005 12:00:00 AM
File: rstsv7gen.tar.Z 5063 KB 10/30/2005 12:00:00 AM
File: rstsv9_source.zip 7980 KB 10/30/2005 12:00:00 AM
File: rstsv9_src.zip 7980 KB 10/30/2005 12:00:00 AM
And everything can be found at the location given above.
-----
Gregg C Levine gregg.drwho8 at gmail.com
"This signature was once found posting rude
messages in English in the Moscow subway."
Zane H. Healy wrote:
At 8:40 AM +0200 8/24/08, Johnny Billquist wrote:
Zane H. Healy wrote:
I assume 4.6 should have a separate tape for the DECnet install?
If you by that mean that DECnet isn't on the normal RSX distribution, then yes.
If, on the other hand, you guess that the DECnet distribution itself is multiple tapes, then no. It's only one tape in 4.6. It was only one tape in 4.5 as well. I can't remember if it was one or two tapes in 4.4 now.
I was simply asking if the DECnet distribution was separate from the RSX distribution. Which means I'm lacking DECnet.
Ok. I wasn't sure. In the past, the DECnet distribution was on two (or three) tapes. I don't think it have ever been on the same tapes as RSX itself. And in the past, the RSX distribution came on two tapes as well, You had the BRUSYS tape, and then the actual system. But that changed in the last few releases as well.
Johnny
At 8:40 AM +0200 8/24/08, Johnny Billquist wrote:
Zane H. Healy wrote:
I assume 4.6 should have a separate tape for the DECnet install?
If you by that mean that DECnet isn't on the normal RSX distribution, then yes.
If, on the other hand, you guess that the DECnet distribution itself is multiple tapes, then no. It's only one tape in 4.6. It was only one tape in 4.5 as well. I can't remember if it was one or two tapes in 4.4 now.
I was simply asking if the DECnet distribution was separate from the RSX distribution. Which means I'm lacking DECnet.
Zane
--
| Zane H. Healy | UNIX Systems Administrator |
| healyzh at aracnet.com (primary) | OpenVMS Enthusiast |
| MONK::HEALYZH (DECnet) | Classic Computer Collector |
+----------------------------------+----------------------------+
| Empire of the Petal Throne and Traveller Role Playing, |
| PDP-10 Emulation and Zane's Computer Museum. |
| http://www.aracnet.com/~healyzh/ |
Zane H. Healy wrote:
At 1:32 AM +0200 8/24/08, Johnny Billquist wrote:
Bob Armstrong wrote:
Sure it is. That's almost back to the '80s...
Wasn't 4.5 the last version released (by Mentec, too) ?
No. Mentec also released V4.6 back in 1998, or maybe it even got to january 1999. Can't remember for sure.
Johnny
I assume 4.6 should have a separate tape for the DECnet install?
If you by that mean that DECnet isn't on the normal RSX distribution, then yes.
If, on the other hand, you guess that the DECnet distribution itself is multiple tapes, then no. It's only one tape in 4.6. It was only one tape in 4.5 as well. I can't remember if it was one or two tapes in 4.4 now.
Johnny
At 1:32 AM +0200 8/24/08, Johnny Billquist wrote:
Bob Armstrong wrote:
Sure it is. That's almost back to the '80s...
Wasn't 4.5 the last version released (by Mentec, too) ?
No. Mentec also released V4.6 back in 1998, or maybe it even got to january 1999. Can't remember for sure.
Johnny
I assume 4.6 should have a separate tape for the DECnet install?
Zane
--
| Zane H. Healy | UNIX Systems Administrator |
| healyzh at aracnet.com (primary) | OpenVMS Enthusiast |
| MONK::HEALYZH (DECnet) | Classic Computer Collector |
+----------------------------------+----------------------------+
| Empire of the Petal Throne and Traveller Role Playing, |
| PDP-10 Emulation and Zane's Computer Museum. |
| http://www.aracnet.com/~healyzh/ |
Bob Armstrong wrote:
Sure it is. That's almost back to the '80s...
Wasn't 4.5 the last version released (by Mentec, too) ?
No. Mentec also released V4.6 back in 1998, or maybe it even got to january 1999. Can't remember for sure.
Johnny
Bob Armstrong skrev:
Hmm. You're running an "old" version of RSX are you? :-)
It's M+ v4.3. Not that old, AFAIK.
Sure it is. That's almost back to the '80s...
I think that the "generic" tape is the one that you should start with. You should only do the DECnet tape after you've done the generic tape.
If you're missing that tape, that's not good. You will never have a working DECnet installation in that case.
I might be able to help with M+ 4.3, but we might as well take that outside the list.
Johnny
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt at softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
