RSTS v7 hangs during build

[Paul A]

Hello everyone, 

... new to the forum and the whole PiDP 11/70 community.

Grew up in an 11/70 running RSTS/E v7 and attempting to recreate that experience.

While away on Vacay (PiDP waiting at home to be completed), I started playing with SimH on my S2 MacBook.

I did a complete make of Open-SimH 4 from GitHub.

And a complete SYSGEN of RSTS/E v7 from RSTS.org.

Everything was running great ... 

Then I started trying to mount some of the .dsk and .tap files I found online.

The RSTS build doesn't include Fortran or C, or much in the way of programming languages.  

So I was trying to figure out how to add some of those, when disaster struck ...

SEGMENT FAULT!  SimH crashed and I was back at a shell prompt.

(Stupidly, I closed that terminal window, so I don't have a record of that.)

Afterwards, every attempt to reboot RSTS hangs.

All DL disks, which had been working perfectly, are sudden disabled ... in RSTS.

SimH says they are there, attached and available.

I tried to boot from several different .dsk files, all of which worked before, with no luck.

Today I did a forced remake (make -B) of Open-SimH, redownloaded the RSTS files, and started another SYSGEN ... but about 3 or 4 steps in, everything hangs ....

I've been following the SYSGEN script that came with the RSTS files, which I've used 3 or 4 times successfully.

Here's what I'm currently getting,  Not much to work with ...

Option: 

You currently have: JOB MAX = 2, SWAP MAX = 28K.

You currently have crash dump enabled.

05-Aug-86? 05-AUG-86

08:14 AM? 08:14

20 devices disabled

( .... just sits there ....)

Not sure how to proceed from here.

Any help would be appreciated.

Thanks.

Paul

[Paul A]

Just for additional info; this is what I had, before the segment fault.

SYSTAT

RSTS V7.0-07 HOUGHTON RETRO status at 31-Jul-26, 09:51 PM Up: 1:26

Job    Who    Where    What    Size    State    Run-Time  Pri/RB   RTS

 1    [SELF]  Det     ERRCPY   5/31K   SR           15.2    0/6   BASIC 

 2    [SELF]  Det     OPSRUN  16/31K   SL            2.4   -8/6   BASIC 

 3    [SELF]  Det     QUMRUN  16/31K   SL            2.3    0/6   BASIC 

 4    [SELF]  Det     SPLIDL  16/31K   SL            1.5   -8/6   BASIC 

 5    [SELF]  Det     BATIDL  13/31K   SL            1.3   -8/6   BASIC 

 6    [SELF]  KB0     SYSTAT  11/31K   RN Lck        0.6   -8/6   BASIC 

Busy Devices: None

Disk Structure:

Disk    Open    Free    Cluster Errors  Name    Comments

DL0      12     998        2      0     DISK0   Pub, DLW

DL1       1     8136       2      0     PRIVAT  Pri, DLW

DL2       0     10196      2      0     DISK2   Pri, DLW

DL3       0     6208       1      0     GAMES   Pri, DLW

Small   Large   Jobs    Hung TTY's      Errors

146       1      6/16       0              0

Run-Time Systems:

 Name   Ext       Size  Users   Comments

BASIC   BAC     16(16)K   6     Perm, Addr:36, KBM, CSZ

RT11    SAV      4(28)K   0     Non-Res, KBM, CSZ, EMT:255

RSX     TSK      3(28)K   0     Non-Res, KBM

TECO    TEC      8(24)K   0     Non-Res

Resident Libraries: None

Message Receivers:

 Name   Job     Msgs    Max     Senders

ERRLOG   1       0      40      Priv

OPSER    2       0      30      Local

QUEMAN   3       0      60      Local

LP0SPL   4       0       5      Priv

BA0SPL   5       0       5      Priv

Ready

UT

UTILTY  V7.0-07E        RSTS V7.0-07 HOUGHTON RETRO

#LIST SWAPFILE

Swapfile 0:     DL1:[0,1]SWAP0 .SYS

Swapfile 1:     None

Swapfile 2:     DL0:[0,1]SWAP  .SYS

Swapfile 3:     None

Overlay file:   None

Error file:     None

#LIST LOGICALS

Unrecognized Command - LIST LOGICALS

Type 'HELP' for Help

#LIST LOGICAL

DL0:DISK0 

DL1:PRIVAT

DL2:DISK2 

DL3:GAMES 

DL3:[100,102]G2    

DL3:[100,101]G1    

DL3:[100,100]G0    

SY:[1,1]LB    

#^Z

Ready

I was successful in mounting MM0: with a .tap file 

(once I figured out I needed to set it to TPC format).

Then I was trying to mount DP0: on a copy of f4v28.dsk, when the seg fault occurred.

Is there some kind of device conflict between the DL and DP disks that I'm not aware of?

The RSTS build shows using only DL disks, but I'd like to make some of the larger disks available

(since virtual hardware is essentially free!).

Thanks in advance.

[terri-...@glaver.org]

You can have DL and DP on the same system. I'm pretty sure those are both fixed vector and CSR, 

so adding DP shouldn't cause a shuffle of the floating CSR / vector.

What happens if you enter "HA LI" at the "Option?" prompt instead of hitting the return key?

It it possible that the custom monitor you generated is missing support for some of the "hardware"

you have on your system? 20 devices is a lot unless you're running a generic monitor or somesuch.

Entering "INSTALL" (IIRC) at the "Option?" prompt will let you switch to any other monitors you may

have on the system. It is likely that you'll have (at least) a SYSGEN.SIL as well as any you created.

A job max of 2 isn't going to get you far, even on V7. Memory is free, unless you're running on an

older system with only 18-bit addressing. Increase your job max and swap max (if possible).

Can we see your SIMH .ini file?

[Paul A]

Thanks for the response.

Yeah,  during that SYSGEN I threw in a little of everything, except the kitchen sink.

And that was part of the reason I was doing another, to be more selective.

The 2 Jobs were just for that step of the SYSGEN, according to the build script from RSTS.

I don't have a SIMH.ini file; I was in the process of creating one when all this happened.

I was just hand-jamming' everything, as I was experimenting.

Something simple like this:

; Set the CPU

;

echo Setting CPU defaults ...

set cpu 11/70, 4M, FPP

sh cpu

sleep 5s

;

; Attach the 4 RL cartridge drives

;

echo Attaching 4 RL drives (DL0:, DL1:, DL2:, DL3:)

att rl0 <... some path ...>/rsts_disk0.dsk 

att rl1 <... some path ...>/rsts_disk1_swap.dsk 

att rl2 <... some path ...>/rsts_disk2.dsk 

att rl3 <... some path ...>/rsts-games.dsk 

sh rl

sleep 10s

;

Here's what simh said, last time I tried to boot it all (before I started the new SYSGEN).

sim> sh rl

RL      RL11, address=17774400-17774411, vector=160, BR5, 4 units

  RL0   2621KW, attached to /rsts_disk0.dsk, on line

        write enabled, RL01, autosize

        RAW format

  RL1   2621KW, attached to /rsts_disk1_swap.dsk, on line

        write enabled, RL01, autosize

        RAW format

  RL2   2621KW, attached to /rsts_disk2.dsk, on line

        write enabled, RL01, autosize

        RAW format

  RL3   2621KW, attached to /rsts-games.dsk, on line

        write enabled, RL01, autosize

        RAW format

I was really surprised the DL problem carried over after remaking open-simh and the pdp11 module.

Is there a config file that would've survived the remake, that could be corrupting the process?

Thanks

[Paul A]

OK, breaking news ... I'm an idiot.

Terry thanks for responding.

But I think I've figured it out.

It appears the original SYSGEN was based on a PDP 11/70 with only 2M of memory.

By changing that parameter,  I'm able to boot up the system I had running.

Here's where having a working .ini file would've helped!

Lesson learned.

Now to see if I can SYSGEN a system with a more realistic configuration.

I'll let you know how I make out.

Thanks again!

[terri-...@glaver.org]

RSTS/E autosizes memory on boot, and runs acceptably on a machine like an 11/34A (which is limited to 128KW). So I'm not sure how this would matter. If you change the system memory size or boot a different monitor, you'll get a "Memory allocation table has changed" when you go to start timesharing.

[Paul A]

It seems very strange to me, as well.

But that is the only thing I changed:

        set cpu 11/70, 4m, FPP    -->   set cpu 11/70, 2m, FPP

and suddenly I was up and running the previously built system

(the one that crashed).

Then today I successfully did another SYSGEN of a downsized system,

and it seems to be working fine.

So I'm back to where I was.

I'll be attempting to mount some C and Fortran .tap and .dsk files.

Any advice on getting those to work?

Also, I guess DCL wasn't ever on v7, so most of that is handled by UTILTY?

Thanks,

Paul

[Gerry Duprey]

That is odd - though 7.0 was the first version of RSTS/E to support 4MB.  

It's possible that 7.0 4MB support was a little fragile being the first/new and maybe not entirely compatible with SIMH.  

Maybe a slightly later version of 7 (7.2 was a good, solid V7 release and include I&D space support for much larger programs)

That said, as much as I loved RSTS/E (it was my first grown-up computer) and was with it from 7.0 til the end in the late 90s, I feel it really hit its stride in 10.x, with multiple levels of permissions, removing weird shackles (like [1,2] being the only privileged account, adding other [0,*] accounts) and fully featured first-class DCL implementation.

And yeah - before DCL, much of the startup/setup stuff was done via UTILTY - a handy tool I was happy to retire when DCL grew up ;-)

