From: Johnny Billquist <bqt at softjar.se>
Date: Sat, 16 Jul 2016 01:09:24 +0200
>Interesting, as XXDP V2 have a format that appears to be pretty much the
>same as RT-11. (Including FLX being able to read it, more or less.)
Hmm. My experience (of reading XXDP V2 disks with my own code) disagrees.
And the RSX doc says that FLX supports DOS-11 disks/DECtapes (in addition
to DOS-11 magtapes which are *much* easier), which are very similar to
XXDP+ format (so maybe FLX has tweaks for the slight differences?).
John Wilson
D Bit
From: <Paul_Koning at Dell.com>
Date: Fri, 15 Jul 2016 18:17:11 +0000
>>I didn't even know that there was a DOS-11 disk format, but thinking about
>>it, it would seem obvious there should be one.
>
>Yes, there is, different from everything else as far as I know. I think
>the DECtape format is faintly related. Some DOS manuals may give some
>clues, but I've never looked into it or had any exposure to DOS disk file
>system internals.
Yes it's in the manuals, and the (commented) source code to PUTR.COM
has some explanation too. I believe the DECtape and disk formats are
the same, except that the MFD1 is located at block 1 on disks and
block 64. (^O100) on DECtapes.
The DOS/BATCH disk format is also used by XXDP before V2. XXDP V2 has
its own similar (but different) format.
John Wilson
D Bit
> Isn't the documentation wrong, since it says 2621?
... copy/paste/transcription error on my part. The file clearly
says 2021. Copied sort of by hand from a .pdf file...
> Either way, I believe this field was expanded to be interpreted as
> unsigned later than your code and documentation, meaning it will work a
> while longer. However, I doubt that the TOPS-10 code have been updated
> for that. Something for you to do?
As I said, the text indicates that the (monitor) code stops working in
2021, but the code does in fact allow one more bit, no change needed here.
The thing to wonder about is a piece of (ehum) software called NML.
Written in the wonderful language BLISS. (sarcasm)
> There is a similar issue with FAL, where the date field was also
> extended to be unsigned. RSX only got these updated in 1999 in the code.
> I'm sure VMS also have this. But for other OSes, I have no idea.
Time for some experimentation.
> Johnny
--Johnny
Okay,
Now it's static so long as I stop switching routers...;)
50.131.218.138 is now handled by a 7301.
--
Cory Smelosky
http://gewt.net Personal stuff
http://gimme-sympathy.org Projects
When browsing the Tops-10 sources I stumbled onto this (d36com.mac):
NMXTIM:
IFN FTOPS10,<
MOVE T1,DATE## ;GET CURRENT UDT (IN DAYS,,FRACTION)
MOVE T2,TIME## ;GET CURRENT TIME (IN JIFFIES SINCE MIDNIGHT)
LSH T1,-^D17 ;TRUNCATE TO NUMBER OF HALF DAYS.
SUBI T1,124210_1 ;CONVERT DAYS SINCE 1858 TO DAYS SINCE 1977
MOVE T3,[^D60*^D60*^D12]
IMUL T3,TICSEC## ;SECONDS SINCE HALF-DAY
TRNE T1,1 ;IS THIS THE SECOND HALF OF A DAY?
SUB T2,T3 ;YES, RECORD SECONDS SINCE HALF-DAY
IDIV T2,TICSEC## ;CONVERT JIFFIES INTO SECONDS.
IMULI T3,^D1000 ;CONVERT TO NUMBER OF MILLISECONDS*TICSEC
IDIV T3,TICSEC## ;CONVERT TO NUMBER OF MILLISECONDS.
SKIPL T2 ;MAKE SURE WE HAVE A POSITIVE NUMBER OF SECONDS
TDNE T1,[XWD -1,600000] ;MAKE SURE NO DATE OVERFLOW
BUG.(HLT,COM911,D36COM,SOFT,<The date is past 9 November 2021>,,<
Cause: The 2 byte julian half-day field in an event message is limited
to 9 november 2021. The routine above has calculated the julian
half-day, and has found that it overflowed.
I doubt very much that the date itself has really gone past 2021.
Probably someone smashed an AC or the routine to get the time
from the monitor is returning junk.
>)
RET
>;END IFN FTOPS10
This made me search for some documentation, and I found aa-k181a-tk
which said, amongst other things:
EVENT TIME Is the source node date and time of event
processing. Consists of:
+----------+--------+-------------+
! JULIAN ! SECOND ! MILLISECOND !
! HALF DAY ! ! !
+----------+--------+-------------+
where:
JULIAN HALF DAY (2) : B = Number of half days
since 1 Jan 1977 and
before 9 Nov 2621
(0-32767). For example,
the morning of Jan 1,
1977 is 0.
SECOND (2) : B = Second within current
half day (0-43199).
MILLISECOND (2) : B = Millisecond within
current second (0-999).
If not supported, high
order bit is set,
remainder are clear, and
field is not printed
when formatted for
output.
Some observations/questions:
* The code in Tops-10 actually checks for the half day value beeing
not more than 16 bits, i.e. it will not trigger until 2066. This
means that I will consinder it a typical case of SEP when it does.
* I have no idea what will happen when the date goes past 9-Nov-2021,
i.e. when the sixteen bit field gets the sign bit set and possibly
some software somewhere goes belly up. Maybe we should try to do a
controlled test?
* Will this be/become a problem? What to do about it?
--Johnny
Hi All,
After some effort, I got an PDP-11/93 (simh) online running RSX-11M+ 4.6
bl 87. It is reachable as ROJIN (1.542) and I've configured a guest
account on this box if anyone is interested in nosing around on this
sytem. Do note, I just have about 2 weeks of experience with rsx, so be
gentle with me :)
Kind Regards,
Lex van Roon
--
LRO-RIPE | 570DE0BE | 9BF5 922E AF87 8584 E9CA C3AD C508 39A9 570D E0BE
Hey guys,
I'm seeking some hardware technical expertise.
I have a DEC 3000-300L and have a CRT monitor (with RGB & SOG).
The monitor is over 13 years old and I'm not sure how much longer it will last.
A friend stumbled upon a Sun LSA 800 flat panel monitors at a resale shop.
Online search show the LSA 800 does Sync on Green, but not find details on resolution and freq.
Anyone know if the Sun LSA 800 support the resolution and freq of the Dec?
I'd like to swap out the CRT with the Sun LSA 800, but don't want to pay the shipping and then find out the Sun isn't compatible.
Thanks
Mike
Hi,
Can I get my IP updated to 50.131.150.11 please? This should be static-enough. ;)
GRE is being forwarded right through to a cisco 2620 I picked up at weirdstuff along with some weird stuff. ;)
Some people might have noticed that Mim.Update.UU.SE have not been
reachable the last week. This is because the University have decided to
put all systems behind firewalls, which hurt the Update computer club
pretty bad.
For people who would still like to get access to Mim, I have now setup
telnet to listen to a second port in addition to port 23. Mim is now
accessible by telnet on port 10023 as well, which is not blocked by an
firewall.
In addition, I also added ftp on port 10021 in addition to port 21, so
people who would like to get to files on Mim by ftp can do so again.
This also prompted me to make a couple of improvements to BQTCP/IP for
RSX. The changes are that the telnet daemon can now be set to listen to
an alternative port, and can also listen to several ports.
I also added the capability to the ftp client to specify which port to
connect to.
The TCP/IP package can be found at ftp://mim.update.uu.se:10021/
However, if you have the previous version of TCP/IP for RSX, you cannot
access this address, as the previous version ftp client did not accept a
port argument. So it's a bit of a chicken and egg thing. But using some
intermediate system, you can get the disk image to the machine, and
install the new version, after which things will be possible to use more
or less as before.
One more thing: NEMA, my very tiny EMACS clone for RSX, have gotten a
lot of work done lately, and if anyone is interested in this tool, I
really recommend that you fetch the latest version. A port to VMS is
also included with the files now, courtesy of Erik Olufsen.
NEMA is available at ftp://nema at mim.update.uu.se:10021/
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
All,
I am trying to bring my PDP-11/83 "Frodo" address 30.1 on to HECnet. I've been running Johnny's BQTCP and used FTP and TELNET to work from RSX11M+ to the rest of the internet. Now I want to connect to HECnet.
I've reNETGENed and added the IP multinet device, rebooted and run INS.CMD and it
all looks good. I do need to open the port in my router and direct it to the PDP-11 when I know the correct port #.
I'm in the HECnet node database but I need to connect the IP-0-0 network line in BQTCP to another HECnet node.
The PDP-11/83 DECnet name is Frodo and it is at DECnet 30.1
my static (as far as I know) IP address is 24.100.118.162 and it's DNS name is Matlock.DYNDNS-IP.COM
I would need to know:
the port # for the connection (700?)
the host name at the end of the connection and it's DECnet address?
also what cost you would like me to use for the circuit
Again I am VERY new to HECnet but have been around DECnet since 1981.
Thanks!
Mark Matlock
CHIMPY:: can be reached at telnet to hilant.sampsa.com port 2710.
This is for EU players.
I still need someone to host a US server as lag really is an issue.
Any volunteers? (I?ve got binaries for the AXP version but having some issues getting the VAX one to work)
This year's prize is THREE QATARI RIYALS plus of course a printed certificate of your amazing Tetris skills. The competition will run until October 1st, 2016.
As before, please if you get the current high score, please take a screenshot of it and email it to sampsa [at] mac.com.
sampsa
I've been working on rewriting parts of the VAX simulator(s) to avoid some of the undefined behaviors that the C language has relating to overflow and shifts of signed integer values.
Changing the details of how instructions are implemented comes with the non trivial potential to break more things than are being fixed. To manage this, I've been trying to use the basic CPU diagnostics that DEC for the systems being simulated. I have found the VAX Diagnostic Supervisor for the 11/730, 11/750 and 11/.780. I'm missing the VAX 8600's diagnostic supervisor.
If someone knows where I can find a version of this file it would be helpful.
Thanks.
- Mark
supratim at riseup.net writes:
>What monitoring tools are folks using here?
>
>I have so far found Ergosol's Watchdog - it provides a neat solution to
>high-level server security, status and connectivity monitoring with
>email alerts. I tweaked it a little for adjusting it to OpenVMS 7.3 -
>you can grab it from http://sanyal.duckdns.org:81/pub/rampage.sav
>
>I am getting (NUMEROUS!) emails from all intrusion attempts and whenever
>someone logs in to the monitored accounts, as well as when any of the
>monitored HECnet nodes or internet IPs are unreachable.
>...
As maintainer/author of Clyde-Digital's-(then)-> Raxco's-(then)-> ProvN's
Intruder Alert product, emails -- such as provided by your Watchdog -- will
soon overwhelm you and you'll soon either ignore them, or supress them, or
sequester them for review well after the fact.
--
VAXman- A Bored Certified VMS Kernel Mode Hacker VAXman(at)TMESIS(dot)ORG
I speak to machines with the voice of humanity.
Johnny Billquist <bqt at softjar.se> writes:
>On 2016-06-20 19:30, Brian Schenkenberger, VAXman- wrote:
>> Johnny Billquist <bqt at softjar.se> writes:
>>
>>> On 2016-06-20 18:19, Brian Schenkenberger, VAXman- wrote:
>>>> ___ _ _ _ __ __ _ _ _ _ ___ _____
>>>> / __| /_\ | \| | \ \ / / /_\ | | | \| | | __| |_ _|
>>>> \__ \ / _ \ | .` | \ V / / _ \ | |__ | .` | | _| | |
>>>> |___/ /_/_\_\_|_|\_| |_| /_/ \_\ |____| |_|\_| |___|_ |_|
>>>>
>>>> You've allowed this node on HECnet, so I assume somebody on this list knows
>>>> who runs it.
>>>
>>> Who runs it can always easily be found by http://mim.update.uu.se/nodedb
>>>
>>>> Please have it secured! It has been used in the past several
>>>> days to try and break into my system(s). It is highly irresponsible to put
>>>> access credentials into its SYS$ANNOUNCE allowing ANYBODY access to DCL and
>>>> other utilities that can affect systems on the internet. A reasonable way
>>>> to allow access would be to have a guest account (restricted/captive) that
>>>> can be used to create other login accounts. Validate such accounts with a
>>>> valid email address and other schemes that will insure that whomever is on
>>>> this system can be vetted in some fashion.
>>>>
>>>> THANK YOU!
>>>
>>> I'm curious about what kind of intrusions we're talking about, and over
>>> which network.
>>>
>>> In general, I want to keep HECnet more open than what you are suggesting
>>> above, but this also requires that people act responsibly. If there is
>>> abuse, I'd like to know.
>>
>> Well, since I have not yet put any of my systems on HECnet, it should have
>> been obvious that it's via the internet.
>
>Ah. Sorry for being dense. Thanks.
>
>So what kind of intrusion attempts are we talking about? Essentially
>your issue is that someone have a machine on the internet. Getting
>access on the machine is easy, and something/someone on that machine is
>trying to do something to your machine?
Well, for one, trying brute force attacks agains services. Here are some of
the FTP attempts from 108.31.82.9.
admin
support
guest
vizxv
123
1234
12345
123456
cisco
admin
service
1234
root
support
vizxv
123
12345
123456
xc3511
7ujMko0admin
root
root
support
123
12345
123456
xc3511
smcadmin
1234
xc3511
meinsm
vizxv
admin
admin
service
service
root
root
xc3511
12345
meinsm
dreambox
user
changeme
12345
pass
vizxv
user
changeme
root
I'm guessing that, due to the repeated nature of the usernames attempted, the
system has been logged into by a great many different twits.
--
VAXman- A Bored Certified VMS Kernel Mode Hacker VAXman(at)TMESIS(dot)ORG
I speak to machines with the voice of humanity.
Jordi Guillaumes i Pons <jg at jordi.guillaumes.name> writes:
>
>> El 20 juny 2016, a les 20:14, Brian Schenkenberger, VAXman- =
><system at TMESIS.COM> va escriure:
>>=20
>> 108.31.82.9.
>
>Uh, I=E2=80=99d bet the simulated 3900 is not the real origin of the =
>attack you are getting. It is probably behind a home DSL/cable router, =
>whith port 23 redirected to the 3900=E2=80=99, which has probably a =
>private IP address masqueraded using NAT=E2=80=A6 So probably the node =
>owner has been hacked and zombified, regadrless of he having a pet 3900 =
>open to the net.
That may very well be true too. I have found many attack vectors over the years that
have originated from home routers. Several home routers have known/identified/easily
exploitable weaknesses. Regardless, I will check to see if this IP address continues
to aggrieve me now that it's been reported that FTP is no longer possible from the VMS
instance.
--
VAXman- A Bored Certified VMS Kernel Mode Hacker VAXman(at)TMESIS(dot)ORG
I speak to machines with the voice of humanity.
Hello,
Does anyone have that thing? The ALPHA one is in vaxhaven (where there is also a HALF of a TK50 kit), but I?ve not been able to find the VAX one.
Thanks in advance.
Johnny Billquist <bqt at softjar.se> writes:
>On 2016-06-20 18:19, Brian Schenkenberger, VAXman- wrote:
>> ___ _ _ _ __ __ _ _ _ _ ___ _____
>> / __| /_\ | \| | \ \ / / /_\ | | | \| | | __| |_ _|
>> \__ \ / _ \ | .` | \ V / / _ \ | |__ | .` | | _| | |
>> |___/ /_/_\_\_|_|\_| |_| /_/ \_\ |____| |_|\_| |___|_ |_|
>>
>> You've allowed this node on HECnet, so I assume somebody on this list knows
>> who runs it.
>
>Who runs it can always easily be found by http://mim.update.uu.se/nodedb
>
>> Please have it secured! It has been used in the past several
>> days to try and break into my system(s). It is highly irresponsible to put
>> access credentials into its SYS$ANNOUNCE allowing ANYBODY access to DCL and
>> other utilities that can affect systems on the internet. A reasonable way
>> to allow access would be to have a guest account (restricted/captive) that
>> can be used to create other login accounts. Validate such accounts with a
>> valid email address and other schemes that will insure that whomever is on
>> this system can be vetted in some fashion.
>>
>> THANK YOU!
>
>I'm curious about what kind of intrusions we're talking about, and over
>which network.
>
>In general, I want to keep HECnet more open than what you are suggesting
>above, but this also requires that people act responsibly. If there is
>abuse, I'd like to know.
Well, since I have not yet put any of my systems on HECnet, it should have
been obvious that it's via the internet.
--
VAXman- A Bored Certified VMS Kernel Mode Hacker VAXman(at)TMESIS(dot)ORG
I speak to machines with the voice of humanity.
___ _ _ _ __ __ _ _ _ _ ___ _____
/ __| /_\ | \| | \ \ / / /_\ | | | \| | | __| |_ _|
\__ \ / _ \ | .` | \ V / / _ \ | |__ | .` | | _| | |
|___/ /_/_\_\_|_|\_| |_| /_/ \_\ |____| |_|\_| |___|_ |_|
You've allowed this node on HECnet, so I assume somebody on this list knows
who runs it. Please have it secured! It has been used in the past several
days to try and break into my system(s). It is highly irresponsible to put
access credentials into its SYS$ANNOUNCE allowing ANYBODY access to DCL and
other utilities that can affect systems on the internet. A reasonable way
to allow access would be to have a guest account (restricted/captive) that
can be used to create other login accounts. Validate such accounts with a
valid email address and other schemes that will insure that whomever is on
this system can be vetted in some fashion.
THANK YOU!
--
VAXman- A Bored Certified VMS Kernel Mode Hacker VAXman(at)TMESIS(dot)ORG
I speak to machines with the voice of humanity.
Hello,
I'm looking for Vaxima, if someone has preserved a copy of it, it is
best described as such (if you don't know Vaxima):
MACSYMA (Project MAC's SYmbolic MAnipulation System) is a large
computer algebra system for symbolic and numerical computations.
Originally MACSYMA was developed by the MATH lab group at M.I.T. The
descendants of MACSYMA (circa 1982) fall into two camps, viz., the
commercialized Symbolics MACSYMA and its successor from Macsyma, Inc.,
and the versions released to National Energy Software Center at
Argonne, Illinois, which are based on the "public" MIT source code for
the DEC PDP-10 MACLisp system. The latter ones do not have the
Symbolics enhancements, but they have been modified from time to time
by several individuals or groups. One of these modifications is known
as VAXIMA. It is an implementation around 1980 on DEC-Vaxes by R.
Fateman at the University of California at Berkeley. It uses VAX/UNIX
Franz Lisp and runs on some Franz-Lisp hosts.
Thanks,
Jerome
Hi all,
My name is Lex van Roon, and for quite some time I've been lurking on
this list as a DEC/VMS enthusiast and today I got my link to HECnet
working with the help of Johnny.
Somewhere during the 90s, a high-school classmate of mine gave me a couple of
copies of Hacktic(*). In there I read about these operating systems with
weird names like VMS and UNIX, and since I only knew MS based OS's back
then, I was intrigued. I soon got my first Linux box running under x86,
and not long thereafter I got my first whitelabel Alpha mainboard, on
which I happily ran BSD and Linux. After dropping out of school, I went
to work as a sysadmin in the UNIX world during the end of the dotcom boom,
and nowadays I'm a DevOps engineer working for a large dutch .com.
As a hobby, I've been running various Alpha's (and other RISC iron) over
the years:
- Whitelabel AXPCI133
- AS1000 (lots of them)
- PWS 466au
- DS10/DS20/DS25
- ES47
and since a couple of years, I finally wiped UNIX off my Alpha's and
installed VMS, and have used them for various things. Mostly replicating
services I'd normally run under UNIX (dns, ntp, http), but also for
software development in C and Python(**). In this time, I've discovered
that it's very helpful to know people who know VMS very well (thnx
Steven Hoffman), and I am confident enough about my VMS skills
that I decided to join, since being in a DECnet with my own systems is
not such an interesting learning experience as working with 'the real
thing' :)
For now I'm online with the following two Alpha's:
REI / 1.540 / AlphaServer DS10 / 466MHz / 1GB ram / 2 x 18GB u2w 10k
PAI / 1.541 / AlphaServer DS25E / 1GHz / 1GB ram / 6 x 73GB u320 15k
In the future, I plan/hope to get my VAX 4000/200 connected, but that
system still needs some TLC before it will operate. Most likely I will
also spin up some emulated instances of various other DEC operating
systems in the future, for learning/discovery purposes.
The systems are connected to a 100mbit FttH uplink, located in Amersfoort,
The Netherlands and are available 24/7. I have not yet configured any guest
accounts, but I intend to do this.
Kind Regards,
Lex van Roon
*) https://en.wikipedia.org/wiki/Hack-Tic
**) https://github.com/r3boot/pki
--
LRO-RIPE | 570DE0BE | 9BF5 922E AF87 8584 E9CA C3AD C508 39A9 570D E0BE
Not sure if anyone really cares, but I figure it don't hurt to tell
anyway...
I have for many years used a very old version of MicroEMACS for RSX. I
eventually started searching around for alternatives, but realized
during that search that most Emacs clones are horribly huge (including
MicroEMACS), not portable at all (even if they claim to be), and
generally also expects to just allocate gobs of memory to keep all data
in ram.
Now, RSX, being a PDP-11 OS, have a 16-bit address space limitation. So
just allocating memory is never going to be a solution. There is a C
compiler, which is pretty much ANSI C. But it is not Unix, and gives you
the C standard IO library, but not low level Unix calls.
On the plus side, most of the library can sit in supervisor space, and
not consume any memory in your process space.
Clones I've looked at:
MicroEMACS - Huge and difficult to port. Use lots of memory.
JOVE - Small (runs on 2.11BSD), but horribly difficult to port.
mg - Huge and difficult. Use lots of memory.
AMIS - Huge, and written in Pascal. Not necessarily bad, but adapting
the code to a new system requires mucking around some, made worse by the
small differences in different Pascal compilers, and the lack of any
preprocessor, as well as the bonehead type system in Pascal. Also use
lots of memory, but it has been made to run on small machines (including
PDP-11 with RSTS/E) in the past, so it is a solveable problem.
Atto - Hard to port.
JED - Huge.
I looked at dozens more, which were not even worth looking deeper into,
or to list here.
The long and short of it was that, even though there are numerous
implementations out there, they all suck, from my point of view.
With all that in mind, I decided to write my own Emacs clone instead
(yes, I got horribly upset with the lousy quality of most code I looked
at, if someone wants to hear some rants, contact me privately).
I started about a month ago, and at this point, it's working, and quite
useful. And I guess if other people are in a similar situation, they
might be interested in looking into this, and possibly make use of it.
Quick run through:
. ANSI C sources.
. Mostly uses the C standard IO library. Exception is terminal I/O,
which requires some small pieces reimplemented if you want to port it.
So, if you have an ANSI C compiler, porting should be very low effort.
. Only works on ANSI terminals today. It would be doable to extend with
other terminal support, but I don't have any need, and since I do not
have, nor want to depend on curses, it will require coding to either
have a module to uses curses, if that is wanted, or handling of specific
terminals.
. The compiled code, using PDP-11 C, ends (at the moment) up at around
36 Kbytes of binary. The C library and RMS sits mostly in supervisor
mode, and is not accounted for in this.
. Data usage is about 8K for various storage and strings.
. Code dependecies are very much in a tree, so overlaying is easy, if
wanted/needed, and that capability exists on the host.
. Since I compile with split I/D space, this means than about 56K of
dataspace can be used for buffering of various sorts.
. File buffers are kept in a temporary file, and read/written to memory
as needed (pretty much a demand-paging virtual memory implementation in
the application).
. The virtual, paged memory is about 4G, which is an absolute limit on
memory usage. Practical file limit is (I would guesstimate) around 1G.
. Most basic EMACS editing functions are implemented, including split
windows, multiple buffers, kill buffer, moving around in various ways,
and some semi-stupid automatic indentation handling for C code. Also
incremental searching in a proper fashion.
. Speed, tested on a real PDP-11/93 is pretty acceptable. Testing on a
file about 1000 lines takes a couple of second to open, and a couple of
seconds if you try to search from the start to the end. Most other
things move faster.
. The program is not suitable for editing binary data. The C standard
I/O library don't really lend itself to binary I/O, and this code have
to live within those constraints.
There are still lots of functionality that I'm working on adding, such
as repeats (almost done) and macros (only started thinking about it).
If people have functions they consider extra important, let me know, and
I'll see if I can add them. If people want to contribute code, I'll be
happy to incorporate changes as well, as long as they make sense.
The sources, as well as a compiled RSX-11M-PLUS binary for PDP-11 C
V1.2, can be found at HECnet: MIM::DU:[NEMA], or
ftp:://nema at mim.update.uu.se/.
This editor is now installed as ...EMA on MIM::, so if you type "EMA
filename", you can see how it works there.
It is now my tool for doing further development. I have ditched
MicroEMACS. So I'm constantly testing the thing, as I am developing
it... :-)
Maybe someone will find it 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
Hi,
I wonder if someone has been succesful repairing the corrupted tpc images of several PDP-11 layered products that are (not)available in some sites (bitsavers and trailing-edge come to memory). IIRC there was a kind of effort to fix whatever could be fixed (the BRU format ones, specifically) reordering the mangled tape blocks in the image.
More specifically, I?m looking for an usable COBOL-81 compiler. The one which is not corrupted (cobol_v4_4) is COBOL/C11, not COBOL 81, and even for hobbyist stuff, handling COBOL-74 is a PITA?
Best regards to all.
Jordi Guillaumes
Hello,
I've got an RSX-11M+ VM up (real hardware whenever I get my boards
shipped...) and I've got a question:
Is the FMS-11 tape on trailing-edge ftp corrupted? Can it be used to
pe4rform an install?
--
Cory Smelosky
http://gewt.net Personal stuff
http://gimme-sympathy.org Projects
I've put up two new systems:
MARDUK at 61.151 is a simh emulated pdp11/93 running RSTS/E v9.6 with DECnet.
ENKIDU at 61.152 is a simh emulated VAX running OpenVMS 7.3 with DECnet and IP.
This is in addition to GLGMSH (Gilgamesh) at 61.150, the KLH10 TOPS-20
system I've been running for many years.
All are located in San Jose, CA. Johnny, if you could add my two new
systems to the nodedb, I would appreciate it. And to Dave M., these
will be pretty low volume net usage, so impact on your link should be
minimal to unnoticeable.
Should anyone want an account, feel free to contact me. More users = more fun!
Thanks!
-Mark
Time for a new release announcement of TCP/IP for RSX-11M-PLUS.
A couple of fixes have been done since the last release.
At this point, the TCP/IP and tools seem to be very stable and usable.
MIM, which is my main test machine have been up and running for a month.
During that time, the machine have send out around 8G of data over TCP,
had about 28500 connections established, blocked about 17000 packets
from about 1000 spammers, had about 700 logins over telnet, and
basically been very busy, while not falling over or failing.
These are quite fun numbers, and I do feel a bit proud about them as
well. I don't think DEC ever envisioned an RSX system doing that.
I should also point out that I have not had a crash because of TCP/IP in
a very long time. But since I have often been doing various tests and
changes, uptime have often not been that long anyway. But right now I
feel that I do not have any pressing needs for things to fix in the
network stack, and have start to focus more on applications.
Things that have been done since the last release:
TCP:
- Made some transmit and receive statistics 64 bit wide. Numbers started
wrapping...
- Added smarter ACK probing for packets received out of sequence, which
improves transmission rates and lost connection detection.
- Added ability to set keepalive time on a per connection basis.
Telnet:
- Added spoof detection for telnet connections.
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
Note! I've realized that BQTCP/IP do not work right if you have a
PDP-11/74 with multiple processors online. I'll fix that at some point,
as it's probably just a case of affinity not being set on devices, nor
relevant processes. This might only be a problem with telnet in fact. I
know for sure that the IP and TCP drivers works ok in multiprocessor
systems.
The one thing I might do some additional work on in the near future
is improving the DNS resolver. It should not affect any existing code,
but is something needed before I can do SMTP.
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
