• Please review our updated Terms and Rules here

can you help me identify the contents of an rl02 disk?

I

iainmaoileoin

Experienced Member
Joined
Dec 24, 2014
Messages
216
Location
inverness
http://www.scotnet.co.uk/iain/DEC/strings

I bought some RL02 disks; Was planning to format them.
I *THINK* that trying to boot from each of them gave me a "no boot block" (or such like) error.

Before toasting the 1st drive I thought I would do a unix "stirngs" on it (strings /dev/rrl0a)

The results are in the link given above.
Is it 1.5Meg of "junk"?

I am not sure, lots of interesting snippets - wee tables and what appears to be a unix like system with /usr/ and /dev/ and such like.
Can anybody tell me what I have here? I suppose I could put up the entire dd if it is not breaching somebodies copyright.

But what it is?

search for "-----"
[a-z][a-z][a-z]
/.*/.*/
chmod
2/2B EF1 & EARLIER MULTILINE HUNT GROUP STATION DISCONNECT
1/1A ADD/REPLACE A RATE & ROUTE PATTERN NO IN 3/6 DIG TRANS - SCC
5ESS VERIFICATION OF ONE DIGIT SPEED CALL LIST
WOULD YOU LIKE A PRINTOUT OF YOUR SESSION (Y/N)?