Gerry

--
You received this message because you are subscribed to the Google Groups "[PiDP-11]" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pidp-11+u...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/pidp-11/f6f37eff-ba89-4a39-a54a-f91bae235be2n%40googlegroups.com.

[Anton Lavrentiev]

Since it's SimH which crashes, I don't think it matters if you are
running an OS already or not. Try attaching all the devices you did
for starting RSTS/E, and then attach the image, which crashed your
simulator. Also, I'm not an RSTS/E expert but IIRC DP: was a mnemonic
used for RP02/03 disks. Those are used to attach to an RP11
controller, which is not enabled by default in open-simh (it is using
the same IO and interrupt vector as the RH70/RH11 Massbus adapter
(RHA), which handles RP disks of the next gen, RP04+ and RM02+ -- all
those are enabled by default. I'm not sure which device mnemonic
those disks used, but I think it was "DB:" (that's what RSX would use
for these devices).

> Then I was trying to mount DP0: on a copy of f4v28.dsk

What command did you use to attach your f4v28.dsk image in simh?

"HA LI" in the INIT boot prompt (as Terri Suggested) of RSTS should
obviate if your system has detected any of those. INIT does not
however guarantee that these were sysgenned into the actual system
image -- those are shown by SYS, and yours obviously does not have
them there. So, I suppose by "mounting" you actually mean "attaching"
(and RSTS should have rejected the command with an unknown device
mnemonic).

[LWF (RealTimeCat)]

Paul, 

My professional career in computer science started with RSTS/E 6.0-C. I believe RSTS/E. 

V7.1 was the first version to introduce DCL scripting. With RSTS/E V9.0, DCL became the default scripting language. Many of the previously common utilities (REACT, MONEY, UTILTY, etc) were superseded with DCL-only commands. 

The RSTS/E dialect of DCL is different enough from that of VMS that there is a small learning curve, especially if you had developed muscle memory for specific switches on VMS prior to working with the RSTS/E version of commands. Specific areas of major differences included the specification of account privileges and other user account defaults. 

The timeshare system I managed was fortunate enough to be one of the test-bed systems for Keven Herbert's terminal links. I had successfully implemented and maintained them on the system for RSTS/E V6 an RSTS/E V7 implementations. Other hacks on our RSTS/E V6 included making use of the File Attribute fields in the MFD to store bits regarding privileges and capabilities we defined for users of the TALK and ADVISE programs (again, part of the KPH terminal links suite). The MFD file attributes went away with V7 of RSTS/E, but I had been careful to back them up to equivalent Basic Plus string Virtual arrays and was able to easily modify the applications utilizing the bits to work from that file. 

Fun times!

[terri-...@glaver.org]

On Thursday, August 6, 2026 at 10:34:34 AM UTC-4 paul...@mac.com wrote:

It seems very strange to me, as well.

But that is the only thing I changed:

        set cpu 11/70, 4m, FPP    -->   set cpu 11/70, 2m, FPP

and suddenly I was up and running the previously built system

(the one that crashed).

 

RSTS/E will (or would, I'm not sure if it's been fixed) overwrite its memory sizing

routine if it didn't hit an NXM trap anywhere along the line. The gate-array-based

PDP2011 backfilled the IO page with RAM, so unless some simulated device got

upset when its CSR was read, the sizer would go right past the IO page and wrap

to address zero. I don't think any of the SIMHs ever had that issue, though:

https://pdp2011.sytse.net/wordpress/rsts-and-j-11/

I think the INIT.SYS option to show the memory layout is TABLE. But my per-

sonal memory never had ECC, and the parity checking logic failed a decade or

two ago. 8-}

