Hello all,
If Altavista was developed by the folks at WRL, SRC and NSL and the source code was released into public domain at some point, there would be a tape dump or something somewhere, wouldn?t it? Any known places too look at?
Regards,
Supratim
---
Supratim Sanyal, W1XMT
39.19151 N, 77.23432 W
QCOCAL::SANYAL via HECnet
Hi,
Apologies for some of the intermittent connection problems to/from area29. I was being hit with a very small part of some DDOS reflection traffic targeted at some cloud providers. This wasn't causing the actual issues however. In making a series of incremental, and in some cases automated changes to firewall rules and threshold settings, it would appear that the router needs a reboot following any major changes. Apparently, there's a bit of garbage created when rules are moved around, changed and deleted which degrades throughput until a reboot is performed. I suppose you could call it a bug in their software.
Just FYI
Keith
Hello All,
I recently acquired/rescued a rack of Alphaserver gear that was going to get scrapped. In the rack is two ES45 servers (with no local drive cages), and a 3-shelf HSG80 Fibre Channel disk system. There were no drives, but I have plenty of this form factor and so I?ve fully populated all three shelves.
The original system apparently ran Tru64 Unix, but I don?t have much interest in that. I?d love to get the two machines running in an OpenVMS cluster.
I?ve managed to figure out the HSG80 array, and I am serving up acouple of FC LUNs. I can verify this because I?ve got wwidmgr on the Alpha?s to see and create a drive (dgb2).
However, when I attempt to boot OpenVMS Alpha 8.4 from CD-ROM, the install process doesn?t recognize the FC drive and offer it as an installation target.
Is anyone familiar with this generation of gear and possibly give me a pointer or two about what I might be doing wrong?
Perhaps I need a newer OpenVMS install? Is there ISO images of various versions lurking around hecNET that anyone is willing to share?
Thanks for any suggestions!
Ian
Time for a new release announcement of TCP/IP for RSX-11M-PLUS.
Highlights:
. TCP have had some potential fatal bugs fixed, and some significant
performance improvements.
. FTP have received significant performance improvements.
. Various tools and drivers have had improvements in order to support
more than one ethernet interface.
*** For these reasons, it is strongly recommended that systems be
upgraded to the latest version at your earliest convenience.
Detailed information on things that have been done since the last release:
IPGEN:
. Corrected IPGEN to be able to generate configurations with multiple
Ethernet interfaces.
. Bugfix for no purge options, which did not work.
IF:
. Bugfix in interface driver. IO.RIF did not return proper status.
UDP:
. Added ability in UDP to bind socket to specific interface.
TCP:
. Improved TCP retransmission strategy.
. Rewrote TCP ACK generation and window update handling.
. Bugfix. A TCP connection in the process of closing down would just
absorb incoming SYN packets to the connection. They should be responded
to with a RST.
. Bugfix in some longword processing that could potentially cause wrong
effects under rare circumstances.
. Bugfix in TCP. I/O writes of more than 8K was accepted, but actual
data was not transferred correctly.
. Bugfix in TCP. I/O reads of more than 8K was accepted, but should not.
This could crash the system.
DHCP:
. Corrected DHCP to detect if interface do not start.
. Rewritten DHCP to handle interfaces properly also if there are
multiple interfaces using DHCP.
. Rewritten DHCP to better handle options and to try explicit renews
instead of always starting over with request when time is up.
IFCONFIG:
. Add indication in IFCONFIG SHOW IF to indicate if interface is
running, also for DHCP controlled interfaces.
TELNETD:
. Added additional space in telnet UCB, and telnetd now stores remote
address in UCB. (Separate changes to RSX can enable reading this out via
QIO to TT:)
SPOOF:
. Added notifying the SPOOF handler for some more TCP situations.
. Bugfix in SPOOF. Under some circumstances, it could loose track of
hosts it was blocking, and never unblock them.
. Changed spoofer to be capable of blocking different network block sizes.
FTP/FTPD:
. Improved file handling in FTP for RSX and block mode. Performance is
now close to 2x as fast as before in some situations.
Multinet:
. Improved handling of connections in Multinet.
. Added ability to change mode of Multinet links to either be VMS
compatible, or pure DDCMP style.
. Bugfix in MLTNET. There was an odd address error in one place.
. Improved MLTNET handling and recovery from some communication errors.
. Updated IPNCONFIG.CMD to new version from Oleg Safiullin.
MAILD:
. Corrected block lock handling in MAILD, which could sometimes keep
blocks locked for long times for no good reason.
. Mailbox format slightly changed. MBXUPD needed for upgrade.
XLISP:
. Added port as a parameter to connect function in XLISP.
Datatrieve-11:
. Added proper interface to Datetrieve-11 from PDP-11 C.
MCR:
. Bugfix. DEV /FILES could crash RSX.
*** Important notice about MAILD ***
The changes to MAILD are not seamless. When installing the new version,
the mailbox update program should be run, in order to upgrade all user
mailboxes to the new mailbox format. The task for this is MBXUPD.TSK.
There are no issues with running this task several times. A mailbox that
has already been updates will not be modified anymore by the update task.
As usual, the distribution is available from:
ftp://mim.update.uu.se/bqtcp.dsk
ftp://mim.update.uu.se/bqtcp.tap
ftp://ftp.update.uu.se/pub/pdp11/rsx/tcpip/tcpip.dsk
The documentation is also available through ftp on Mim, or also at
http://mim.update.uu.se/tcpipdoc
I hope people find this update useful.
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
In the Phase IV network management spec the description of the encoding of the event log message has this field:
JULIAN HALF DAY (2) : B Number of half days
since 1 Jan 1977 and
before 9 Nov 2021
(0-32767). For
example, the morning
of Jan 1, 1977 is 0.
It's a 16 bit field containing a 15 bit value; there is no explanation why the upper bit is not used even though it's marked as an unsigned integer.
As shown, the field overflows in late 2021. If one ignores the arbitrary limit of 15 bits, the end date is 18 September 2066, which is more civilized.
I wonder if implementations ignore the 15 bit limit. I think RSTS/E ignores it.
paul
I'm searching for an RQDX2 controller. I know this is maybe a bit off
from normal HECnet discussions, but I'm hoping that maybe some people
might happen to have some real hardware.
I have a few RD53 drives I'd like to read out the contents of, and it
seems they were controlled by an RQDX1 or RQDX2. I have an RQDX3
controller, however, the on disk format differs between the RQDX1/2 and
the RQDX3, so I don't have any ability to read the drives right now.
Since I am in Switzerland (near Zurich) someone local would be much
easier, but if someone somewhere else have a card, is willing to ship
it, and don't expect a bunch of money in return, I'm interested in that
too. If nothing pops up, and can solve this myself at Christmas, when I
go back to Sweden, where I have access to more hardware. But being an
impatient guy, I'm trying this option as well... :-)
Also, an RQDX1 should also work, but if possible, I prefer the RQDX2,
since the RQDX1 have some additional issues...
And of course, if I manage to get the data out from the drives, there
might be some useful things on there that I can share in the end (I'm
specifically searching for a few files needed to complete a Modula-2
compiler that exists for RSX).
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
People, I have written a page about DECnet costs and HECnet costs, which
I would recommend that anyone interested read through. It contains a bit
of elaboration on how DECnet does routing, and gives some suggestions on
how costs could be set on HECnet to make it perform better.
I have noticed over the years that sometimes we do get really silly
routing decisions just because of how people set, or do not set costs.
The page I've written is by no means perfect, nor are the suggestions in
there. But feel free to come with feedback, or ignore it. But I am going
to try and use this myself more properly from now on, and that means
that if others don't, you probably are going to get more traffic through
your nodes. Traffic that probably do not make sense that it passes
through you, but I just feel that I prefer to try and make it work right
from my point of view, and then just at least tell people how I worked
my numbers out. If someone have a different idea, I'm open to changing
my settings, but I will not try and do optimizations to achieve:
a) Same paths for packets in both directions - DECnet explicitly does
not do this.
b) Specifically penalize one type of interface because of any subjective
preference about that type of interface in general.
Oh - and the link to my writeup: http://mim.update.uu.se/costs.htm
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
I've worked on RSTS and DECnet/E for a long time but I only very rarely do a formal install, so I don't have the knowledge handy.
I just did a V10.1 install, and now would like to do the matching DECnet install, but I can't figure out how to do that and I can't find a DECnet/E installation manual.
Can anyone give a quick outline of how to do this?
paul