The strings below remind me of when I read the "cp/mv" command that had been moved to the kernel of a vax unix system
%s: command must be named cp|mv|ln--defaults to `cp'
%s: %s not found
%s: cannot access %s
%s : <%s> directory
%s/%s
%s: %s and %s are identical
%s: %s: %o mode
%s: cannot unlink %s
%s: different file system
%s: no permission for %s
%s: cannot open %s
%s: cannot create %s
%s: bad copy to %s
%s: cannot unlink %
%s: directory %s exists
%s: ?? source == target, source exists and target doesnt
%s: cannot rename %s
%s: cannot locate parent
%s: directory rename only
%s: no write access to %s
%s: cannot link %s and %s
%s: ?? cannot unlink %s
Usage: {mv|cp|ln} f1 f2
{mv|cp|ln} f1 ... fn d1
mv d1 d2


I suppose it could be VAX and not PDP11 boot blocks?

Anyway - have a poke if you want a walk down memory lane.
 
What would I boot it on? an AT&T system. Apart of V6 and V7 the only AT&T kit I remember using was a 3B.
I have not seen one of those for 40 years. I never saw a 3B with RLs - since they were not PDPs.
I guess I need to poke around the boot block for a bit of information and see what the programs are?
 
I believe what you have is a disk from an RMAS system. RMAS stood for "Recent change Memory Administration System". RMAS was a system used to input "Recent Change" messages to alter databases in various elements in the telephone network. At least in our area they supported a group called RCMAC or "Recent Change Memory Administration Center". If a new telephone line was to be connected, and old one deleted, or features added or deleted, either a machine generated or manual entry message was sent to an RMAS which then generated an input message appropriate for the given network element type. Messages could either be held until a "release window" or immediately input into the target system.

Note that there are many messages in your strings associated with #5ESS tables. But there are also references to DACS, DMS10, No. 3, 5ETS, 2/2B, 1/1A and others.

Typically an RMAS system that needed to input into a network element would seize an input channel to that element then verify it was talking to the correct one. It would do so by inputting a message such as "UTL::QRY,WHO!" (for an AT&T DACSII) or "WHO-RU-." for a #1 or #1A ESS. Both of those messages appear in your list of strings. It would then input the message and read a response which would often be in the form of an RC message, "RC18 ACPT" for example, which would indicate success or failure and log the response. Note that your strings have a bunch of various RCnn messages.

When I worked at our minicomputer center we had dozens of these RMAS systems lined up in rows. They were all PDP11/23 PLUS in the typical 4 ft cabinet with two RL02 drives.

They looked just like the one on this page.

http://www.cosam.org/computers/dec/pdp11-23/

Hope that helps.
 
Before you do anything else with that disk I'm going to strongly suggest you image it and have the image archived somewhere. During my 42 years with what used to be called "The Bell System" I had quite a lot of contact with various flavors of Unix. Before Unix became widely known "Ma Bell" was using it internally in variants that never saw the light of day externally. As a result of these variants being for internal use only many of them have been lost or nearly so.

See here:

https://www.usenix.org/legacy/event/usenix09/tech/full_papers/toomey/toomey.pdf

And here:

http://www.mailcom.com/lsx/

My first exposure to Unix was in a Switching Control Center where we remotely monitored performance of #1ESS, #1AESS, #5ESS, and DMS100 switches and dispatched techs to clear troubles in them as necessary. We accessed these switches through PDP11/70 computers that ran a system called #2SCCS (Switching Control Center System). It was a variant of Unix III but we often noticed the syntax in the man pages did not match those published for the plain vanilla Unix III. Later some of our PDP11/70's started being replaced by 3B15's running the #3SCCS based on a variant of Unix V. Again, a variant, as some of the core Unix programs used different syntax. I was later to see more variants in the Administrative Module (AM) 3B20D's of the #5ESS switches and a different one in the Attached Processor System (APS) 3B20D's in the #1AESS switches. After a while it became obvious that quite a bit of gear made by Western Electric/AT&T/Lucent Technologies had some form of Unix in them if you scratched deeply enough. I suspect most of these variants are lost for good because no value was seen in preserving them. As the equipment was retired & scrapped the tapes, documentation, etc. was scrapped along with the hardware.

In short, your disk might contain the last surviving copy of the Unix variant that RMAS was built on. I noticed quite a few .o files in your listing along with what appeared to be c code variables as they would be stored in the symbol table of an a.out file. That would help anyone trying to disassemble the code on the disk a great deal. Sometimes this stuff was run through a program (strip?) that removed the symbol table to save space. You're not likely to see any source code on the disk. We did have one PDP11/70 at our computer center that had a source license but generally source would not be on a running network element due to space constraints and security concerns.
 
OK, I have a dd in 3 places - including another RL02. I can get the image to my web-pages if that helps anyone.
However is there a more general repository for "stolen or otherwise shady software?" ;-( Sorry, I meant to say "Items of archaeological interest".

I need some evenings to see if I can figure out what OS/filesystem/format is on the disk.
It wont boot "no boot block". An attempt to mount it as I finished last night took the kernel out - an old unix trait when the superblock is "not as expected".

The disk was writ-prot (and tested to be so!), so no damage done

On your reverse engineering comments:
In the 80s at Strathclyde Uni Alan Black developed a vax ".o" to "C" program that he trained to "recover" the source of the game "rogue".
He could recompile the functions to generate exactly the code that was in the executable. Eventually he ended up with a recompilable source -
all so he could remove a bug he did not like. I think I would just have thunked it.
 
Before you do anything else with that disk I'm going to strongly suggest you image it and have the image archived somewhere. During my 42 years with what used to be called "The Bell System" I had quite a lot of contact with various flavors of Unix. Before Unix became widely known "Ma Bell" was using it internally in variants that never saw the light of day externally. As a result of these variants being for internal use only many of them been lost or nearly so.

See here:

https://www.usenix.org/legacy/event/usenix09/tech/full_papers/toomey/toomey.pdf

And here:

http://www.mailcom.com/lsx/

My first exposure to Unix was in a Switching Control Center where we remotely monitored performance of #1ESS, #1AESS, #5ESS, and DMS100 switches and dispatched techs to clear troubles in them as necessary. We accessed these switches through PDP11/70 computers that ran a system called #2SCCS (Switching Control Center System). It ran a variant of Unix III but we often noticed the syntax in the man pages did not match those published for the plain vanilla Unix III. Later some of our PDP11/70's started being replaced by 3B15's running the #3SCCS based on a variant of Unix V. Again, a variant, as some of the core Unix programs used different syntax. I was later to see more variants in the Administrative Module (AM) 3B20D's of the #5ESS switches and a different one in the Attached Processor System (APS) 3B20D's in the #1AESS switches. After a while it became obvious that quite a bit of gear made by Western Electric/AT&T/Lucent Technologies had some form of Unix in them if you scratched deeply enough. I suspect most of these variants are lost for good because no value was seen in preserving them. As the equipment was retired & scrapped the tapes, documentation, etc. was scrapped along with the hardware.

In short, that disk might contain the last surviving copy of the Unix variant that RMAS was built on. I noticed quite a few .o files listed along with what appeared to be c code variables as they would be stored in the symbol table of an a.out file. That would help anyone trying to disassemble the code on the disk a great deal. Sometimes this stuff was run through a program (strip?) that removed the symbol table to save space. You're not likely to see any source code on the disk. We did have one PDP11/70 at our computer center that had a source license but generally source would not be on a running network element due to space constraints and security concerns.
 
I found this at the near the bottom of the "toomey.pdf" paper I cited above:

"Never underestimate the ‘packrat’ nature of com-
puter enthusiasts.
Artifacts that appear to be lost are
often safely tucked away in a box in someone’s base-
ment. The art is to find the individual who has that box.
The formation of a loose group of interested enthusiasts,
TUHS, has helped immensely to unearth many hidden
treasures. And professional organisations such as the
Computer History Museum are vital if the computing in-
dustry wants to preserve a detailed record of its past.
In conclusion, the restoration of some of the earliest
software artifacts from the development of UNIX has
been time-consuming, frustrating but most importantly
extremely rewarding. It is now more important than ever
to begin to preserve computing history, not as a collec-
tion of “stuffed exhibits”, but to keep old systems run-
ning as was intended by their designers."

Pretty cool description of our "hobby" eh?

I would only add that it is important to find "that box" before the programmer's heirs or significant other decides it belongs in a dumpster and then take the right steps to preserve the contents.
 
You must log in or register to reply here.
Back
Top