Then today I successfully did another SYSGEN of a downsized system,

and it seems to be working fine.

So I'm back to where I was.

I'll be attempting to mount some C and Fortran .tap and .dsk files.

Any advice on getting those to work?

You'll want to make sure that the versions of those languages run on RSTS/E V7.

I know that PDP-11 C won't. That's likely the case for COBOL-81 and Fortran-77.

PDP-11 COBOL and FORTRAN IV should work. 

Also, I guess DCL wasn't ever on v7, so most of that is handled by UTILTY?

Yes. UTILTY is still around in V10.1 for things that still use it (like some layered

product startups). And for speed, some things are done "behind DCL's back" -

for example, the V10.1 startup invokes $TERMGR to process a bunch of "set

terminal" commands, rather than having each one go through the DCL parser.

[terri-...@glaver.org]

On Thursday, August 6, 2026 at 10:48:21 AM UTC-4 gdu...@gmail.com wrote:

That said, as much as I loved RSTS/E (it was my first grown-up computer) and was with it from 7.0 til the end in the late 90s, I feel it really hit its stride in 10.x, with multiple levels of permissions, removing weird shackles (like [1,2] being the only privileged account, adding other [0,*] accounts) and fully featured first-class DCL implementation.

I agree. And it got command line editing. After many years of "that's too hard",

the CLE (Command Line Editing) run-time system was written by Brian Nelson

and updated and enhanced by me. It goes through some contortions to "play

nice" with the rest of RSTS/E. As an example, every single character except ^T

is declared as a private delimiter, so ^T still gets passed through to RSTS and

reports job status as usual. It worked on RSTS/E V9.0 through V9.7, then V10

came along with it finally built in.

V9.6 finally delivered LAT support, promised since V9.3 added Ethernet (but

only for DECnet at the time). I handed out buttons at the Symposium where 

V9.6 was announced that said "Better LAT/E than never". 8-}  You do need

DECnet in order to enable LAT - I'm not sure why, but never bothered to look

in the uncensored sources (which include the source to DECnet/E) to see why.

[terri-...@glaver.org]

On Thursday, August 6, 2026 at 10:57:09 AM UTC-4 LWF (RealTimeCat) wrote:

The RSTS/E dialect of DCL is different enough from that of VMS that there is a small learning curve, especially if you had developed muscle memory for specific switches on VMS prior to working with the RSTS/E version of commands. Specific areas of major differences included the specification of account privileges and other user account defaults. 

VMS had the advantage of having DCL from Day One. In RSTS/E, it was grafted on

over time until it got as much feature parity as possible. Some things are just dif-

ferent because of the operating system (like lexical functions). Other things are

different... because...

