Johnny,
Thanks for the update. I've been installing some of the various updates that you have put out since the early version, and have seen the number of the improvements you have made. It is so nice to have the ability to move files with ftp from linux or the internet directly into files-11 !! Even whole .dsk files from bitsavers which can be loaded as virtual disks in RSX.
I have been using it both on a real PDP-11/83 and with Simh on Mac, Ubuntu and Raspberry PI2. Also, thanks for distributing the precompiled versions of the utilities as this helps when BP2 and PDP-11 C are not readily available.
I hope to have some time to read the sources and learn much more about TCP/IP. I've already found the NTPDATE.C program quite interesting.
Thanks again for your efforts to keep RSX alive for those of us who have such affection for it.
Best Regards,
Mark Matlock
On Mar 17, 2015, at 10:38 AM, Johnny Billquist wrote:
It's been close to two months since the last announcement. I have been busy with improving thing since then, and I guess it's time to announce a new version, for people who might be interested.
Improvements since last announcements:
. FTP client and server have had extensive bugfixing, performance improvements and feature enhancements.
. NETSTAT has been rewritten to be more useful and friendly.
. Bugfix in INETD. It never checked the result from the ACCEPT.
. TCP have had several bugfixes and improvements:
. At tcp close, retransmit didn't happen if only FIN was left unacknowledged.
. If both sides sent FIN at the same time, the socket could get out of sync.
. Improved performance at FIN time by allowing ACK to be delayed.
. Accept legal packets after the FIN.
. Cleanup of how offspring task sockets are handled.
. Added the ability to transmit TCP URGENT data.
. Redesigned the TCP receive window handling for improved performance.
. TCP PUSH could transmit more data with push flag that it should.
. Added handling of ICMP error packets to TCP.
. Installation procedure have been updated with the ability to not install some command files. The helps with updates of existing installation.
. Documentation have been updated (although it still miss a lot of pieces.)
I encourage everyone who have installed BQTP/IP on an RSX system to update to the latest version, as some of these fixes can make a big difference.
As usual, the distribution is available from:
ftp://madame.update.uu.se/bqtcp.dsk
ftp://madame.update.uu.se/bqtcp.tap
ftp://ftp.update.uu.se/pub/pdp11/rsx/tcpip/tcpip.dsk
The documentation is also available through ftp on Madame, or also at http://madame.update.uu.se/tcpipdoc
Johnny
On 2015-01-22 17:47, Johnny Billquist wrote:
I just thought I'd make yet an announcement.
(Maybe I should find a better forum for this?)
The last week I've been busy with FTP improvements and performance, and
I've managed to improve this a lot.
Enough that it is worth sending information out that people should
upgrade if they have installed this.
The FTP client and server have improved performance and some additional
features. Along with this I also changed the protocol format for RSX
special mode transfers. This is not backwards compatible, and due to an
initial design miss, the old ftp client/server will not reliably detect
this incompatibility, resulting in broken files if RSX mode is used
between the old and new version. This will not be a problem going
forward. If you run FTP from RSX to fetch the new package, use BLOCK
mode instead of RSX mode, and fetch the disk image and not the tape
image, and you'll be fine. Once upgraded, RSX mode is definitely the
recommended mode for the future. For all kind of files.
TCP itself increased the receive buffer size, which also improves
performance for everything that would be interested in higher throughput.
I've also gone over the distribution and installation scripts and fixed
a few minor details.
As usual, the distribution is available from:
ftp://madame.update.uu.se/bqtcp.dsk
ftp://madame.update.uu.se/bqtcp.tap
ftp://ftp.update.uu.se/pub/pdp11/rsx/tcpip/tcpip.dsk
The documentation is also available through ftp on Madame, or also at
http://madame.update.uu.se/tcpipdoc
Johnny
All in all,
On 2015-01-16 04:47, Johnny Billquist wrote:
There have been lots of positive comments, and obviously some people
have even tested using the software.
Of course, a bug was also found. A really weird corner case with
severely loading the network stack and having a socket in listen state
programatically could trigger a corruption of kernel memory.
So I've cut a new release with the bug fixed.
While I'm at it I also realize that I forgot to mention that included in
the distribution is also a simple IRC client as well as a simple IRC
robot.
I've also taken a little time to slightly improve the documentation, and
the documentation is now also available directly by ftp from
Madame.Update.UU.SE, so you do not need to get the whole distribution
and unpack it to just read something.
So - same as before. Disk image and tape image are available at
Madame.Update.UU.SE. Use anonymous ftp.
Disk image is also available at
ftp://ftp.update.uu.se/pub/pdp11/rsx/tcpip.
The disk image is a virtual RL02 disk. Can be used with any emulator, or
also directly inside RSX if you have virtual devices available.
Happy hacking.
Johnny
On 2015-01-14 00:40, Johnny Billquist wrote:
Well, it's been a long time project, but I'm happy to finally announce a
more public initial release of TCP/IP for RSX-11M-PLUS.
This is the result of over 20 years of development. Needless to say,
I've been doing a lot of things over the years, and this code have been
through four reimplementations over the years.
What I now release is something that I believe is a nice and useful
piece of software. I am aware of the fact that most people do not use
these machines any longer, but if someone actually wants to talk to me
about support for this or other RSX software, let me know.
Also, feel free to spread this information to anyone who might be
interested, anywhere.
So - what is in this release?
It is a complete implementation of ARP, IP, UDP, and TCP for
RSX-11M-PLUS. It has been tested on RSX-11M-PLUS V4.6, but should work
on any V4 release. There might be some small tweaks or fixes required,
but nothing major.
It do require a system with split I/D-space, or else at least the TCP
part will not fit.
For Unibus machines, it should be possible to run without any additional
software except what is in a base RSX distribution.
For Q-bus machines, DECnet is required for ethernet networking.
The TCP/IP stack can co-exist with DECnet.
Some utilities also utilize RMS for file access.
A bunch of tools, utilities and libraries are also included. These
include:
. IFCONFIG network configuration tool.
. NETSTAT network information tool.
. PING
. TRACEROUTE
. DNS client
. FTP daemon
. FTP client
. HTTP server
. TELNET client (rudimentary)
. TFTP client
. TFTP server
. INET server that can do SINK, ECHO, DAYTIME, QUOTE, and IDENT
. NTP client
. LPR client that sits in the queue manager (rudimentary)
. FORTRAN-77 library
. BASIC+2 library
. PDP-11 C library
The implementation fulfills most of the requirements put forth in RFC
1122. There are a few limitations because of restrictions in the PDP-11,
but none of them should really cause any problems.
Documentation is still on the thin side, but example configs are also
provided, along with installation scripts.
A bunch of test programs and example programs are also included, as well
as the sources of all tools and libraries.
The TCP/IP stack itself only comes in binary form.
All tools are also included precompiled in the distribution, so an
installation only have to build the stack itself for your system, and
then you should be ready to go.
The API only have a slight resemblance to the Unix sockets API. However,
if someone sits down to write code to use TCP/IP under RSX, I'm sure
they will discover that it is extremely easy to use the libraries, or
the basic functions.
The TCP/IP implementation is mostly written as device drivers. This also
have some other interesting implications, such as it is possible to
access TCP as a normal file. You can, for instance do something similar
to the Unix netcat command by issuing the MCR command:
PIP TI:=TC:"foo.com";4711
which would open a connection to foo.com, on port 4711, and any data
sent from that machine will be shown on the terminal.
The resources used by TCP/IP are modest. A memory area (size selectable
at generation/startup) is used internally. The amount of memory in the
private pool limits the amount of data that can be buffered. Normal pool
is used in a small quantity for each TCP port that is open.
People are welcome to play around with this, and make improvements.
Contributions of code is most welcome.
There are still lots of things to do. The programs marked as rudimentary
should be rewritten.
The most obvious thing still missing is a telnet daemon, which probably
is my next step.
However, the reason for now announcing the release is that it can
finally be distributed natively from an RSX host.
The main locations to download the TCP/IP for RSX are:
Madame.Update.UU.SE (anonymous ftp).
This is one of my development systems for this software. It runs under
E11, and if things are down, I blame E11. :-)
When connected, you are already in the right directory. There is both an
RL02 disk image there, which can be downloaded by anyone. If you happen
to have an RSX system which you are conneting from, you can also try
getting the BQTCP.TAP tape image. Such an image will not transport
cleanly to a non-RSX system, however. Sorry.
ftp.Update.UU.SE (anonymous ftp) - /pub/pdp11/rsx/tcpip
The disk image is normally duplicated to ftp.update.uu.se as well, so
the same file can be found there.
I hope some people will find this useful/amusing. :-)
Johnny Billquist
It's been close to two months since the last announcement. I have been busy with improving thing since then, and I guess it's time to announce a new version, for people who might be interested.
Improvements since last announcements:
. FTP client and server have had extensive bugfixing, performance improvements and feature enhancements.
. NETSTAT has been rewritten to be more useful and friendly.
. Bugfix in INETD. It never checked the result from the ACCEPT.
. TCP have had several bugfixes and improvements:
. At tcp close, retransmit didn't happen if only FIN was left unacknowledged.
. If both sides sent FIN at the same time, the socket could get out of sync.
. Improved performance at FIN time by allowing ACK to be delayed.
. Accept legal packets after the FIN.
. Cleanup of how offspring task sockets are handled.
. Added the ability to transmit TCP URGENT data.
. Redesigned the TCP receive window handling for improved performance.
. TCP PUSH could transmit more data with push flag that it should.
. Added handling of ICMP error packets to TCP.
. Installation procedure have been updated with the ability to not install some command files. The helps with updates of existing installation.
. Documentation have been updated (although it still miss a lot of pieces.)
I encourage everyone who have installed BQTP/IP on an RSX system to update to the latest version, as some of these fixes can make a big difference.
As usual, the distribution is available from:
ftp://madame.update.uu.se/bqtcp.dsk
ftp://madame.update.uu.se/bqtcp.tap
ftp://ftp.update.uu.se/pub/pdp11/rsx/tcpip/tcpip.dsk
The documentation is also available through ftp on Madame, or also at http://madame.update.uu.se/tcpipdoc
Johnny
On 2015-01-22 17:47, Johnny Billquist wrote:
I just thought I'd make yet an announcement.
(Maybe I should find a better forum for this?)
The last week I've been busy with FTP improvements and performance, and
I've managed to improve this a lot.
Enough that it is worth sending information out that people should
upgrade if they have installed this.
The FTP client and server have improved performance and some additional
features. Along with this I also changed the protocol format for RSX
special mode transfers. This is not backwards compatible, and due to an
initial design miss, the old ftp client/server will not reliably detect
this incompatibility, resulting in broken files if RSX mode is used
between the old and new version. This will not be a problem going
forward. If you run FTP from RSX to fetch the new package, use BLOCK
mode instead of RSX mode, and fetch the disk image and not the tape
image, and you'll be fine. Once upgraded, RSX mode is definitely the
recommended mode for the future. For all kind of files.
TCP itself increased the receive buffer size, which also improves
performance for everything that would be interested in higher throughput.
I've also gone over the distribution and installation scripts and fixed
a few minor details.
As usual, the distribution is available from:
ftp://madame.update.uu.se/bqtcp.dsk
ftp://madame.update.uu.se/bqtcp.tap
ftp://ftp.update.uu.se/pub/pdp11/rsx/tcpip/tcpip.dsk
The documentation is also available through ftp on Madame, or also at
http://madame.update.uu.se/tcpipdoc
Johnny
All in all,
On 2015-01-16 04:47, Johnny Billquist wrote:
There have been lots of positive comments, and obviously some people
have even tested using the software.
Of course, a bug was also found. A really weird corner case with
severely loading the network stack and having a socket in listen state
programatically could trigger a corruption of kernel memory.
So I've cut a new release with the bug fixed.
While I'm at it I also realize that I forgot to mention that included in
the distribution is also a simple IRC client as well as a simple IRC
robot.
I've also taken a little time to slightly improve the documentation, and
the documentation is now also available directly by ftp from
Madame.Update.UU.SE, so you do not need to get the whole distribution
and unpack it to just read something.
So - same as before. Disk image and tape image are available at
Madame.Update.UU.SE. Use anonymous ftp.
Disk image is also available at
ftp://ftp.update.uu.se/pub/pdp11/rsx/tcpip.
The disk image is a virtual RL02 disk. Can be used with any emulator, or
also directly inside RSX if you have virtual devices available.
Happy hacking.
Johnny
On 2015-01-14 00:40, Johnny Billquist wrote:
Well, it's been a long time project, but I'm happy to finally announce a
more public initial release of TCP/IP for RSX-11M-PLUS.
This is the result of over 20 years of development. Needless to say,
I've been doing a lot of things over the years, and this code have been
through four reimplementations over the years.
What I now release is something that I believe is a nice and useful
piece of software. I am aware of the fact that most people do not use
these machines any longer, but if someone actually wants to talk to me
about support for this or other RSX software, let me know.
Also, feel free to spread this information to anyone who might be
interested, anywhere.
So - what is in this release?
It is a complete implementation of ARP, IP, UDP, and TCP for
RSX-11M-PLUS. It has been tested on RSX-11M-PLUS V4.6, but should work
on any V4 release. There might be some small tweaks or fixes required,
but nothing major.
It do require a system with split I/D-space, or else at least the TCP
part will not fit.
For Unibus machines, it should be possible to run without any additional
software except what is in a base RSX distribution.
For Q-bus machines, DECnet is required for ethernet networking.
The TCP/IP stack can co-exist with DECnet.
Some utilities also utilize RMS for file access.
A bunch of tools, utilities and libraries are also included. These
include:
. IFCONFIG network configuration tool.
. NETSTAT network information tool.
. PING
. TRACEROUTE
. DNS client
. FTP daemon
. FTP client
. HTTP server
. TELNET client (rudimentary)
. TFTP client
. TFTP server
. INET server that can do SINK, ECHO, DAYTIME, QUOTE, and IDENT
. NTP client
. LPR client that sits in the queue manager (rudimentary)
. FORTRAN-77 library
. BASIC+2 library
. PDP-11 C library
The implementation fulfills most of the requirements put forth in RFC
1122. There are a few limitations because of restrictions in the PDP-11,
but none of them should really cause any problems.
Documentation is still on the thin side, but example configs are also
provided, along with installation scripts.
A bunch of test programs and example programs are also included, as well
as the sources of all tools and libraries.
The TCP/IP stack itself only comes in binary form.
All tools are also included precompiled in the distribution, so an
installation only have to build the stack itself for your system, and
then you should be ready to go.
The API only have a slight resemblance to the Unix sockets API. However,
if someone sits down to write code to use TCP/IP under RSX, I'm sure
they will discover that it is extremely easy to use the libraries, or
the basic functions.
The TCP/IP implementation is mostly written as device drivers. This also
have some other interesting implications, such as it is possible to
access TCP as a normal file. You can, for instance do something similar
to the Unix netcat command by issuing the MCR command:
> PIP TI:=TC:"foo.com";4711
which would open a connection to foo.com, on port 4711, and any data
sent from that machine will be shown on the terminal.
The resources used by TCP/IP are modest. A memory area (size selectable
at generation/startup) is used internally. The amount of memory in the
private pool limits the amount of data that can be buffered. Normal pool
is used in a small quantity for each TCP port that is open.
People are welcome to play around with this, and make improvements.
Contributions of code is most welcome.
There are still lots of things to do. The programs marked as rudimentary
should be rewritten.
The most obvious thing still missing is a telnet daemon, which probably
is my next step.
However, the reason for now announcing the release is that it can
finally be distributed natively from an RSX host.
The main locations to download the TCP/IP for RSX are:
Madame.Update.UU.SE (anonymous ftp).
This is one of my development systems for this software. It runs under
E11, and if things are down, I blame E11. :-)
When connected, you are already in the right directory. There is both an
RL02 disk image there, which can be downloaded by anyone. If you happen
to have an RSX system which you are conneting from, you can also try
getting the BQTCP.TAP tape image. Such an image will not transport
cleanly to a non-RSX system, however. Sorry.
ftp.Update.UU.SE (anonymous ftp) - /pub/pdp11/rsx/tcpip
The disk image is normally duplicated to ftp.update.uu.se as well, so
the same file can be found there.
I hope some people will find this useful/amusing. :-)
Johnny Billquist
On 2015-03-16 21:05, Clem Cole wrote:
On Mon, Mar 16, 2015 at 3:55 PM, Johnny Billquist <bqt at softjar.se
<mailto:bqt at softjar.se>> wrote:
Nitpick: The 11/40 "class" machines did not have split I/D space.
Split I/D space was the 11/45,11/50,11/55 and 11/70, before we move
into "modern" PDP-11s..
That's what I said - "shared I/D" as opposed to "split I/D"
Doh! Color me stupid then. :-)
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
On 03/16/2015 02:28 PM, Johnny Billquist wrote:
On 2015-03-16 18:32, Clement T. Cole wrote:
Yes. It should be by easy to do, although I thought Tom put the BRU
support code in there because I remember one the folks we worked
(Mital in Canada IIRC) used RSX somewhere and he had the deal with it
when then sent us tapes. But may be it was not BRU. I don't remember
as that worked started as I was leaving UCB and Tom had become the new
mr. 9-track and Thus I did not write that code (I did write the
original RT11 support with which he started).
I obviously don't know what Tom might have done. It's definitely
possible he did. But depending on when this was, it might have been
another format called DSC (Disk Save and Compress), which is what RSX
used up until V3.something. Which is, I think, almost mid-80s.
My first 11/34 came with an RSX-11M v4.2 distribution tape, which had
been kicking around there for a couple of years already, in 1986, so I'd
assume 3.x was a bit earlier than mid-80s.
-Dave
--
Dave McGuire, AK4HZ/3
New Kensington, PA
On Mon, Mar 16, 2015 at 3:55 PM, Johnny Billquist <bqt at softjar.se> wrote:
Nitpick: The 11/40 "class" machines did not have split I/D space.
Split I/D space was the 11/45,11/50,11/55 and 11/70, before we move into "modern" PDP-11s..
That's what I said - "shared I/D" as opposed to "split I/D"
On 2015-03-16 20:43, Clem Cole wrote:
On Mon, Mar 16, 2015 at 3:13 PM, Johnny Billquist <bqt at softjar.se
<mailto:bqt at softjar.se>> wrote:
And one of the tricks were to reduce disk seek times during a
backup. And that is done by actually not backing up files in the
logical order of the blocks in the file, but in the order they
appear on disk, which is why I said the format is slightly tricky.
That was a common trade off - the reason being that backup was done way
more often then restore. But the problem was that the a lot of the
those formats had a big issues when you had a tape error (UNIX tp and
the PDP-10 dumper formats were notorious for this problem).
Tape errors gives you problems no matter which way you cut it. The BRU format allows you to deal with the rest of the file/tape properly anyway.
But as you say a threaded format like that, you don't need a PhD to
figure it out. You just need to be careful and recognize there is a
bunch of housekeeping needed when you pull things back in. Today its a
little easier, but on an 11/40 class (shared I/D space) that would be
even more difficult, since you don't have a lot of room in active memory
to keep those tables.
Nitpick: The 11/40 "class" machines did not have split I/D space.
Split I/D space was the 11/45,11/50,11/55 and 11/70, before we move into "modern" PDP-11s...
The 11/40 is really a primitive model, where most things you even could have was optional. The basic CPU do not have an MMU, no EIS, no stack limit, not to mention that the 11/40 never even had the capability of an FPP. It had the FIS instead...
(And no I/D space, nor supervisor mode, nor 22-bit addressing.)
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
On Mon, Mar 16, 2015 at 3:13 PM, Johnny Billquist <bqt at softjar.se> wrote:
And one of the tricks were to reduce disk seek times during a backup. And that is done by actually not backing up files in the logical order of the blocks in the file, but in the order they appear on disk, which is why I said the format is slightly tricky.
That was a common trade off - the reason being that backup was done way more often then restore. But the problem was that the a lot of the those formats had a big issues when you had a tape error (UNIX tp and the PDP-10 dumper formats were notorious for this problem).
But as you say a threaded format like that, you don't need a PhD to figure it out. You just need to be careful and recognize there is a bunch of housekeeping needed when you pull things back in. Today its a little easier, but on an 11/40 class (shared I/D space) that would be even more difficult, since you don't have a lot of room in active memory to keep those tables.
Clem
On 2015-03-16 19:52, Clem Cole wrote:
On Mon, Mar 16, 2015 at 2:28 PM, Johnny Billquist <bqt at softjar.se
<mailto:bqt at softjar.se>> wrote:
I obviously don't know what Tom might have done. It's definitely
possible he did. But depending on when this was, it might have been
another format called DSC (Disk Save and Compress), which is what
RSX used up until V3.something. Which is, I think, almost mid-80s.
Johnny,
As I said, neither do it and I don't have the code on-line to look
anymore, but given the dates you mention, DSC sounds more reasonable.
His work would have been 82/83 ish IIRC. I seem to remember that the
tapes from Mitel came from an RSX system that one of our
officemates/fellow grad students brought with him, telling us the tapes
were an RSX backup format. When we mounted them and started to poke
around, the tools we had would not work without modification. Since I
was getting ready to bug out/graduate, I remember Tom dealt with it, I
just don't remember how he did it.
Yeah. And I don't know at all how the DSC format looked like, but I believe it was simpler than BRU. One of the reasons for DEC to create BRU was to improve speed of backups. And one of the tricks were to reduce disk seek times during a backup. And that is done by actually not backing up files in the logical order of the blocks in the file, but in the order they appear on disk, which is why I said the format is slightly tricky.
This is a good example of knowing enough to be dangerous. I know a
little about RSX, but never dived in deep enough to be sure of any of
some of those details, so if you suggest that it was likely DSC, I
definitely bow to your knowledge.
:-)
That said, a quick look at:
http://www.ibiblio.org/pub/academic/computer-science/history/pdp-11/rsx/dec…
and, assuming no tape errors .... I suspect that it should not be that
hard to take any of the UNIX ansi tape readers that are available and
hack this format in them. Interesting to see the RAD50 stuff in there.
That takes me back to painful times.
Yeah, I have already studied that document at a great length.
The format is not hard. But the fact that you need to analyze some meta-information in order to understand where the disk blocks in the backup saveset actually fits into the restored file makes it a bit more interesting.
It also looks like the tape directory is in the front few blocks of the
tape, which was pretty typical of a number of tape formats, particularly
ones for backup. [This makes writing the tapes easier (faster) but it
also make recovery harder if you lose blocks in the directory].
Yes. Like said. It's not rocket science, but it is a bit more complicated than you might first realize.
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
On Mon, Mar 16, 2015 at 2:28 PM, Johnny Billquist <bqt at softjar.se> wrote:
I obviously don't know what Tom might have done. It's definitely possible he did. But depending on when this was, it might have been another format called DSC (Disk Save and Compress), which is what RSX used up until V3.something. Which is, I think, almost mid-80s.
Johnny,
As I said, neither do it and I don't have the code on-line to look anymore, but given the dates you mention, DSC sounds more reasonable. His work would have been 82/83 ish IIRC. I seem to remember that the tapes from Mitel came from an RSX system that one of our officemates/fellow grad students brought with him, telling us the tapes were an RSX backup format. When we mounted them and started to poke around, the tools we had would not work without modification. Since I was getting ready to bug out/graduate, I remember Tom dealt with it, I just don't remember how he did it.
This is a good example of knowing enough to be dangerous. I know a little about RSX, but never dived in deep enough to be sure of any of some of those details, so if you suggest that it was likely DSC, I definitely bow to your knowledge.
That said, a quick look at: http://www.ibiblio.org/pub/academic/computer-science/history/pdp-11/rsx/dec…
and, assuming no tape errors .... I suspect that it should not be that hard to take any of the UNIX ansi tape readers that are available and hack this format in them. Interesting to see the RAD50 stuff in there. That takes me back to painful times.
It also looks like the tape directory is in the front few blocks of the tape, which was pretty typical of a number of tape formats, particularly ones for backup. [This makes writing the tapes easier (faster) but it also make recovery harder if you lose blocks in the directory].
Clem
On 2015-03-16 18:32, Clement T. Cole wrote:
Yes. It should be by easy to do, although I thought Tom put the BRU support code in there because I remember one the folks we worked (Mital in Canada IIRC) used RSX somewhere and he had the deal with it when then sent us tapes. But may be it was not BRU. I don't remember as that worked started as I was leaving UCB and Tom had become the new mr. 9-track and Thus I did not write that code (I did write the original RT11 support with which he started).
I obviously don't know what Tom might have done. It's definitely possible he did. But depending on when this was, it might have been another format called DSC (Disk Save and Compress), which is what RSX used up until V3.something. Which is, I think, almost mid-80s.
BRU has been documented enough that it's not hard to write a program to extract the files from it, but it's is not totally trivial, as the files are somewhat scrambled in the saveset. I wrote a program to analyze and manipulate BRU tapes under Unix, to be able to repair tapes that had become corrupted (tape blocks scrambled).
When Tom took over he wrote a whole new program because the CAD group had had to start to deal with VMS so much and my original ANSI reader for RT11 tapes was pretty lame. When he was done, I'm pretty sure he could handle VMS save sets in his version because that what the CAD group @ DEC would use. I remember that HP used some funky format from the HP3000 which I ended up decoding using dd and some shell scripts and when never used again as we got them to switch to tar. IBM was always a different format (usually in EBCDIC). I remember once getting an ANSI labeled tape from them but in EBCDIC and broke all our tools. AT&T could also be funny. Different groups there used different tools even within UNIX so I got pretty good handling strange formats since they often sent tapes in binary and had endianness mixed in to add to the confusion. At the time, I became the go to person in Cory Hall (and often Evans folks would come to see me too) because I had spent time in a mainfra
m
e shop long before UCB and learned a lot of tricks and had a tool kit for same.
VMS backup savesets are totally incompatible with BRU savesets, though (sad). But I know I've seen Unix tools to read VMS tapes and savesets.
But both VMS and RSX use normal ANSI format tapes, so the first level of just getting to the savesets as such, is easy on Unix. Plenty of tools already exist to deal with ANSI labelled tapes.
Johnny
Somewhere I have a script called mtaapita - mag tapes are a pain in the ass - which I wrote to help pull the first few records apart and try to figure out how the tape was formatted. As I said, I used to have a pretty good collection of mag tape tools but they are not online anymore ( undoubtedly on a 9-track Unix dump tape in my basement).
Sent from my iPad
On Mar 16, 2015, at 12:25 PM, Johnny Billquist <bqt at softjar.se> wrote:
On 2015-03-16 14:08, Clem Cole wrote:
The format is defined in:
http://www.ibiblio.org/pub/academic/computer-science/history/pdp-11/rsx/dec…
and yes UNIX has tools that grok it.
Worst case it any ANSI tape reader will get the raw data off as files
with strange names and you may need a shell script to put some of the
files back together after decoding the directory.
My old housemate (and SPICE2/3 author) Tom Quarles wrote an really good
ANSI tape reader for Unix years ago. It did VMS format by default but
seem to remember he added RT11 and RSX support to it also. Since we had
to write tapes to export to those systems also.
Sadly, I used to have a directory of "magtape utilities" but I no longer
have it online. I'll try to poke around to see if I can find it next
weekend if no one else shouts out sooner.
BRU tapes are proper ANSI format tapes, so as far as that goes, the whole saveset as such can certainly be accessed with any tool that deals with ANSI tapes.
However, BRU savesets is another level, below this. To extract files from those savesets will require other software. I don't think any exists for Unix, but you can certainly write it.
Johnny
Clem
On Mon, Mar 16, 2015 at 1:05 AM, Cory Smelosky <b4 at gewt.net
<mailto:b4 at gewt.net>> wrote:
All,
Is it possible to extract files from a BRU RSX tape on UNIX, or is
the best path BRUREAD to VMS, and then zip/tar?
--
Cory Smelosky
http://gewt.net Personal stuff
http://gimme-sympathy.org Projects
--
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
