This post is constantly growing, it’s mainly for me remembering not making some fu**ups again… but it might be useful for you, too 😉

Hot keys

The Helios server has quite some hotkeys you can use to navigate and control it. Per default the “hot key” is control-shift. So combining that with a 3rd key, you will get the following effect:

• hot key ‘F1’ Switch to next window
• hot key ‘F2’ Switch to previous window
• hot key ‘F3’ Refresh current window
• hot key ‘F7’ Enter built-in debugger
• hot key ‘F8’ I/O server status request
• hot key ‘F9’ I/O server exit
• hot key ‘F10’ Reboot I/O server

Debugging the server

Booting Helios with server.exe you can provide a couple of debugging switches to see what’s going on:

• A – All. Either enable all debugging, or disable any debugging which is currently active.
• B – Boot. Give a progress report while the root processor is being booted.
• C – Communications. Monitor transmissions to and from serial lines and similar devices.
• D – Delete. List all files and directories being deleted.
• E – Errors. Report any error messages generated by the I/O server.
• F – File I/O. Give details of miscellaneous file I/O activities such as renaming files.
• G – Graphics. Report any graphics transactions.
• H – Raw disc. List sector reads and writes on a raw disc device.
• I – Initialisation. Give a progress report as the I/O server initialises its various component servers.
• J – Directory. Show details of any directory accesses.
• K – Keyboard. Report any key presses.
• L – Logger. Cycle the error logging destination between screen-only, file-only, and both screen and file.
• M – Message. Report all messages sent to and from the I/O server.
• N – Names. Show the names of objects Helios is trying to access.
• O – Open. List all files that Helios is trying to open.
• P – Close. Report any file close requests sent by Helios.
• Q – Quit. Give a progress report when the I/O server tries to exit.
• R – Read. Monitor any file reads.
• S – Search. Report all distributed searches arriving at the I/O server.
• T – Timeouts. Report any stream timeouts that may occur.
• U – Nopop. In the Server windows system, toggle between pop and nopop mode.
• V – OpenReply. Give details of replies to Open, Create, and Locate requests.
• W – Write. Monitor any file writes.
• X – Resources. Produce a snap shot of what the I/O server is currently doing.
• Y – List. Give details of all debugging options.
• Z – Reconfigure. Re-read the configuration file host.con

Those switches can be combined, e.g. server -rw

Cool: If the debug-output becomes too much to read (i.e. on screen) you can toggle the setting by pressing ctrl-shift plus the corresponding character. E.g. “c” to mute all the traffic on the serial line.

Logging

Now that we get some info about what’s going on internally, it might be a bit too much to follow on the screen (and you can’t redirect the output with “server > output.txt”). But don’t despair, there’s a way to define a logfile in HOST.CON:

logging_destination = [screen | file | both]
logfile = logbook

So simply define where you want the logging to go (screen or file or both) and define a logfile name. In this case it will be written inlogbook in the Helios root directory.
Please mind that the logfile will be overwritten (not appended) each time you reboot!

Config-Files

I cannot repeat it often enough: ALL config files (but HOST.CON) are Unix-Formatted, ie. LF instead of LF+CR. So each time something is behaving strange, check your config files for proper formatting!
I’ve spent hours of debugging just to find out I had (again) “tainted” a config file by quickly having a look with edit.exe :-/

Yup, Helios is a Multitasking-Multiuser OS… but not quite as you might got used to it using UNIX(ish) OSes in recent times. There are some caveats:

Theory

As Helios is running on Transputers (mostly) and Transputers do not feature an MMU, there’s no ‘protected’ multitasking, i.e. a badly written application can kill (at least) the Transputer it is running on, if not the whole network. This might bring back memories of Apples System 7.x “Multi Finder” or Windoze 95 and other cooperative multitaskting solutions.
The only half-way robust way to really protect Helios processes is to ‘lock them away’ into a dedicated Transputer.

Running Multiuser (ie. providing remote login etc.) means you need at least 2 Transputers. To protect certain essential services like ‘netserver’ and ‘sessionmanager’ those have to run on the “root Transputer” (/00) which is not accessible to any user – including root. Logging in from the console on your PC will automatically put you onto the next Transputer in-line, eg. /01.
In consequence, if you like to have another user logging in over ‘telnet’ or serial console you’ll need another Transputer for that user (making it 3 in total).

Practice

So what do we need to configure to go Multiuser? First you should have your Transputer network configured and running as described 2 posts before this.
Then we check the nsrc file found in Helios’ /etc folder. Because I couldn’t say it better, I’ll copy from the Manual:
“The nsrc file contains a list of options for the networking software, like the host.con
file which has a list of options for the I/O server. The nsrc file is read by the startns
program when networking software is started up, and passed in the environment to
the network server and/or Session Manager.”
(Just a refresher: network, networking and server means Transputer networks, no TCP/IP stuff and such.)

It should look somehow like this:

# root_processor = /Bozo/01
# single_user
# password_checking
# processor_protection
# no_taskforce_manager
share_root_processor
preload_netagent
waitfor_network
# 30 seconds is the default interval, -1 disables network monitoring
#monitor_interval = 10

I won’t go into every detail of each setting – there’s a Manual for that (p.58). Just make sure that ‘single_user’ is commented. For the curious amongst you: share_root_processor means the taskforce-manager, network-server and session-manager may run on the same CPU. If Helios runs in Multiuser mode like we are going to do, this is ignored anyway.

That’s it. If everything worked as described, Helios will boot all processors (but showing only /01 and /02) and logging in locally on your host machine will put you on Transputer /01. Users logging in via telnet will automatically put onto Transputer /02. This is a ps output entered in a telnet session:

% ps /00 /01 /02
Processor 00
ProcMan.0           Loader.1            netserv.4
Pipe.5              session.7           login.9
Processor 01
ProcMan.0           Loader.1            tcpip.3
inetd.4             Pipe.6              tfm.27
shell.28            telnetd.31          ttyserv.32
login.33
Processor 02
ProcMan.0           Loader.1            tfm.3
Pipe.4              shell.5             ps.7

The (inaccessible) Root-Transputer /00 is running the netserver and session-manager.
Processor /01 does the TCP/IP, inetd and telnetd handling, runs a shell (local login), cares for tty and runs a taskforce-manager (needed for parallel programs).
Finally processor /02 is the one the telnet-user actually lives and triggered the ps command from its shell.

So after all this configuring we have multiple Transputers running, TCP/IP is there and we can host multiple users (given we have enough Transputers to host them)… next and final step: X-Window!