Implementing it was "interesting".  DCL isn't as internally consistent as you might

think. This came up with the /NOTIFY option to print and batch commands. Nor-

mally /NOmumble negated mumble. For a while, that meant that "/TIFY" was a 

valid (but hidden) qualifier, and negating it produced "/NOTIFY".

This isn't just a RSTS/E thing. On VMS, you can say "NO/NONO" which is a valid

command on a system with VAX Notes installed. It invokes NOTES, while not

accessing the user's notebook (/NONO is actually /NONOTEBOOK).

When RSTS/E V9 came along with the BACKUP command, I complained loudly

that it couldn't deal with many VMS backup savesets as it was limited to an

8192-byte record size. Via a bunch of contortions (which had the RSX group run

away screaming after they asked to use the RSTS/E BACKUP and saw the code),

RSTS/E BACKUP was extended to handle buffer sizes up to 28672. The buffer

sits in a job-local piece of supervisor D-space and the last 4K is reserved. Also,

RSTS/E uses a separate RESTORE command, while VMS uses the BACKUP com-

mand for all operations.

[terri-...@glaver.org]

On Thursday, August 6, 2026 at 10:52:01 AM UTC-4 Anton L. wrote:

Also, I'm not an RSTS/E expert but IIRC DP: was a mnemonic
used for RP02/03 disks. Those are used to attach to an RP11
controller, which is not enabled by default in open-simh (it is using
the same IO and interrupt vector as the RH70/RH11 Massbus adapter
(RHA), which handles RP disks of the next gen, RP04+ and RM02+ -- all
those are enabled by default. I'm not sure which device mnemonic
those disks used, but I think it was "DB:" (that's what RSX would use
for these devices).

A bit of fascinating trivia - INIT.SYS was never told to forget about devices

no longer supported by RSTS/E (like RS fixed-head disks). It can still format

them and do everything else that INIT.SYS does, but of course once it trans-

fers control to the monitor, those devices are no longer visible.

And when I said "format", I meant it - for disks that can actually be formatted

(as opposed to just erased) it knows how to hardware format them.

Easter egg: INIT.SYS also knows what a Pro/3xx is and will work on one. But

again, there's no [released] monitor support for the Pro. 

[Paul A]

On Thursday, August 6, 2026 at 10:52:01 AM UTC-4 Anton L. wrote:

I'm not an RSTS/E expert but IIRC DP: was a mnemonic
used for RP02/03 disks. Those are used to attach to an RP11
controller, which is not enabled by default in open-simh (it is using
the same IO and interrupt vector as the RH70/RH11 Massbus adapter
(RHA), which handles RP disks of the next gen, RP04+ and RM02+ -- all
those are enabled by default. I'm not sure which device mnemonic
those disks used, but I think it was "DB:" (that's what RSX would use
for these devices).

That is one thing that still baffles me, and I have yet to find clear guidance in the manuals: 

which simh device corresponds to which PDP-11 device?

I know RL: = DL:, but I was using trial an error on the others. 

And as I recall (since I stupidly closed the shell window) I had gotten a message about vector 224 being a conflict.

Do TU: and DP: devices use the same vector?

> Then I was trying to mount DP0: on a copy of f4v28.dsk

What command did you use to attach your f4v28.dsk image in simh?

 

ATTACH in simh and then MOUNT in RSTS.

I don't remember the specifics. 

"HA LI" in the INIT boot prompt (as Terri Suggested) of RSTS should
obviate if your system has detected any of those. INIT does not
however guarantee that these were sysgenned into the actual system
image -- those are shown by SYS, and yours obviously does not have
them there. So, I suppose by "mounting" you actually mean "attaching"
(and RSTS should have rejected the command with an unknown device
mnemonic).

Here's the HI LI from my new system:

Option: HA LI

  Name  Address Vector  Comments

  TT:    177560   060

  RK:    177400   220   RK05F units: none

  RL:    174400   160   Units: 0(RL01) 1(RL01) 2(RL01) 3(RL01)

  RM:    177440   210   Units: 0(RK06) 1(RK06) 2(RK06) 3(RK06) 4(RK06)

                               5(RK06) 6(RK06) 7(RK06)

  RR:    176700   254   BAE=+050, Units: 0(RM03) 1(RM03) 2(RM03)

                               3(RM03) 4(RM03) 5(RM03) 6(RM03) 7(RM03)

  TM:    172520   224

  PR0:   177550   070

  PP0:   177554   074

  LP0:   177514   200

  RX0:   177170   264

  DZ0:   160100   300

  DZ1:   160110   310

  KW11L  177546   100

  SR     177570

  DR     177570

  Hertz = 60.

  Other: FPU, SL, 22-Bit Addressing, Cache w/address, System ID = 4660

I wanted to have some disk pack disks and magtapes available.

So I SYSGEN'd 2 each of several different devices.

And that is what I got.  I guess it'll change when I start enabling them ...?

I'm guessing     TM: = MT:

 but                     RM: = ?

and                     RR: = ?

In simh, RK06s appear to be HK:?

And, RM03s appear to be DP:?

I'm confused .... 

[Anton L.]

There's has always been distinction between hardware names of devices and device names used by OSes, and it has only partially consistent.

Tx hardware devices were tapes, TM11, TS11, etc...  In many OS'es they were called MT:, MM:, MU:, MS:, etc.  The only exception was "TC11" (for DECTape), which would be a "disk" in the operating system environment, such as DT: (e.g. in DOS).

Rx hardware devices were disks (I suppose "R" was for "rotating")...  All these would generally appear as "Dx:" devices in the OS'es.

DK: would correspond to the RK05 disks (but! for RT-11 DK: denotes your boot disk device, and the physical disk for the RK controller would be called "RK:"), DL: -- to RL11 drives, DP: (under RSX) would be for RP02/03, DR:, DB:, DM:, DU:, DY:, DX: etc for various controllers...

So, I suppose (well, assume, in reality) RSTS/E would use the DM: and DR: mnemonics for the disk drives that "HA LI" show as "RM:" and "RR:", respectively.  There would not be any "DP:" available.  I guess RSTS/E folks should be able to tell for sure.

I'm kinda puzzled when exactly your simh crashed, when you were attaching the disk image in the "sim>" prompt or when you were attempting to mount a "DP:" drive from under RSTS/E?  'Cuz this really matters.  Can you maybe reproduce that by re-tracing your steps (using a temp file area and images, that you wouldn't care to lose, for just this one time once again)?

[Paul A]

On Friday, August 7, 2026 at 4:40:04 PM UTC-4 Anton L. wrote:

 

I'm kinda puzzled when exactly your simh crashed, when you were attaching the disk image in the "sim>" prompt or when you were attempting to mount a "DP:" drive from under RSTS/E?  'Cuz this really matters.  Can you maybe reproduce that by re-tracing your steps (using a temp file area and images, that you wouldn't care to lose, for just this one time once again)?

 

I had ATTACHed a .tap file to TU0: and successfully read the directory from it in RSTS/E.

Then I ATTACHed the f4v28.dsk to RP0:, which seemed to work in simh.

But when I attempted to MOUNT DP0: in RSTS/E, it generated a Segment Fault.

After reseting simh, and for the next 2 days, every time I booted RSTS

... regardless of the boot disk ...

it disabled all the DL: disks and hung ... 

no response after the 'devices disabled' message.

I'm pretty sure I trashed all those files, when I recompiled open-sim.

I was attempting a complete purge, since it wasn't obvious what was causing the hang after the crash.

[Paul Koning]

A couple of reactions.

If SIMH crashes, that's a SIMH bug, not a bug in the software running on it.  You  might build SIMH with DEBUG=1 on the "make" command line, then run the emulation via the debugger ("gdb pdp11", gdb> run <args>).  If you hit the crash, it will drop into the debugger and you can  use "bt" to get the call stack and find where it went wrong.

I can't imagine any reason why restarting the emulation after such a crash would cause RSTS to believe the devices are not there.  What you should do: in the first run, use "HA LI" to get the hardware list as RSTS (INIT) sees it.  Compare that with what SIMH is set up to do; if there is a mismatch then something got confused.  It should be ok to have devices that aren't supported or are not part of the SYSGEN you did, but if you have extraneous stuff you do have more opportunities for addressing to go wrong.  Next, instead of starting by the default start, use the ST command, which is the verbose version where any device disable actions are reported with the device name given.

Now reproduce the crash, and then do the same (HA LI and ST) afterwards.  See what is different.

[Paul Koning]

Mostly true.  A few disks were really entirely removed because of space issues; the RF11 comes to mind.

And yes, you can boot on a Pro.  It's a bit tricky.  Copy the minimal bootable system  (INIT.SYS in particular) to an RX50 style floppy and hook it.  The hook part requires asking for the "DZ" bootstrap rather than the default DU.  I don't think standard HOOK can do that.  It can be done with my utility RSTSFLX, though.

One of these days I should make a V101 Pro config available.

[Paul Koning]

The main reason V9 BACKUP has a lower record size limit is that it needs to have several record buffers, not just one, because the most important new feature (with help from the monitor) was asynchronous I/O to enable streaming operation on tapes like the TS80.  And it could not count on having I/D and supervisor mode available.

As for DCL, the early implementations were somewhat clunky.  In V9.0 it got a pile of help from the monitor, with "permanent files" to allow DCL to keep stuff it needed to track across calls in a scratch file, and to keep the command files and log file.  The command and log file handling was grafted into the terminal driver (that was a rather weird project) so unlike earlier batch or indirect command file services, V9.0 DCL command files do not require additional jobs.  That is also when command files became "executable" and system startup simply involved creating the first job and making it run [0,1]sysini.com.

BTW, someone mentioned fine grained privileges not tied to hardcoded user numbers.  That appeared in V9.0, though I don't remember whether it was fully documented or supported.  I also prototyped the notion of "installing" privileged programs with configurable privilege masks, akin to what VMS long had, but while it worked it wasn't shipped.

[Paul A]

On Thursday, August 6, 2026 at 5:07:04 PM UTC-5 terri-...wrote:

On Thursday, August 6, 2026 at 10:34:34 AM UTC-4 paul..wrote:

So I'm back to where I was.

I'll be attempting to mount some C and Fortran .tap and .dsk files.

Any advice on getting those to work?

You'll want to make sure that the versions of those languages run on RSTS/E V7.

I know that PDP-11 C won't. That's likely the case for COBOL-81 and Fortran-77.

PDP-11 COBOL and FORTRAN IV should work. 

 

You were saying ....?

I can mount the fortran_iv_v2_8.tap and copy the file onto one of the drives.

Any hints on how to proceed from there would be appreciated.

If that is the wrong version, can you point me to the correct one?

I'm still hoping to find a C (as I said), Pascal, and maybe Lisp ... idk .... I'd like to play with them ALL!

Also, I having trouble accessing several of the V7 manuals from Elvira .... is it just me?

Thanks

 

[terri-...@glaver.org]

On Wednesday, August 19, 2026 at 6:31:42 PM UTC-4 paul...@mac.com wrote:

You were saying ....?

I can mount the fortran_iv_v2_8.tap and copy the file onto one of the drives.

Any hints on how to proceed from there would be appreciated.

If that is the wrong version, can you point me to the correct one?

It has been a VERY long time since I did anything with RSTS/E prior to 9.x. So,

I'm probably not the best person to ask.

However, the installation script for FORTRAN IV 2.8 is a DCL script dated 1987,

which puts it well into the RSTS/E V9.x era. Also, the whole kit is a BACKUP

saveset, which means you can't even unpack it on RSTS/E versions before 9.0.

I don't see the FORTRAN IV SPDs (Software Product Descriptions) online any-

where, so I can't tell you what the newest version of Fortran supported on V7

is.

I could package up what I *THINK* are the necessary compiler bits from my

V10.x system:

 Name .Typ    Size    Prot     Name .Typ    Size    Prot    SY:[1,2]
FORTRA.SAV     206C  <104>    FORLIB.OBJ     134   < 40>
FORTRA.HLP       4   < 40> 

But I can't guarantee that those are complete, or that they would work on V7.
Let me know if you want to try that, and if you prefer .tgz or .zip

I'm still hoping to find a C (as I said), Pascal, and maybe Lisp ... idk .... I'd like to play with them ALL!

DECUS C might work. DEC's PDP-11 C definitely won't. There was a DECUS 

Lisp, but I don't know if it has been preserved - after DEC was sold, the

DECUS library ceased to exist and discarded all of their material.

You might be able to find Lisp on one of the RSTS/E SIG tapes, which are

archived in various places online. I think Tim Shoppa has the most com-

plete set.

Also, I having trouble accessing several of the V7 manuals from Elvira .... is it just me?

It is either down or no longer at that address. I know there was a rather large

set of changes in the Swedish hobbyist community. I _think_ that that was

because a university could no longer support the computer club and its sys-

tems. Johnny Billquist (who probably doesn't read this group) would likely be

the person with the most information. 

I didn't go back and read all of the prior messages in this thread, so forgive

me if you answered this question previously - is there some reason you don't

want to run V10.1? That's the latest version, has the most preserved material

available, and comes in a ready-to-boot version with all of the layered prod-

ucts I have already installed:

bp2_v2_7.tap
cobol-11_v4_4.tap
cobol-81_v2_3.tap
c_v1_2.tap
decmail-11_v3_1.tap
decnet-e_v4_1.tap
fms11_v2_1.tpc
fortran-77_v5_4.tap
fortran_iv_v2_8.tap
rsts_v10_1_install.tap
rsts_v10_1_source.tap

You can download my "canned" image from:

https://www.glaver.org/PiDP-11/tkrsts/generic-rsts-V10_1-latest.tgz (or

.zip if you prefer).

At some point I'll try to track down additional languages and other layered

products, but that isn't even on my radar yet.

[Johnny Billquist]

I do read this list. :-)
The Update Computer Club, which is located in Uppsala, had to move out
from the University a few years ago.

Elvira is a machine at Stacken, which is the computer club at KTH (the
Royal Institute of Technology). Not sure what is going on there at the
moment, although I am sortof a member there as well...

DECUS C can definitely be installed on RSTS/E V7. I remember seeing that
back in the day. But all the rest is just as you say, Terri.

And in order to understand how to install different layered products,
manuals are usually very helpful.

Johnny

On 2026-08-20 01:54, terri-...@glaver.org wrote:
> On Wednesday, August 19, 2026 at 6:31:42 PM UTC-4 paul...@mac.com wrote:
>
> You were saying ....?
> I can mount the fortran_iv_v2_8.tap and copy the file onto one of
> the drives.
> Any hints on how to proceed from there would be appreciated.
>
> If that is the wrong version, can you point me to the correct one?
>
>
> It has been a VERY long time since I did anything with RSTS/E prior to
> 9.x. So,
> I'm probably not the best person to ask.
>
> However, the installation script for FORTRAN IV 2.8 is a DCL script
> dated 1987,
> which puts it well into the RSTS/E V9.x era. Also, the whole kit is a BACKUP
> saveset, which means you can't even unpack it on RSTS/E versions before9.0.
>
> I don't see the FORTRAN IV SPDs (Software Product Descriptions) online any-
> where, so I can't tell you what the newest version of Fortran supported
> on V7
> is.
>
> I could package up what I *THINK* are the necessary compiler bits from my
> V10.x system:
>

>  Name .Typ    Size    Prot     Name.Typ    Size    Prot    SY:[1,2]

> --
> You received this message because you are subscribed to the Google
> Groups "[PiDP-11]" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to pidp-11+u...@googlegroups.com

> <mailto:pidp-11+u...@googlegroups.com>.

> To view this discussion visit https://groups.google.com/d/msgid/

> pidp-11/6a9249dc-77bf-4fe2-8270-18fe7674521bn%40googlegroups.com
> <https://groups.google.com/d/msgid/
> pidp-11/6a9249dc-77bf-4fe2-8270-18fe7674521bn%40googlegroups.com?
> utm_medium=email&utm_source=footer>.

--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: b...@softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol

[Tony Nicholson]

On Thursday, August 20, 2026 at 8:31:42 AM UTC+10 paul...@mac.com wrote:

On Thursday, August 6, 2026 at 5:07:04 PM UTC-5 terri-...wrote:

On Thursday, August 6, 2026 at 10:34:34 AM UTC-4 paul..wrote:

So I'm back to where I was.

I'll be attempting to mount some C and Fortran .tap and .dsk files.

Any advice on getting those to work?

You'll want to make sure that the versions of those languages run on RSTS/E V7.

I know that PDP-11 C won't. That's likely the case for COBOL-81 and Fortran-77.

PDP-11 COBOL and FORTRAN IV should work. 

FORTRAN V02.5 is known to work under RSTS/E V6C and RSTS V7.0-07 as I installed it a

few years back when I was trying to re-create a RSTS/E V6C system running Bob

Supnik's ADVENT and getting a few things from a DECtape image with some of

Dave Ahl's 101 Basic Games.

I have put an RK05 image of the RSTS/E FORTRAN V02.5 Installation disk on

my Google Drive at 

https://drive.google.com/file/d/1EqWtE6rkcb-I1YRVBQtM7iY7iNDV4h0Q/view?usp=sharing

You'll need to mount it under RSTS (pack ID is FORT25).

I did this from a (created) priviledged account [1,3] and run the FORGEN.CMD using

the $BUILD program.  You'll probably wish to select threaded code to maximise

the size of programs you can compile.  

I think there's my prebuilt FORTRAN.SAV, SYSLIB.OBJ and FORTRA.HLP that you can copy

from the RK05 to your system disk in [1,2] (with <104> protection on the FORTRA.SAV

and <40> for the others.

This should get you going.

Tony

[Paul A]

On Wednesday, August 19, 2026 at 8:20:32 PM UTC-5 agn... wrote:

FORTRAN V02.5 is known to work under RSTS/E V6C and RSTS V7.0-07 as I installed it a

few years back when I was trying to re-create a RSTS/E V6C system running Bob

Supnik's ADVENT and getting a few things from a DECtape image with some of

Dave Ahl's 101 Basic Games.

I have put an RK05 image of the RSTS/E FORTRAN V02.5 Installation disk on

my Google Drive at 

https://drive.google.com/file/d/1EqWtE6rkcb-I1YRVBQtM7iY7iNDV4h0Q/view?usp=sharing

You'll need to mount it under RSTS (pack ID is FORT25).

I did this from a (created) priviledged account [1,3] and run the FORGEN.CMD using

the $BUILD program.  You'll probably wish to select threaded code to maximise

the size of programs you can compile.  

I think there's my prebuilt FORTRAN.SAV, SYSLIB.OBJ and FORTRA.HLP that you can copy

from the RK05 to your system disk in [1,2] (with <104> protection on the FORTRA.SAV

and <40> for the others.

This should get you going.

Tony

Thank you so much!  

That's awesome!   

I'll  look at it! 

[Tony Nicholson]

I was pressed for time when I sent my message yesterday - hence the typos and misinformation.

The part where I said -

I did this from a (created) priviledged account [1,3] and run the FORGEN.CMD using

the $BUILD program.  You'll probably wish to select threaded code to maximise

the size of programs you can compile.  

is incorrect.   I could not find a copy of the FORTRAN IV V02.5 release notes and install guide,

and according to my notes I just manually typed the appropriate commands in the FORGEN.CMD

FORBLD.CMD and OTSGEN.CMD/OTSBLD.CMD files in a new privileged account and copied

the resulting built files across to the system library in [1,2].

If anyone can point to the installation instructions that would be great.

Tony

[Jörgen Wahlsten]

Elvira has been down a few times before and later come back up. You could always try Hunta's copy of Elvira from (i think) 2024: https://forum.vcfed.org/index.php?threads/elvira-stacken-kth-se-down.1256706/#post-1494163

Jörgen

_______________________________________________________________________
Jörgen Wahlsten -- jor...@wahlsten.com -- http://www.wahlsten.com/

To unsubscribe from this group and stop receiving emails from it, send an email to pidp-11+u...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/pidp-11/5e22c162-52dc-46b1-92f1-aed6d2bce669%40softjar.se.

[Paul A]

On Thursday, August 20, 2026 at 4:19:07 PM UTC-5 agn... wrote:

I was pressed for time when I sent my message yesterday - hence the typos and misinformation.

The part where I said -

I did this from a (created) priviledged account [1,3] and run the FORGEN.CMD using

the $BUILD program.  You'll probably wish to select threaded code to maximise

the size of programs you can compile.  

is incorrect.   I could not find a copy of the FORTRAN IV V02.5 release notes and install guide,

and according to my notes I just manually typed the appropriate commands in the FORGEN.CMD

FORBLD.CMD and OTSGEN.CMD/OTSBLD.CMD files in a new privileged account and copied

the resulting built files across to the system library in [1,2].

Thanks again.  

I just have to enable a RK/DK: drive on my RSTS system to mount that.

But I know how to do that now.  :)

If anyone can point to the installation instructions that would be great.

I saw a copy of an install guide for Fortran IV v2.0  (c) 1977 somewhere a while back ... basically a PDF of photos of a really old manual.

I wish I had downloaded it .... but I was sure someone in this group had already done all this, and didn't want to reinvent the wheel ...

The Fortran IV v2.0 Utilities Manual is on the Elvira site (or the mirror linked below).

Paul

[Paul A]

On Thursday, August 20, 2026 at 7:14:51 PM UTC-5 jor... wrote:

Elvira has been down a few times before and later come back up. You could always try Hunta's copy of Elvira from (i think) 2024: https://forum.vcfed.org/index.php?threads/elvira-stacken-kth-se-down.1256706/#post-1494163

Jörgen

It was VERY slow ... but it worked!!

I was missing the System Managers Guide for RSTS/E v7.

Thanks so much!

 

[Paul A]

On Wednesday, August 19, 2026 at 6:54:57 PM UTC-5 terri-... wrote:

However, the installation script for FORTRAN IV 2.8 is a DCL script dated 1987,

which puts it well into the RSTS/E V9.x era. Also, the whole kit is a BACKUP

saveset, which means you can't even unpack it on RSTS/E versions before 9.0.

yeah, when I saw the *.BCK I figured I was out of luck. 

I could package up what I *THINK* are the necessary compiler bits from my

V10.x system:

 Name .Typ    Size    Prot     Name .Typ    Size    Prot    SY:[1,2]
FORTRA.SAV     206C  <104>    FORLIB.OBJ     134   < 40>
FORTRA.HLP       4   < 40> 

But I can't guarantee that those are complete, or that they would work on V7.
Let me know if you want to try that, and if you prefer .tgz or .zip

I was wondering if there's a way to know which *.SAV files would run on which system;

but I guess it's just trial and error.  I can do either .tgz or .zip.

I'm still hoping to find a C (as I said), Pascal, and maybe Lisp ... idk .... I'd like to play with them ALL!

DECUS C might work. DEC's PDP-11 C definitely won't. There was a DECUS 

Lisp, but I don't know if it has been preserved - after DEC was sold, the

DECUS library ceased to exist and discarded all of their material.

I found a couple DECUS files; I'll look at those.   Thanks. 

 

I didn't go back and read all of the prior messages in this thread, so forgive

me if you answered this question previously - is there some reason you don't

want to run V10.1?

It's just nostalgia ... I grew up on 7.0-7.2.  I will probably play around with the others too.

Hell, I'm retired now, so what else do I have to do?!  LOL.!

  

You can download my "canned" image from:

https://www.glaver.org/PiDP-11/tkrsts/generic-rsts-V10_1-latest.tgz (or

.zip if you prefer).

Thanks very much for the help! 

[Paul Koning]

On Aug 20, 2026, at 10:21 PM, 'Paul A' via [PiDP-11] <pid...@googlegroups.com> wrote:

On Wednesday, August 19, 2026 at 6:54:57 PM UTC-5 terri-... wrote:

However, the installation script for FORTRAN IV 2.8 is a DCL script dated 1987,

which puts it well into the RSTS/E V9.x era. Also, the whole kit is a BACKUP

saveset, which means you can't even unpack it on RSTS/E versions before 9.0.

yeah, when I saw the *.BCK I figured I was out of luck. 

I could package up what I *THINK* are the necessary compiler bits from my

V10.x system:

 Name .Typ    Size    Prot     Name .Typ    Size    Prot    SY:[1,2]
FORTRA.SAV     206C  <104>    FORLIB.OBJ     134   < 40>
FORTRA.HLP       4   < 40> 

But I can't guarantee that those are complete, or that they would work on V7.
Let me know if you want to try that, and if you prefer .tgz or .zip

That's likely sufficient.  In many cases, plain RT11 tools (and probably RSX ones also but I don't have much experience) will run on RSTS with the relevant runtime system installed.  Some things might not work exactly as you might want.  For example, RT11 does not have account numbers ("[1,2]" or the like) in file specs.  The RT11 emulation accepts those, but depending on the specific RT11 syscall used they might end up ignored, or they might do what you expect.  Roughly speaking, a .CSIGEN call will handle full RSTS file specs, while a .CSISPC will not.  To pick one example, I think the linker uses CSIGEN for the base command line and CSISPC for continuation lines, so PPNs would work on the first line only.

I'm still hoping to find a C (as I said), Pascal, and maybe Lisp ... idk .... I'd like to play with them ALL!

DECUS C might work. DEC's PDP-11 C definitely won't. There was a DECUS 

Lisp, but I don't know if it has been preserved - after DEC was sold, the

DECUS library ceased to exist and discarded all of their material.

I found a couple DECUS files; I'll look at those.   Thanks. 

DECUS C definitely works on RSTS V7, I remember one of my colleagues using it to port csh to RSTS.  Unfortunately that wasn't preserved.

My earlier comment about standard RT11 tools might apply to DEC C also, it's something you could try.  The V10 RSTS C kit might not work, if it uses DCL API calls to process command line arguments.  But DEC C for RT11 might run on V7.

paul